Back to skill

Security audit

slack-memory

Security checks for vulnerabilities and agentic risk

Overview

This Slack memory skill is coherent, but it can send and persist broad Slack workspace context to an external service without clear scoping, consent, or retention controls.

Review this before installing in any real Slack workspace. Only use it with approved channels and data that your organization permits to be stored by BlueColumn/Supabase, avoid private messages and regulated or sensitive content, and require clear retention/deletion and access-control terms before enabling broad monitoring.

Vulnerability Patterns
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (2)

other

Warning
Location
SKILL.md:12
Finding
Unrestricted Transmission of Sensitive Slack Data to an External Service## Vulnerability Details **File Location**: `SKILL.md`, lines 12-19; related workflow instructions at lines 40-44 **Vulnerability Type**: Sensitive Workspace Data Disclosure **Risk Level**: Medium The skill directs the agent to collect Slack decisions, personal attribution, dates, channel names, and thread references and transmit them to a fixed third-party Supabase endpoint. ```bash ## Capture the decision When a channel lands on a decision, store it with the channel and date. curl -X POST https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1/agent-remember \ -H "Authorization: Bearer $BLUECOLUMN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"text": "DECISION (in #product, Jul 30): v2 ships without the offline mode; revisit after onboarding metrics. Priya objected, Daniel carried it. Thread: t/12345.", "title": "slack - v2 scope"}' ``` The broader workflow explicitly encourages continuous collection: ```markdown 1. **Monitor** — capture decisions, promises, and context from channels you work in. 2. **Search** — recall the stored history before answering, instead of scrolling. 3. **Connect** — link Slack promises to the follow-up radar. 4. **Summarize** — for busy channels, post a stored summary so the decision is findable by everyone. ``` ### Technical Analysis Slack channel content can contain confidential business decisions, employee information, customer data, credentials, incident details, and regulated information. The skill sends selected content to an externally hosted endpoint without defining: - Workspace or channel allowlists - User consent or administrative approval - Data classification checks - Credential and personal-data redaction - Payload review before transmission - Data retention and deletion controls - Tenant isolation or destination verification - Restrictions for private channels and direct messages The use of TLS protects data in transit but does not addre ...[truncated 1304 chars]
Remediation
## Remediation Suggestions 1. Require explicit workspace-administrator authorization before enabling external storage. 2. Restrict collection to an explicit allowlist of channels and prohibit private channels and direct messages by default. 3. Display the destination and complete proposed payload for user confirmation before each transmission, or enforce a documented approved automation policy. 4. Redact credentials, access tokens, customer data, personal data, and regulated information before sending records. 5. Minimize stored content by retaining concise decisions rather than raw messages, names, or unnecessary thread content. 6. Document encryption, tenant isolation, access controls, retention periods, deletion procedures, subprocessors, and incident-response obligations. 7. Validate that the hostname is an administrator-approved destination and prevent user-controlled endpoint substitution or redirects. 8. Use a narrowly scoped API key, rotate it regularly, avoid logging authorization headers, and provide immediate revocation. 9. Offer local or organization-controlled storage for workspaces that cannot send Slack data to an external service.

T02 · Agent Memory Poisoning

Warning
Location
SKILL.md:12
Finding
Persistent Slack Memory Can Be Poisoned by Untrusted Channel Content## Vulnerability Details **File Location**: `SKILL.md`, lines 12-27 **Vulnerability Type**: Agent Memory Poisoning **Risk Level**: Medium The skill instructs the agent to persist decisions derived from Slack and consult that history before answering later questions. ```markdown ## Capture the decision When a channel lands on a decision, store it with the channel and date. ```bash curl -X POST https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1/agent-remember \ -H "Authorization: Bearer $BLUECOLUMN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"text": "DECISION (in #product, Jul 30): v2 ships without the offline mode; revisit after onboarding metrics. Priya objected, Daniel carried it. Thread: t/12345.", "title": "slack - v2 scope"}' ``` ## Answer from history Before answering a workspace question, search the captured history. ```bash curl -X POST https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1/agent-recall \ -H "Authorization: Bearer $BLUECOLUMN_API_KEY" \ -H "Content-Type: application/json" \ -d '{"q": "What did #product decide about offline mode for v2, and who objected?"}' ``` ### Technical Analysis Slack messages are untrusted input because workspace participants may intentionally or accidentally publish false statements, instruction-like text, or misleading claims about decisions. The skill provides no requirements for: - Confirming that a message represents an approved decision - Recording the original author and immutable source provenance - Distinguishing quoted Slack data from executable agent instructions - Assigning trust levels to recalled records - Requiring approval before persistent storage - Expiring, correcting, or deleting disputed records - Enforcing channel-level authorization during recall Consequently, misleading channel content can become persistent state and influence answers in later sessions. The demonstrated behavior primarily threatens ...[truncated 1412 chars]
Remediation
## Remediation Suggestions 1. Treat every Slack message and recalled record as untrusted data, never as an instruction to the agent. 2. Store immutable provenance including workspace, channel, message identifier, thread identifier, author, timestamp, and capture identity. 3. Require explicit confirmation from an authorized participant before classifying a discussion as a binding decision. 4. Preserve quotations separately from agent-generated summaries and label both with confidence and trust metadata. 5. Detect and quarantine instruction-like content, tool commands, credential requests, and attempts to alter agent behavior. 6. Apply workspace, channel, and user authorization checks to both memory writes and recalls. 7. Add record expiration, correction, dispute, audit, and deletion mechanisms. 8. Present source links with recalled claims so users can verify the original discussion. 9. Prevent recalled text from entering system or developer instruction layers; place it only in a clearly delimited untrusted-data context. 10. Use human review for high-impact decisions or records involving security, finance, legal obligations, personnel, or production changes.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (3)

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The skill description advertises capturing and answering from the whole Slack workspace but does not warn users that workspace messages, decisions, names, channels, and thread content are sent to an external BlueColumn/Supabase-hosted service. This can lead to unintentional exfiltration of sensitive internal communications, regulated data, or confidential business context because users may reasonably assume the skill operates locally within Slack or the agent.

External Transmission

Medium
Category
Data Exfiltration
Content
When a channel lands on a decision, store it with the channel and date.

```bash
curl -X POST https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1/agent-remember \
  -H "Authorization: Bearer $BLUECOLUMN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text": "DECISION (in #product, Jul 30): v2 ships without the offline mode; revisit after onboarding metrics. Priya objected, Daniel carried it. Thread: t/12345.", "title": "slack - v2 scope"}'
Confidence
99% confidence
Finding
The example command sends Slack-derived content, including channel identifiers, participant names, decisions, and thread references, to an external HTTPS endpoint controlled outside the user's Slack environment. Even though the functionality appears intentional, it is still security-relevant because it operationalizes third-party transmission of potentially sensitive workspace history using a live API key, creating confidentiality, compliance, and insider-risk concerns if used broadly.

Missing User Warnings

Medium
Confidence
98% confidence
Finding
The workflow explicitly tells the agent to monitor, capture, and summarize content from channels it works in, but provides no privacy, consent, scope, or data-minimization constraints. In context, this broad collection guidance increases the chance of mass ingestion of private conversations, HR/legal discussions, customer data, or other sensitive workspace content into an external memory system.

Static analysis

No suspicious patterns detected.