Back to skill

Security audit

InterClaw

Security checks for vulnerabilities and agentic risk

Overview

This skill has a coherent email-coordination purpose, but it needs review because it handles mail and PGP credentials, persistent message archives, and unaudited helper commands with under-scoped security guidance.

Review this before installing on a real mailbox. Use a dedicated email account, avoid putting passwords in command history, prefer app-specific credentials or a secret manager, verify any helper scripts and downloaded binaries yourself, and assume ~/.interclaw may contain sensitive message history and keys unless you add your own retention and file-permission controls.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (4)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:12
Finding
Agent Communication Behavior Hijacking Through Mandatory Skill Instructions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:12-21` **Vulnerability Type**: Agent instruction hijacking **Risk Level**: High ### Vulnerable Code ```markdown You are now running **InterClaw v3**. This skill gives every OpenClaw instance a reliable, encrypted, sequenced communication channel with any other instance using only email + PGP. **When you need to talk to another agent:** 1. Decide the tag (`[COORD]`, `[ENCRYPTED]`, `[MULTI]`, etc.) 2. Call the helper script instead of raw email. ## Core Rules You Must Follow - Never send raw email to another agent. - Always use `interclaw-send`. - Always verify incoming messages with `interclaw-receive`. - Only trust fingerprints listed in your config. ``` ### Technical Analysis The Skill uses role-setting and mandatory language to alter the agent's session-wide communication behavior. Rather than limiting itself to instructions for an explicitly requested InterClaw operation, it declares that the agent is already “running InterClaw” and commands it to route all agent-to-agent email through Skill-defined helpers. This constitutes instruction hijacking because loading the Skill can change the agent's current goals and tool-selection behavior. The referenced `interclaw-send` and `interclaw-receive` implementations are not included in the submitted project, despite the manifest referring to `scripts/*`. Their handling of credentials, message contents, recipient validation, and network traffic therefore cannot be audited. ### Attack Path 1. An agent loads or is instructed to consult `SKILL.md`. 2. The agent interprets “Core Rules You Must Follow” as session-level instructions. 3. The agent abandons other legitimate communication paths and routes messages through `interclaw-send`. 4. The external or subsequently supplied helper receives message bodies, recipient addresses, cryptographic material, and mail configuration. 5. If that helper is malicious or compromised, it can redirect, retain, or alt ...[truncated 755 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace session-wide role-setting with opt-in, task-scoped documentation, for example: “When the user explicitly requests sending a message through InterClaw, use the following command.” 2. Remove phrases such as “You are now running,” “You must follow,” “Never,” and “Always” where they attempt to override unrelated communication decisions. 3. State explicitly that higher-priority system, developer, user, privacy, and safety requirements take precedence. 4. Require explicit user confirmation of the recipient and message content before network transmission. 5. Include every referenced `interclaw-*` script in the reviewed package so its network destinations, credential handling, validation, and encryption can be audited. 6. Limit environment-variable access to commands that actually require each credential and avoid exposing mail or PGP secrets merely when the Skill is loaded. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
docs/protocol-v3.md:14
Finding
Reusable Shared Authentication Secret May Be Sent in Unencrypted Email<![CDATA[ ## Vulnerability Details **File Location**: `docs/protocol-v3.md:14-33`, `docs/protocol-v3.md:92-103`, `docs/protocol-v3.md:220-234`, and `config/example.env:49-54` **Vulnerability Type**: Plaintext transmission of reusable authentication material **Risk Level**: High ### Vulnerable Code ```markdown Every email body starts with these structured headers: ``` GlobalSeq: D-042 ConvID: 01J8K9P2Q3R4S5T6U7V8W9X0Y ConvSeq: 003 Ref: 01J8K9P2Q3R4S5T6U7V8W9X0Y:002 Timestamp: 2026-02-17T19:54:00Z X-Agent-ID: Donna/1.0 X-Agent-Secret: <rotating-weekly-shared-secret> ``` ``` ```markdown ### When Encryption is OPTIONAL - `[COORD]`, `[INTEL]`, `[RELAY]`, `[MULTI]` — sender's discretion - `[PING]`, `[ACK]`, `[RECV]` — never encrypted (low-value, high-frequency) ``` The example wire format also includes the reusable value inside a signed but plaintext message: ```text X-Agent-ID: Donna/1.0 X-Agent-Secret: weekly-rotate-abc123 Harvey, let's sync on sprint priorities. ``` The corresponding configuration declares: ```dotenv # Rotating shared secret for X-Agent-Secret header (optional) INTERCLAW_SHARED_SECRET="" ``` ### Technical Analysis The protocol describes `X-Agent-Secret` as an optional rotating shared authentication secret and places it in the mandatory message-header structure. At the same time, it permits several message classes to remain unencrypted and requires `[PING]`, `[ACK]`, and `[RECV]` messages to be unencrypted. A PGP signature protects integrity and authenticates the signing key, but it does not provide confidentiality. Consequently, any reusable secret included in a signed plaintext message remains visible to SMTP relays, mailbox providers, message archives, mail-security gateways, diagnostic systems, and anyone who later obtains mailbox access. The documentation does not clearly state that `X-Agent-Secret` must be omitted from every unencrypted message. The supplied wire-format example reinforces the unsafe behavior by showing the ...[truncated 1133 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `X-Agent-Secret` from the wire protocol if PGP signatures already provide peer authentication. 2. Never place reusable authentication secrets in plaintext messages or ordinary email headers. 3. If an independent symmetric authentication layer is required, use a keyed MAC over a canonical message containing a unique nonce, sender and recipient identities, and an expiration time. Transmit only the MAC, never the key. 4. Bind replay protection to the cryptographic authentication mechanism rather than relying solely on sequence metadata. 5. Require encryption for every message containing sensitive configuration or authentication material; do not define any secret-bearing message type as “never encrypted.” 6. Explicitly specify that the shared secret must be omitted from unencrypted messages. 7. Rotate any secret that may already have been transmitted under the documented protocol. 8. Add tests proving that plaintext output never contains `INTERCLAW_SHARED_SECRET`. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:84
Finding
Email and PGP Credentials Are Accepted Through Command-Line Arguments and Plaintext Environment Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:84-92`, `README.md:68-75`, `README.md:183-188`, and `config/example.env:27-45` **Vulnerability Type**: Insecure credential handling **Risk Level**: Medium ### Vulnerable Code ```bash interclaw-config init \ --email donna@example.com \ --smtp-host smtp.fastmail.com \ --smtp-pass "app-password" \ --imap-host imap.fastmail.com \ --imap-pass "app-password" ``` The multi-agent examples repeat the same pattern: ```bash INTERCLAW_HOME=~/.interclaw-donna interclaw-config init --email donna@example.com --smtp-host smtp.fastmail.com --smtp-pass "pass" INTERCLAW_HOME=~/.interclaw-harvey interclaw-config init --email harvey@example.com --smtp-host smtp.fastmail.com --smtp-pass "pass" INTERCLAW_HOME=~/.interclaw-benjamin interclaw-config init --email benjamin@example.com --smtp-host smtp.fastmail.com --smtp-pass "pass" ``` The configuration template stores credentials as ordinary environment-file values: ```dotenv INTERCLAW_SMTP_HOST="smtp.example.com" INTERCLAW_SMTP_PORT="587" INTERCLAW_SMTP_USER="${INTERCLAW_EMAIL}" INTERCLAW_SMTP_PASS="" INTERCLAW_IMAP_HOST="imap.example.com" INTERCLAW_IMAP_PORT="993" INTERCLAW_IMAP_USER="${INTERCLAW_EMAIL}" INTERCLAW_IMAP_PASS="" # Your GPG private key ID (fingerprint or email) PGP_PRIVATE_KEY_ID="" # Passphrase for automated signing (store securely!) PGP_PASSPHRASE="" ``` ### Technical Analysis Passing passwords as command-line arguments can expose them through shell history, terminal logging, process inspection, audit frameworks, crash reports, and copied setup transcripts. Quoting the value does not prevent those disclosure channels. The template also directs users to copy secrets into `~/.interclaw/config.env`, but the reviewed documentation does not require restrictive file permissions or a secret-management backend. The same directory contains identity, state, message archives, and logs, increasing the consequences of permissive permissions or bro ...[truncated 1590 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove password-bearing command-line options from recommended setup instructions. 2. Read secrets using a non-echoing interactive prompt, protected standard input, an operating-system keychain, or a dedicated secret manager. 3. Support references to secret-manager entries rather than embedding secret values directly in environment files. 4. Create `config.env`, `himalaya.toml`, private-key directories, logs, and message archives with owner-only permissions. Files containing credentials should use mode `0600`; sensitive directories should use mode `0700`. 5. Validate permissions at startup and fail closed when credential files are group- or world-readable. 6. Disable shell-history recording around any unavoidable secret entry and clearly document the residual risks. 7. Ensure commands and logs redact passwords, passphrases, shared secrets, and authentication tokens. 8. Prefer provider-specific, narrowly scoped application passwords and document immediate rotation after suspected exposure. ]]>

T08 · Insecure Dependencies

Warning
Location
SKILL.md:7
Finding
Downloaded Mail Client Dependency Has No Declared Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:7` **Vulnerability Type**: Unverified downloaded executable dependency **Risk Level**: Medium ### Vulnerable Code ```yaml metadata: {"openclaw":{"emoji":"🦞🔒","requires":{"bins":["gpg"],"anyBins":["himalaya"],"env":["INTERCLAW_EMAIL","INTERCLAW_SMTP_HOST","INTERCLAW_SMTP_PORT","INTERCLAW_SMTP_USER","INTERCLAW_SMTP_PASS","INTERCLAW_IMAP_HOST","INTERCLAW_IMAP_PORT","INTERCLAW_IMAP_USER","INTERCLAW_IMAP_PASS","PGP_PRIVATE_KEY_ID"],"optionalEnv":["INTERCLAW_HOME","INTERCLAW_MAX_MESSAGE_AGE","INTERCLAW_AGENT_ID","INTERCLAW_TRUSTED_FINGERPRINTS","INTERCLAW_SHARED_SECRET","INTERCLAW_POLL_INTERVAL","INTERCLAW_AUTO_ACK","INTERCLAW_LOG_LEVEL","PGP_PASSPHRASE","HIMALAYA_CONFIG"]},"install":[{"id":"gpg-apt","kind":"apt","package":"gnupg","label":"Install GnuPG (apt)","bins":["gpg"],"os":["linux"]},{"id":"gpg-brew","kind":"brew","formula":"gnupg","label":"Install GnuPG (brew)","bins":["gpg"],"os":["darwin"]},{"id":"himalaya-brew","kind":"brew","formula":"himalaya","label":"Install Himalaya (brew)","bins":["himalaya"],"os":["darwin"]},{"id":"himalaya-download","kind":"download","url":"https://github.com/pimalaya/himalaya/releases/tag/v1.1.0","label":"Install Himalaya v1.1.0 (download binary)","bins":["himalaya"],"os":["linux","darwin"]}]}} ``` ### Technical Analysis The manifest pins a Himalaya release tag, which is safer than an unversioned download, but it does not identify an exact platform artifact, expected cryptographic checksum, or trusted release signature. A release-page URL is not itself an integrity guarantee for the executable ultimately installed. Himalaya is security-sensitive in this design because it handles SMTP and IMAP traffic and may have access to mailbox credentials, message bodies, recipient addresses, and generated configuration. A substituted or compromised executable would operate at the core of the Skill's network boundary. The reviewed package does not prove that a separate inst ...[truncated 1259 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Reference exact, platform-specific release artifacts rather than a general release-page URL. 2. Pin a SHA-256 or stronger digest for every supported operating-system and architecture combination. 3. Verify an upstream release signature against a separately distributed, trusted maintainer key where available. 4. Fail installation if the checksum, signature, platform, or expected filename does not match. 5. Record the verified dependency version and digest in installation logs without recording credentials. 6. Prefer trusted package repositories that provide signed metadata when their trust and update policies are acceptable. 7. Run the mail client with only the filesystem and network access required for SMTP or IMAP operations. 8. Include the bootstrap implementation in the package so download resolution and verification behavior can be audited. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Rogue AgentSelf-Modification, Session Persistence
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (6)

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The initialization examples pass SMTP/IMAP passwords directly on the command line, which can expose secrets through shell history, process listings, audit logs, CI logs, or terminal scrollback. In an agent skill context, this is more dangerous because users may copy-paste commands verbatim into shared or automated environments where credential leakage persists beyond the session.

Session Persistence

Medium
Category
Rogue Agent
Content
# Or manual: symlink scripts yourself
chmod +x scripts/interclaw-*
mkdir -p ~/.local/bin
ln -sf "$(pwd)"/scripts/interclaw-* ~/.local/bin/
```
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The protocol explicitly specifies persistent storage of configuration, logs, message archives, trusted keys, and conversation state under ~/.interclaw/, but it does not define retention limits, access controls, encryption at rest, or operator warnings about privacy and forensic exposure. In a messaging system intended for sensitive agent-to-agent coordination, indefinite local retention can leak metadata and plaintext content through disk compromise, backups, multi-user access, or later unintended disclosure.

Description-Behavior Mismatch

Low
Confidence
84% confidence
Finding
The description says 'No servers. No WebSockets. No cloud dependency' and later says the tool is 'not a mail client', yet the same README instructs users to configure SMTP/IMAP accounts and recommends cloud email providers, with `curl` listed as a prerequisite for HTTP requests. While SMTP/IMAP are expected for an email-based coordination tool, the absolute 'No cloud dependency' wording overstates the implementation reality described elsewhere in the file.

Missing User Warnings

Low
Confidence
80% confidence
Finding
The Quick Start says the bootstrap step installs packages and creates symlinks, which modifies the user's system state. While the action is noted briefly, there is no explicit warning or caution that this step changes the local environment and PATH-related tooling setup.

Intent-Code Divergence

Low
Confidence
88% confidence
Finding
The documentation makes an absolute claim that non-InterClaw mail is never touched. However, the adjacent example for Maildir processing shows iterating over all files in `~/Maildir/new/*` and moving each processed file to `~/Maildir/cur/`, which is handling mailbox content beyond merely ignoring InterClaw-unrelated messages. That is a direct contradiction at the intent/documentation level.

Static analysis

No suspicious patterns detected.