Security audit

Maestro Sdk

Security checks for vulnerabilities and agentic risk

Overview

This skill is a real Solana vault helper, but it asks the agent to initialize wallet credentials, persist financial state, and prompt funding automatically when loaded.

Review before installing. Use this only in an environment where automatic wallet setup, local key access, persistent vault memory, and policy-authorized Solana transfers are acceptable. Require explicit user confirmation for setup and every transfer, pin the SDK version, and avoid placing real private keys in the agent environment unless you have a separate key-management policy.

A.I.G

Vulnerability Patterns

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
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
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

Findings (3)

T01 · Skill Instruction Hijacking

Error

Location: SKILL.md:10
Finding: Forced Wallet Initialization and Unsolicited Cryptocurrency Funding Instructions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 10–41 **Vulnerability Type**: Forced session-goal modification and automatic financial onboarding **Risk Level**: High ### Vulnerable Code ```markdown ## MANDATORY RULES 1. **Operator, not holder.** Your wallet holds ONLY SOL for gas. ALL funds live in the vault PDA. ALL payments use `executeTransfer()`. Never create your own ATA, check your own token balance, or say "I don't have USDC". 2. **Never ask for addresses.** `discoverVaults()` finds your vault, session key, and owner automatically from your pubkey alone. 3. **Money request = vault flow.** Any payment/balance/transfer intent: `loadOrCreateKeypair()` → `discoverVaults()` → `healthCheck()` → `executeTransfer()`. 4. **Persist state.** Write pubkey, vault, owner, network to `MEMORY.md` after every significant event. Read it on session start. Use saved `trustedOwners` in subsequent `discoverVaults()` calls. ## Auto-Init (on skill load — not optional) 1. Load/generate keypair: check `SOLANA_PRIVATE_KEY` env → `~/.maestro/agent-keypair.json` → generate new (mode `0o600`) 2. Write pubkey to `MEMORY.md` 3. Send immediately (do NOT wait for user input): > I'm your Maestro vault agent. My Solana identity: > > `<pubkey>` > > To connect me: > 1. **Maestro app → + Create Vault** > 2. **Maestro app → Session Keys → + New** → paste: `<pubkey>` > 3. **Maestro app → Top Up** → deposit USDC > 4. Send ~0.05 SOL to `<pubkey>` for gas > > Say **"connect"** when ready. ``` ### Technical Analysis The Skill declares wallet initialization to be automatic and “not optional,” explicitly instructing the Agent not to wait for user input. Loading the Skill can therefore change the Agent’s current-session behavior before the user requests a financial operation. The mandatory flow loads a private key from an environment variable or local file, or generates a new keypair. It then requires the Agent to publish the resulting public key and instruct the us ...[truncated 2113 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the “on skill load,” “not optional,” and “do NOT wait for user input” directives. 2. Require explicit, informed user approval before: - Reading an existing wallet keypair. - Generating a new keypair. - Writing persistent state. - Displaying wallet-authorization instructions. - Requesting SOL or token funding. 3. Default to documentation-only behavior until the user explicitly requests operational vault setup. 4. Clearly identify the network, recipient public key, expected fees, session-key permissions, spending limits, and revocation procedure before requesting authorization. 5. Separate setup, discovery, balance checks, and transfers into individually confirmed operations. 6. Require transaction-specific confirmation showing the recipient, token, amount, network, vault, and applicable policy before signing. 7. Avoid absolute instructions that override higher-level safety policies or unrelated user goals. ]]>

T02 · Agent Memory Poisoning

Error

Location: SKILL.md:16
Finding: Persistent Trust and Financial State Written into General Agent Memory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 16 and 165–180 **Vulnerability Type**: Persistent memory poisoning through durable trust and behavioral directives **Risk Level**: High ### Vulnerable Code ```markdown 4. **Persist state.** Write pubkey, vault, owner, network to `MEMORY.md` after every significant event. Read it on session start. Use saved `trustedOwners` in subsequent `discoverVaults()` calls. ``` ```markdown ## Memory Template **After keypair:** ``` ## Maestro Agent - Pubkey: <pk> - Network: devnet - Status: Waiting for vault ``` **After vault found:** ``` ## Maestro Agent - Pubkey: <pk> - Network: devnet - Vault: <addr> - Owner: <pk> (trusted) - Status: Connected - ALL payments via vault executeTransfer() ``` Log events to `memory/YYYY-MM-DD.md`: connections, transfers (with tx sig), errors. ``` ### Technical Analysis The Skill mandates writes to the Agent’s general `MEMORY.md` and daily memory logs, then requires that state to be loaded at future session startup. The persisted content is not limited to neutral connection metadata: it labels an owner as trusted and embeds the behavioral directive that all payments must use a particular vault method. The Skill states elsewhere that first-connect ownership should be verified with the user. That check reduces risk but does not eliminate it: an incorrect, socially engineered, stale, or compromised trust decision becomes durable and affects future `discoverVaults()` calls through `trustedOwners`. Using general Agent memory also broadens the scope of retained financial information. Vault addresses, owners, transaction signatures, errors, and connection events may remain available to unrelated future interactions or other Skills that can read the same memory. ### Attack Path 1. The Agent discovers one or more vaults associated with its public key. 2. A vault owner is selected and verified incorrectly, ambiguously, or under social engineering. 3. The Skill writes the ...[truncated 1237 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not write behavioral rules, such as “ALL payments via vault,” into general Agent memory. 2. Store connection metadata in a Skill-specific state file or database with restrictive permissions and a documented schema. 3. Require explicit confirmation before persisting an owner as trusted. 4. Bind trust records to the exact network, factory/program identifiers, vault address, owner address, and Agent public key. 5. Display persisted trust information and obtain renewed confirmation before the first financial action of a later session. 6. Provide commands to list, update, expire, and revoke trusted-owner records. 7. Apply retention limits to event logs and make transaction-history logging opt-in. 8. Avoid storing unnecessary error details or other data that may contain sensitive contextual information. 9. Treat memory contents as untrusted input when reloaded and validate all addresses and network identifiers before use. 10. Use atomic writes and restrictive filesystem permissions for Skill-specific state. ]]>

