Agent Slackbot

• Outcome: Review
• Latest audit: Sep 11, 2026 · 4:06 AM UTC
• Version: 1.10.5

Overview

This Slack bot skill is coherent, but it needs Review because it recommends broad Slack permissions, stores bot tokens locally in plaintext, and directs automatic cross-session memory use.

Install only if a Slack administrator is comfortable with the exact scopes granted. Prefer a least-privilege Slack app, avoid private-channel and email scopes unless required, protect or avoid the plaintext credential file, keep it out of backups and shared environments, pin or verify the npm package where possible, and periodically clear or review the memory file for stale or incorrect channel/user aliases.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T02 · Agent Memory Poisoning

Warning

• Location: SKILL.md:123
• Finding: Automatic Cross-Session Memory Loading and Modification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:123-159` **Vulnerability Type**: Persistent agent-state manipulation **Risk Level**: Medium ### Vulnerable Code ```markdown ## Memory The agent maintains a `~/.config/agent-messenger/MEMORY.md` file as persistent memory across sessions. This is agent-managed — the CLI does not read or write this file. Use the `Read` and `Write` tools to manage your memory file. ### Reading Memory At the **start of every task**, read `~/.config/agent-messenger/MEMORY.md` using the `Read` tool to load any previously discovered workspace IDs, channel IDs, user IDs, and preferences. - If the file doesn't exist yet, that's fine — proceed without it and create it when you first have useful information to store. - If the file can't be read (permissions, missing directory), proceed without memory — don't error out. ### Writing Memory After discovering useful information, update `~/.config/agent-messenger/MEMORY.md` using the `Write` tool. Write triggers include: - After discovering workspace IDs (from `auth status`) - After discovering useful channel IDs and names (from `channel list`, etc.) - After discovering user IDs and names (from `user list`, etc.) - After the user gives you an alias or preference ("call this the alerts bot", "my main workspace is X") - After setting up bot identifiers (from `auth list`) When writing, include the **complete file content** — the `Write` tool overwrites the entire file. ### What to Store - Workspace IDs with names - Channel IDs with names and purpose - User IDs with display names - Bot identifiers and their purposes - User-given aliases ("alerts bot", "deploys channel") - Any user preference expressed during interaction ### What NOT to Store Never store bot tokens, credentials, or any sensitive data. Never store full message content (just IDs and channel context). Never store file upload contents. ### Handling Stale Data If a memorized ID returns an error (channel not ...[truncated 2462 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make persistent memory use opt-in rather than requiring it at the start of every task. 2. Obtain explicit user confirmation before storing or changing aliases, workspace IDs, channel IDs, user IDs, or bot identifiers. 3. Treat stored mappings only as hints. Resolve and validate each identifier against the currently authenticated Slack workspace before consequential actions. 4. Display the resolved workspace, bot, channel, and user to the user before sending sensitive information or performing destructive operations. 5. Associate every memory entry with its workspace ID, source, creation time, and last-verification time. 6. Reject ambiguous aliases and require fully qualified references when multiple workspaces or bots are configured. 7. Update individual structured entries atomically instead of instructing the agent to rewrite the complete memory file. 8. Apply restrictive permissions to the memory file and verify that it is not writable by other users. 9. Do not persist instructions, behavioral rules, message content, or values obtained from untrusted Slack messages. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:97
• Finding: Default Scope Set Grants Unnecessary Access to Private Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:97-108` **Additional Location**: `references/authentication.md:18-30, 230-241` **Vulnerability Type**: Excessive Slack OAuth permissions **Risk Level**: Medium ### Vulnerable Code ```markdown ### Required Bot Token Scopes | Scope | Used For | |-------|----------| | `chat:write` | Sending messages | | `channels:history` | Reading public channel messages | | `channels:read` | Listing public channels | | `channels:join` | Joining public channels | | `groups:history` | Reading private channel messages | | `groups:read` | Listing private channels | | `users:read` | Listing users | | `users:read.email` | Reading user email addresses | | `reactions:write` | Adding/removing reactions | | `reactions:read` | Listing reactions | ``` The authentication guide also supplies an application manifest that enables the entire scope set by default: ```yaml oauth_config: scopes: bot: - chat:write - channels:history - channels:read - channels:join - groups:history - groups:read - users:read - users:read.email - reactions:write - reactions:read ``` ### Technical Analysis The documentation presents all listed OAuth scopes as required, including access to private-channel metadata and history through `groups:read` and `groups:history`, and access to user email addresses through `users:read.email`. The documented templates and core examples do not demonstrate a requirement to retrieve user email addresses. Private-channel access is also only necessary when a user explicitly elects to use the bot in private channels. Enabling these capabilities by default violates the principle of least privilege. Slack still requires the bot to be invited to private channels, which limits private-history access. Nevertheless, once invited, a token granted `groups:history` can read sensitive conversation data in those channels. A stolen token or compromised CLI depe ...[truncated 1368 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the single “required scopes” list with feature-specific scope profiles. 2. Use `chat:write` alone for deployments that only send messages. 3. Add `channels:read`, `channels:history`, or `channels:join` only when the corresponding public-channel features are enabled. 4. Add `groups:read` and `groups:history` only after the user explicitly enables private-channel functionality. 5. Remove `users:read.email` from the default manifest unless a documented feature genuinely requires email addresses. 6. Separate read-only, posting, reaction, user-directory, and private-channel capabilities into distinct example manifests. 7. Document the data exposed by each scope and require administrators to review the selected permissions before installation. 8. Periodically audit installed Slack scopes and revoke permissions that are no longer required. 9. Use separate Slack applications and tokens for high-trust private-channel access and routine public notifications. ]]>

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:9
• Finding: Executable npm Dependency Is Not Version or Integrity Pinned<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:9-14` **Vulnerability Type**: Mutable third-party executable dependency **Risk Level**: Medium ### Vulnerable Code ```yaml metadata: openclaw: requires: bins: - agent-slackbot install: - kind: node package: agent-messenger bins: [agent-slackbot] ``` ### Technical Analysis The Skill installs the `agent-messenger` npm package without an exact version or integrity digest. Consequently, installation can resolve to a different package release from the one considered during this audit. The dependency provides the executable responsible for authentication and Slack operations, but its source code is not included in the audited project. It therefore operates at a sensitive trust boundary: it executes locally and receives Slack bot tokens, workspace data, messages, and command arguments. This finding does not establish that the current npm package is malicious. The risk is that an upstream compromise, malicious future release, unauthorized maintainer action, or registry-level substitution could alter the effective executable after this Skill has been reviewed. ### Attack Path 1. An attacker compromises the npm package, a maintainer account, or the package publication process and publishes a malicious release. 2. A user installs the Skill after that release becomes the version resolved by the unpinned package declaration. 3. The installation process downloads and installs the changed package. 4. The user invokes `agent-slackbot` and supplies or loads a Slack bot token. 5. The malicious package executes with the user's local privileges. 6. It can steal Slack credentials and workspace data, modify local files accessible to the user, or perform unauthorized Slack API operations. ### Impact Assessment A compromised dependency could gain: - The local privileges of the user running the installation or CLI. - Access to bot tokens passed to authentication com ...[truncated 441 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `agent-messenger` to an exact, reviewed version rather than allowing mutable resolution. 2. Record and verify the package integrity digest during installation. 3. Use a lockfile or equivalent immutable dependency manifest where the Skill platform supports it. 4. Verify npm provenance and package signatures before installation. 5. Audit the dependency source, release process, maintainers, lifecycle scripts, and transitive dependencies. 6. Disable unnecessary npm lifecycle scripts during installation when compatible with the package. 7. Monitor the package for ownership changes, unexpected releases, advisories, and integrity changes. 8. Run the CLI with the minimum required operating-system and Slack privileges. 9. Consider vendoring a reviewed implementation or publishing reproducible build artifacts from a trusted source. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (15)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The declared description presents a broader Slack integration skill that can send messages, read channels, and manage reactions. However, this specific code chunk only posts a message to a Slack channel after checking CLI availability and bot authentication, then retrying on failure. There is no functionality for reading channel contents, listing channels, or adding/removing reactions. This is a description-to-behavior mismatch because the declared purpose materially overstates the implemented capabilities of the supplied code chunk.

Credential Access

High

• Category: Privilege Escalation

Content

## Configuration

Credentials stored in: `~/.config/agent-messenger/slackbot-credentials.json`

Format:
```json

