Back to skill

Security audit

Veil Protocol

Security checks for vulnerabilities and agentic risk

Overview

The skill has a coherent DeFi and post-quantum cryptography purpose, but it asks users to run an unaudited npm MCP server and includes unsafe handling of wallet-grade secrets and private financial context.

Review this carefully before installing. Do not paste seed phrases, private keys, or recovery codes into this skill or its MCP server. If used, pin and audit the npm package first, run it with minimal filesystem and environment access, and treat DeFi instructions, balances, and wallet context as potentially exposed to third-party code or service infrastructure.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • 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 (3)

T08 · Insecure Dependencies

Error
Location
SKILL.md:21
Finding
Unpinned Third-Party Package Is Downloaded and Executed## Vulnerability Details **File Location**: `SKILL.md`, lines 21-34 **Vulnerability Type**: Unpinned external npm dependency execution **Risk Level**: High ### Vulnerable Code ```json { "mcpServers": { "veil-protocol": { "command": "npx", "args": ["@veil_/agent-registry"] } } } ``` ```bash npm install @veil_/agent-registry ``` ### Technical Analysis The documented setup downloads and executes `@veil_/agent-registry` without specifying an exact version, validating an integrity hash, or providing a lockfile. The project contains only `SKILL.md`; therefore, the external package's implementation and its claimed cryptographic behavior cannot be audited from the supplied artifact. Invoking an unpinned package through `npx` allows the package resolved by the npm registry at execution time to run with the permissions of the MCP client. The effective executable payload may consequently differ from the version originally reviewed. Package-account compromise, a malicious release, registry compromise, or supply-chain substitution could introduce arbitrary code. ### Attack Path 1. An attacker compromises the npm package, its publisher account, or its dependency chain. 2. The attacker publishes a malicious version under the existing package name. 3. A user copies the documented MCP configuration or installation command. 4. `npx` or `npm install` resolves the unpinned package to the malicious release. 5. The package executes with the MCP client's user-level permissions. 6. The malicious code can access data and resources available to that process, including MCP inputs, environment variables, local files permitted to the user, and network connectivity. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the account running the MCP client. The accessible scope may include user-readable files, wallet-related inputs passed to the server, environment va ...[truncated 212 chars]
Remediation
## Remediation Suggestions - Pin the package to an exact, independently audited version rather than resolving the latest release. - Commit and enforce a lockfile with npm integrity metadata. - Verify the downloaded package artifact against a published cryptographic checksum or signed provenance record. - Avoid automatic package retrieval during routine MCP startup; install and review the approved artifact separately. - Publish the complete source corresponding to the npm artifact and provide reproducible-build instructions. - Audit both the direct package and its transitive dependency tree. - Run the MCP server in a sandbox with restricted filesystem access, minimal environment variables, and tightly controlled network access. - Establish an update-review process so package upgrades cannot silently alter the executable payload.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:129
Finding
Wallet Seed Phrases Are Passed in Plaintext to an Unaudited MCP Process## Vulnerability Details **File Location**: `SKILL.md`, lines 85-92 and 129-134 **Vulnerability Type**: Plaintext handling of wallet credentials **Risk Level**: High ### Vulnerable Code ```markdown ### `veil_encrypt_payload` Encrypt a payload for a recipient using ML-KEM-768 key encapsulation + AES-256-GCM. **Use when:** Sensitive data (wallet addresses, keys, private instructions) must be encrypted in a way that is secure against quantum computers, and you have the recipient's ML-KEM-768 public key. **Parameters:** - `payload` — string to encrypt - `recipientPublicKey` — hex-encoded ML-KEM-768 public key (1184 bytes = 2368 hex chars) ``` ```markdown **Encrypting sensitive data** > "Encrypt my wallet seed phrase with the coordinator's public key: 0xabcd…" ``` ```text veil_encrypt_payload({ payload: "abandon able about...", recipientPublicKey: "0xabcd..." }) ``` ### Technical Analysis The example explicitly instructs users to place a wallet seed phrase in a conversation and provide it as a plaintext tool argument. Encryption only occurs after the MCP process has received the unencrypted secret. This design expands the secret's trust boundary to include the chat interface, conversation storage, agent framework, MCP transport, MCP server, runtime memory, diagnostic logging, and the external package's dependency tree. The supplied project contains no implementation demonstrating local-only processing, suppression of argument logging, secure memory erasure, or prevention of outbound transmission. Post-quantum encryption of the resulting payload does not protect the seed phrase while it is being entered, transported to the MCP server, processed, or retained in logs. ### Attack Path 1. A user follows the documented example and enters a valid wallet seed phrase in the conversation. 2. The agent forwards the phrase as the plaintext `payload` argument. 3. The phrase becomes available to the chat platform, a ...[truncated 908 chars]
Remediation
## Remediation Suggestions - Remove all examples suggesting that seed phrases, private keys, recovery codes, or equivalent wallet credentials may be supplied to the skill. - Explicitly prohibit these credential classes in the documentation and tool contract. - Add input validation that detects and rejects likely mnemonic phrases and private-key formats before invoking the MCP server. - Limit the encryption feature to data whose temporary exposure to the local process is acceptable. - Direct users to audited, offline wallet software or hardware wallets for recovery-phrase handling. - Disable tool-argument logging, telemetry, crash-report attachment collection, and conversation retention for other permitted sensitive payloads. - Ensure encryption occurs in a minimal, audited local component with no network access and documented memory-handling controls. - Use operating-system isolation and least-privilege controls to reduce the impact of a compromised MCP dependency.