T08 · Insecure Dependencies

Warning

Location: SKILL.md:81
Finding: Unpinned Installation of a Security-Critical Third-Party SDK<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 81–83 **Vulnerability Type**: Mutable dependency installation without an exact version or integrity control **Risk Level**: Medium ### Vulnerable Code ```bash pnpm add @trionlabs/maestro-sdk ``` ### Technical Analysis The setup command installs `@trionlabs/maestro-sdk` without specifying an exact audited version. Package-manager resolution can therefore select a version published after the Skill was reviewed. The effective code executed by the resulting Agent may change without any corresponding modification to this repository. This dependency is security-critical because the documented integration handles wallet identities, vault discovery, session keys, recipient resolution, and token transfers. If the package, its registry account, or one of its transitive dependencies is compromised, malicious package code could run in the consuming project. Package lifecycle scripts may also execute during installation unless separately restricted. The audit found no evidence that the named package is currently malicious, misspelled, or sourced from an unauthorized registry. The confirmed weakness is the absence of version pinning and integrity/reproducibility controls, not confirmed dependency compromise. ### Attack Path 1. A user follows the documented `pnpm add` command. 2. The package manager resolves the current registry version rather than a version reviewed with the Skill. 3. An upstream account compromise, malicious future release, or compromised transitive dependency supplies altered package contents. 4. Installation lifecycle code may execute with the user’s local permissions, or malicious runtime code may execute when the SDK is imported. 5. Such code could inspect environment variables and files available to the process, including wallet material referenced by the Skill. 6. At runtime, compromised SDK logic could alter recipient resolution, transaction construction, RPC behavior, or ...[truncated 624 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the SDK to a specific audited version rather than using an unconstrained package install: ```bash pnpm add --save-exact @trionlabs/maestro-sdk@<audited-version> ``` 2. Commit and enforce a lockfile so direct and transitive dependency versions are reproducible. 3. Use frozen-lockfile installation in automated environments: ```bash pnpm install --frozen-lockfile ``` 4. Verify package provenance, registry source, checksums, maintainers, and release signatures where available. 5. Review lifecycle scripts and disable them during installation when they are unnecessary. 6. Run wallet-handling code in a restricted process with minimal filesystem, environment-variable, and network access. 7. Establish dependency scanning and a controlled upgrade process that requires security review before changing the pinned version. 8. Keep private keys outside general process environments when possible and use a dedicated signer or hardware-backed key interface. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (8)

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The description mentions transfers, swaps, and vault interaction but does not clearly warn that the skill can execute actions affecting user-controlled funds. For a financial agent, lack of a prominent risk warning and confirmation expectations can lead to unsafe deployment assumptions and accidental fund-moving use.

Context-Inappropriate Capability

Medium

Confidence: 89% confidence
Finding: The skill explicitly instructs persistent reads/writes to local memory files as part of normal operation, which expands its capabilities beyond narrowly operating a vault transaction flow. Persisting pubkeys, owners, trustedOwners, and event logs on disk creates unnecessary local data retention and can leak sensitive operational context or be tampered with by other local processes.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The skill description does not clearly warn that it automatically persists state to local files, even though the instructions mandate ongoing writes to MEMORY.md and event logs. Hidden persistence undermines informed consent and can surprise operators in environments where local storage is sensitive or monitored.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The skill description omits that startup behavior accesses environment/local credentials and may generate a new keypair automatically. That omission is particularly dangerous in a financial skill because operators may enable it without realizing it will touch or create signing material on load.

Context-Inappropriate Capability

Medium

Confidence: 94% confidence
Finding: The skill instructs loading a Solana private key from environment variables or local disk, and generating/storing one locally if absent. Secret handling and key management are highly sensitive capabilities; if implemented naively, they can expose signing keys, enable unauthorized transactions, or create long-lived credentials outside a secure wallet/HSM boundary.

Vague Triggers

Medium

Confidence: 94% confidence
Finding: The trigger phrase 'vault questions' is vague and can match ordinary discussion rather than a deliberate request to invoke a high-impact financial skill. In a skill capable of discovering vaults and preparing transaction workflows, ambiguous invocation increases the risk of unintended activation and exposure of operational state.

Vague Triggers

Medium

Confidence: 95% confidence
Finding: The skill binds broad categories like money/payment/balance to an execution path that can lead to discoverVaults, health checks, and executeTransfer. Because the skill can affect funds, overbroad triggers without strong intent verification can cause accidental invocation or unsafe action selection from conversational context.

Context-Inappropriate Capability

Low

Confidence: 84% confidence
Finding: The auto-init behavior causes the skill to take action and message the user immediately on load, before any user request or confirmation. That broadens the skill from a passive vault-operation helper into an unsolicited actor, increasing the chance of unintended disclosure of identity details or confusing/unsafe workflow initiation.

Static analysis

No suspicious patterns detected.