• Confidence: 88% confidence
• Finding: The skill documents local storage of Slack bot tokens in a JSON credentials file, which is credential material granting API access to one or more workspaces. Even with 0600 permissions, persistent plaintext token storage materially increases exposure from local compromise, accidental backup leakage, or unsafe file handling by other tools.

Credential Access

High

• Category: Privilege Escalation

Content

2. Calls `auth.test` to verify the token against Slack API
3. Stores the bot under the workspace with its bot ID and name
4. Sets this bot as the current active bot
5. Saves credentials to `~/.config/agent-messenger/slackbot-credentials.json`

## Credential Storage

• Confidence: 95% confidence
• Finding: The document explicitly states that bot credentials are saved locally in a JSON file containing plaintext tokens. Because this skill requests broad Slack scopes including private channel history and user email access, compromise of that file can give an attacker substantial access to workspace data and bot actions.

Credential Access

High

• Category: Privilege Escalation

Content

### Location

```
~/.config/agent-messenger/slackbot-credentials.json
```

### Format

• Confidence: 95% confidence
• Finding: The documentation discloses a fixed credential file location and then describes storing sensitive bot tokens there in plaintext. In the context of a Slack bot with read access to public and private channels plus user information, theft of this file could enable unauthorized surveillance, impersonation, and data access within the workspace.