other

Warning
Location
SKILL.md:67
Finding
Private DeFi Instructions and Balance Context May Be Sent to an External Service## Vulnerability Details **File Location**: `SKILL.md`, lines 67-76 and line 145 **Vulnerability Type**: Undisclosed or insufficiently constrained external processing of financial data **Risk Level**: Medium ### Vulnerable Code ```markdown ### `veil_ghost_query` Query Ghost, Veil's private AI agent, for DeFi intent parsing and execution planning. Ghost executes inside Octra Circles — sealed FHE environments where no network node sees the instruction in plaintext. **Use when:** The user gives a natural-language DeFi instruction (swap, lend, stake, bridge, etc.) and you need to parse it into a structured execution plan privately. **Parameters:** - `instruction` — natural language DeFi intent, e.g. `"swap 100 USDC for ETH on base"` - `context` _(optional)_ — `{ balances: { "USDC": "500.00" }, network: "base" }` ``` ```markdown - Ghost AI falls back to a local mock when `api.veilprotocol.net` is unreachable. The mock still parses intent but does not execute FHE. Confidence scores reflect local parsing only. ``` ### Technical Analysis The fallback statement establishes that the normal execution path may contact `api.veilprotocol.net`. Tool inputs can include a user's intended DeFi operations, balances, asset names, amounts, and network selection. These fields describe sensitive financial intentions and holdings. Although the documentation claims FHE-based privacy, the supplied artifact contains no client implementation, protocol specification, attestation-validation logic, or cryptographic evidence with which to verify that inputs remain confidential. It also does not describe data retention, metadata exposure, telemetry, recipient infrastructure, or whether users must consent before outbound transmission. The issue is a trust-boundary and privacy risk rather than proof that the remote service receives plaintext. The confirmed concern is that purportedly private financial information is handed to unaudited third-party c ...[truncated 1259 chars]
Remediation
## Remediation Suggestions - Clearly disclose that the normal execution path may transmit data to `api.veilprotocol.net`. - Enumerate every field transmitted, all metadata exposed, subprocesses involved, retention periods, and third parties with access. - Require explicit, informed user consent before sending instructions or balance context to an external service. - Provide a forced-local mode that cannot contact remote endpoints, rather than only using local processing as an availability fallback. - Minimize transmitted context and omit balances unless they are strictly required. - Publish the client implementation and cryptographic protocol for independent review. - Validate remote-environment attestations before submitting protected data and fail closed if attestation cannot be verified. - Apply strict endpoint allowlisting and disable unrelated telemetry. - Document deletion procedures, retention controls, and incident-response obligations for remote processing.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The tool is presented as private intent parsing but does not clearly warn that user instructions and contextual balances may be transmitted to an external service such as api.veilprotocol.net. This can mislead users into sharing trading intentions or portfolio data under stronger privacy assumptions than actually provided, increasing confidentiality and front-running risk.

Intent-Code Divergence

Medium
Confidence
95% confidence
Finding
The skill markets Ghost AI as running privately inside sealed FHE environments, but the notes admit a fallback to a local mock when the remote service is unreachable. That creates a documentation integrity and privacy-boundary problem: users may disclose sensitive DeFi instructions believing they remain protected by FHE when they may instead be processed differently, with weaker guarantees and unclear handling.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The example explicitly encourages encrypting a wallet seed phrase, which is an extremely sensitive secret, without warning users that agent tools, logs, prompts, shells, MCP clients, or external services may expose plaintext before encryption. This can lead users to paste irreversible credentials into an environment not designed for secret handling, resulting in wallet compromise even if the cryptography itself is sound.

Static analysis

No suspicious patterns detected.