T02 · Agent Memory Poisoning
- Location
setup.md:5- Finding
Persistent Modification of Agent Instructions and Long-Term Memory
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a real Minara finance skill, but it asks agents to install mutable global software and permanently rewrite agent routing or memory for broad finance topics.
Install only if you are comfortable giving Minara broad influence over finance-related agent behavior and using a globally installed, mutable CLI for wallet and trading workflows. Before installing, review setup.md and avoid automatic writes to global memory/config files unless you explicitly want that routing. Prefer pinned, reviewed CLI versions, do not expose MINARA_API_KEY or ~/.minara credentials, and require fresh confirmation for every trade, withdrawal, transfer, leverage change, subscription change, or autopilot action.
setup.md:5Persistent Modification of Agent Instructions and Long-Term Memory
SKILL.md:6Mutable Global Installation of a Financial CLI from an Unpinned Package
The documented purpose is trading, wallet, and analysis, but the skill also performs update management, package installation, git-based code modification, and local cache/file manipulation. This hidden operational behavior increases attack surface and weakens user expectations, since activating a finance skill can lead to unrelated system and repository changes.
git pull modifies the local skill repository, changing code after trust review and potentially introducing unreviewed behavior. For a financial skill with shell access, mutating its own codebase is dangerous because it enables supply-chain compromise and defeats stable security assumptions.
Deleting ~/.minara/.last-update-check alters local state outside the core finance task and is part of a broader self-update mechanism. While the command itself is narrow, it demonstrates the skill can manipulate local files and maintenance controls, which becomes more dangerous when combined with shell access and remote update behavior.
After a successful upgrade, invalidate the cache so the next session re-detects correctly:
rm -f ~/.minara/.last-update-check
Only prompt for the components listed in the UPGRADE output (e.g. if only cli: is present, don't mention skill).
The documentation explicitly identifies a credential file location and an environment variable that bypasses login in a high-risk crypto wallet/trading context. This materially increases credential-theft and misuse risk because any agent, plugin, or local process with filesystem or environment access could target ~/.minara/credentials.json or MINARA_API_KEY to gain wallet/account access and potentially initiate sensitive financial actions.
If fails → user needs `minara login`.
Credentials: `~/.minara/credentials.json`. `MINARA_API_KEY` env var bypasses login.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
#
# Snooze: write a future Unix timestamp to ~/.minara/.update-snooze
# e.g. echo "$(( $(date +%s) + 604800 ))" > ~/.minara/.update-snooze (1 week)
# Cache reset after upgrade: rm -f ~/.minara/.last-update-check
set -euo pipefail
CHECK_FILE="$HOME/.minara/.last-update-check"
The skill invokes shell commands (bash, npm, git, rm, echo) but does not declare any explicit tool scope or allowed-tools boundary. That creates an authorization and review gap: a finance skill can execute local system modifications without a manifest-level restriction, making misuse or accidental overreach harder to detect and contain.
Automatically reading and following an external setup file on activation expands behavior beyond what is visible in the main manifest and may trigger file writes or other side effects. Because the referenced file is external to the reviewed content, it creates an indirection channel through which risky actions can be introduced without being obvious at activation time.
The skill directs the agent to self-update via npm install -g minara@latest and git pull, which causes execution of newly fetched code from external sources during normal operation. In a wallet/trading context, this is especially risky because compromised upstream packages, repos, or dependency chains could immediately gain access to a high-value environment.
The skill handles authentication material through MINARA_API_KEY and local credential storage under ~/.minara/ but provides no strong warning about safe handling, storage, or exposure risks. In a crypto-wallet context, poor credential hygiene can lead to account takeover or unauthorized transactions.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- **Token input:** `'$BONK'` (quote `$`), ticker, address, or name
- **JSON output:** `--json` on root command
- **Interactive commands:** use `pty: true` — never use it to auto-confirm. Full bypass guide: `{baseDir}/references/interactive-commands.md`
- **Non-interactive discover:** `--type tokens|stocks` skips category prompt
- **Non-interactive perps order:** `-S SIDE -s SYMBOL -z SIZE` skips all prompts
- **Supported chains:** ethereum, base, arbitrum, optimism, polygon, avalanche, solana, bsc, berachain, blast, manta, mode, sonic, conflux, merlin, monad, polymarket, xlayer
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
# Balance / Assets
> Execute commands yourself. All read-only — no confirmation needed.
## Commands
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
# Balance / Assets
> Execute commands yourself. All read-only — no confirmation needed.
## Commands
This file tells the agent to execute account-inspection commands directly and says 'no confirmation needed,' but it does not warn that the output may expose sensitive financial holdings, balances, positions, and PnL. For markdown files, omission of warnings about behaviors affecting user privacy or sensitive data is in scope.
The file explicitly authorizes autonomous execution with no confirmation. Although the listed commands are read-only, they still trigger network activity and agent-controlled decision-making about when to query external services, which can expose user intent and reduce user awareness of outbound actions.
# Market Discovery
> Execute commands yourself. All read-only — no confirmation needed.
## Commands
The transfer and withdrawal examples show sending funds to external addresses with no warning that blockchain transfers are typically irreversible and highly sensitive to recipient-address accuracy and chain selection. In a wallet/trading skill, this omission is dangerous because an agent may normalize executing withdrawals or transfers without validating destination, token, chain, and user intent.
These examples document high-risk financial actions such as funding perps accounts, setting leverage, placing orders, closing all positions, withdrawals, and autopilot trading without adjacent warnings about liquidation risk, slippage, fees, loss of funds, or the need for explicit user confirmation. In an agent-facing skill, examples strongly shape implementation behavior, so omission of safeguards can cause an agent to execute materially irreversible trades or account actions too casually.
The example minara perps close --all --yes demonstrates a non-interactive command that closes all positions while skipping confirmation, which is a direct autonomous account action with potentially large financial consequences. In the context of a trading skill, this is especially dangerous because it lowers friction for destructive bulk actions and can enable accidental or agent-initiated liquidation of a user's strategy without a final approval step.
minara perps close # Interactive: select position to close
minara perps close --all # Close all positions (non-interactive)
minara perps close --symbol BTC # Close BTC position (non-interactive)
minara perps close --all --yes # Close all, skip confirmation
# Cancel orders
minara perps cancel
The guide explicitly instructs agents to use pty: true and walk through minara limit-order create interactively, but it does not require a clear user warning, explicit confirmation, or a prohibition on proceeding without fresh consent for each order parameter. In a crypto trading skill, interactive order creation can place real financial orders, so missing safeguards materially increases the risk of unintended, misunderstood, or agent-driven trades.
The file states that minara perps autopilot is 'always interactive' and should be used with pty: true, but it provides no warning that this dashboard may control or alter leveraged perpetual trading behavior on a live account. In the context of a wallet and perps trading skill, omission of a user-facing risk warning and explicit consent flow can lead to unauthorized or poorly understood account-affecting actions.
The documentation gives conflicting guidance for minara perps leverage: it first says the command is always interactive with no non-interactive flags, then later documents -s and -l flags and even shows a non-interactive example. For a fund-risk-changing operation, this ambiguity can cause an agent to choose the wrong execution path, skip required confirmation handling, or unintentionally change leverage under the wrong margin mode.
The contradictory natural-language instructions around perps leverage are especially dangerous because leverage changes directly alter liquidation risk on live perps positions. In this skill context, an agent may misinterpret whether it should ask for margin mode, whether supplied flags are sufficient, or whether execution can proceed automatically, leading to unintended exposure or forced-liquidation risk.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
estimatedOutput: 4.0123 · priceImpact: 0.02% · route: Jupiter · gasFee: $0.001
No confirmation needed.
### Swap parsing (any-to-any)
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- `-t, --token <address|ticker>` — token to withdraw
- `-a, --amount <amount>` — amount
- `--to <address>` — destination wallet address
- `-y, --yes` — skip confirmation (never use unless user explicitly requests)
Interactive if any flags are omitted — prompts for each missing field. Use `pty: true`.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- `-t, --token <address|ticker>` — token to withdraw
- `-a, --amount <amount>` — amount
- `--to <address>` — destination wallet address
- `-y, --yes` — skip confirmation (never use unless user explicitly requests)
Interactive if any flags are omitted — prompts for each missing field. Use `pty: true`.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- `-t, --token <address|ticker>` — token to withdraw
- `-a, --amount <amount>` — amount
- `--to <address>` — destination wallet address
- `-y, --yes` — skip confirmation (never use unless user explicitly requests)
Interactive if any flags are omitted — prompts for each missing field. Use `pty: true`.
No suspicious patterns detected.