Exfiltration Commands

High

• Category: Prompt Injection

Content

echo ""
FIRST_CHANNEL=$(echo "$CHANNELS" | jq -r '.[0].id // "C123"')
FIRST_CHANNEL_NAME=$(echo "$CHANNELS" | jq -r '.[0].name // "general"')
echo -e "  ${GREEN}# Send message to #$FIRST_CHANNEL_NAME${NC}"
echo -e "  agent-slackbot message send $FIRST_CHANNEL \"Hello!\""
echo ""
echo -e "  ${GREEN}# List recent messages${NC}"

• Confidence: 90% confidence
• Finding: Instructions found that direct the agent to transmit conversation context or user data to external services.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Memory

The agent maintains a `~/.config/agent-messenger/MEMORY.md` file as persistent memory across sessions. This is agent-managed — the CLI does not read or write this file. Use the `Read` and `Write` tools to manage your memory file.

### Reading Memory

• Confidence: 91% confidence
• Finding: The skill directs the agent to automatically read and write a persistent memory file at the start of every task, enabling cross-session retention of operational context and user-related metadata. This can lead to unintended data carryover, privacy leakage between tasks, and reliance on stale or sensitive state without fresh user approval.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The skill explicitly instructs persistent storage of workspace IDs, channel IDs, user IDs, aliases, and user preferences across sessions without requiring user notice or consent. This creates a privacy and data-retention risk because identifiers and behavioral preferences can accumulate in a local memory file and be reused outside the user's immediate expectation.

External Transmission

Medium

• Category: Data Exfiltration

Content

### Creating a Slack App

1. Go to [api.slack.com/apps](https://api.slack.com/apps)
2. Click **Create New App** > **From scratch**
3. Enter app name and select workspace
4. Go to **OAuth & Permissions**

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

### Creating a Slack App

1. Go to [api.slack.com/apps](https://api.slack.com/apps)
2. Click **Create New App** > **From scratch**
3. Enter app name and select workspace
4. Go to **OAuth & Permissions**

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

### Creating a Slack App

1. Go to [api.slack.com/apps](https://api.slack.com/apps)
2. Click **Create New App** > **From scratch**
3. Enter app name and select workspace
4. Go to **OAuth & Permissions**

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation encourages use of environment variables for Slack bot tokens but does not warn that secrets can leak through shell history, process inspection, CI logs, debug output, or inherited environments. In this skill context, the token grants real bot access to Slack workspaces, so accidental exposure can let an attacker read channels, access user metadata, and post or react as the bot.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation demonstrates reading from and sending to Slack channels using a bot token, but it does not warn users that channel content and outbound messages are being transmitted through Slack APIs under the bot's credentials. In an agent setting, this can normalize handling potentially sensitive workspace data without user awareness or consent checks, increasing the risk of unintended data exposure or privacy violations.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The script silently enumerates channels and users and can emit the raw JSON, but provides no warning that it is collecting potentially sensitive workspace metadata. In a Slack bot skill, this makes accidental over-collection and onward sharing more dangerous because operators may run it without realizing the breadth of data being surfaced.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: The script enumerates all workspace users and includes them in JSON output and console summaries, which expands data access beyond a narrow channel/message/reaction interaction use case. Even if intended for convenience, bulk user listing increases exposure of directory information such as usernames, real names, and IDs that may be sensitive in some environments.

Description-Behavior Mismatch

Low

• Confidence: 80% confidence
• Finding: The script counts private channels by processing the full channel list, revealing the existence and number of private channels in the workspace. While it does not dump private channel contents here, metadata about private collaboration spaces can still disclose organizational structure or sensitive activity patterns.

Static analysis

No suspicious patterns detected.