Why Your AI Agent Needs a Permissions System (Before It Gives Away $250,000)

When an AI Agent Gives Away $250,000 in Crypto

On February 22, 2026, an autonomous AI agent called Lobstar Wilde did something its creator never intended: it sent 52.4 million tokens — roughly $250,000 in value — to a complete stranger.

The agent was running on OpenClaw, connected to a live Solana wallet, with the goal of growing a $50,000 portfolio through autonomous trading. A user on X replied to the bot with a story about needing "4 SOL for my uncle's tetanus treatment" and included a wallet address.

The bot decided to help. Due to a combination of decimal confusion and lost conversational state after a crash, it didn't send 4 SOL worth of tokens. It sent approximately 5% of the entire LOBSTAR token supply. The recipient cashed out immediately for around $40,000.

This wasn't a sophisticated attack. It was a sad story in a tweet reply.

Prompt Injection, Social Engineering, and Malicious Skills

Lobstar Wilde is not an isolated case. The pattern repeats across the AI agent ecosystem:

Freysa: $47,000 lost to prompt injection

In November 2024, an AI agent called Freysa was deployed as a game. It controlled 13.19 ETH (roughly $47,000) and was given one rule: never transfer funds under any circumstances.

After 482 attempts by 195 participants, someone found the exploit. They told Freysa it was in a "new admin session" and redefined the transfer function's purpose — claiming it was for receiving funds, not sending them. Freysa called the function, sending the entire prize pool to the attacker.

The agent's restriction was in its system prompt. The system prompt was bypassed.

OpenClaw malicious skills: 1,184 wallet-targeting packages

In February 2026, security researchers discovered over 1,100 malicious "skills" on ClawHub, OpenClaw's skill registry. Many specifically targeted crypto wallets, deploying the AMOS stealer malware to exfiltrate private keys from 60+ wallet applications including MetaMask, Exodus, and Ledger Live.

The malicious skills passed initial review because the OpenClaw/Clawdbot skill system has no sandboxing — skills run with the same permissions as the user. A skill that claims to help with productivity could silently exfiltrate wallet files. Cisco scanned 31,000 ClawHub skills and found 26% contained at least one vulnerability.

Cisco's security team assessed OpenClaw and described it as "an absolute nightmare" from a security perspective. Palo Alto Networks warned of a "lethal trifecta": access to private data, exposure to untrusted content, and the ability to take external actions. Independent researcher Lucas Valbuena assigned OpenClaw a security score of 2 out of 100.

The common failure

Every one of these incidents shares the same root cause: the agent's restrictions existed only in words — in prompts, in instructions, in documentation — where they can be overridden, forgotten, or manipulated.

Prompt injection is an unsolved problem in AI. No amount of prompt engineering can guarantee that an LLM will refuse to execute a harmful instruction. The model's behaviour is probabilistic, not deterministic. Adding "never transfer funds" to a system prompt is a suggestion to the model, not a constraint on the system.

Code-Level AI Agent Permissions: Beyond Prompt Engineering

There is a straightforward way to prevent an AI agent from executing an operation: make the operation unavailable.

If the tool doesn't have a "transfer" command, the agent can't transfer. It doesn't matter what's in the prompt, what conversation the agent has, or what instructions it receives. The capability simply doesn't exist.

This is how Sol CLI's permissions system works.

How it works

Sol CLI uses a [permissions] section in its configuration file (~/.sol/config.toml) to control which commands are registered:

[permissions]
canTransfer = false
canSwap = false
canBurn = false
canExportWallet = false

When a permission is set to false, the corresponding command is not registered with the CLI framework. It doesn't appear in --help. It can't be invoked. If the agent tries to run it, the response is "unknown command" — identical to running a command that has never existed.

This is fundamentally different from a prompt-level restriction:

What you can control

Sol CLI provides thirteen permission flags, each gating a specific set of operations:

All read operations — checking balances, viewing prices, listing positions, taking portfolio snapshots — are always available regardless of permissions.

Practical configurations

Monitor-only agent — can observe but never transact:

[permissions]
canTransfer = false
canSwap = false
canStake = false
canWithdrawStake = false
canLend = false
canWithdrawLend = false
canBurn = false
canCreateWallet = false
canRemoveWallet = false
canExportWallet = false

The agent can run sol wallet balance, sol token price, sol portfolio, sol lend rates, and any other read command. It can research and report. It cannot move a single lamport.

Trading agent — can buy and sell but not withdraw:

[permissions]
canSwap = true
canTransfer = false
canExportWallet = false

The agent can swap tokens on DEXes — buy BONK with USDC, sell SOL for USDC — but it cannot send tokens to any external address. Even if an attacker convinces the agent to "send all funds to this address," the command doesn't exist. The worst case is the agent making bad trades, not losing custody of funds.

Yield agent — can deploy capital but not retrieve it:

[permissions]
canStake = true
canLend = true
canBorrow = false
canWithdrawStake = false
canWithdrawLend = false
canTransfer = false

The agent can stake SOL, deposit USDC into lending protocols, and deposit into earn vaults. It cannot withdraw, unstake, or borrow — those operations require you to temporarily enable the permissions and run them yourself.

Transaction Limits: Capping AI Agent Spending

Permissions control what an agent can do. Transaction limits control how much it can do in a single operation or a single day.

[limits]
maxTransactionUsd = 500
maxDailyUsd = 2000

Limits apply to swaps, sends, staking, lending deposits, borrows, DCA creation, and limit orders. They do not apply to withdrawals (you're retrieving your own funds), MEV claims, or read operations.

If Lobstar Wilde's owner had set maxTransactionUsd = 1000, the $250,000 send would have been rejected instantly — even if canTransfer were enabled.

Missing a setting means no limit. Start with conservative values and adjust upward as you gain confidence in the agent's behaviour.

Token and Address Allowlists for AI Agent Wallets

Permissions and limits still leave the agent free to interact with any address and any token. Allowlists narrow that further.

Address allowlist

[allowlist]
addresses = "DRtXHDgC312wpNdNCSb8vCoXDcofCJcPHdAynKGz7Vr,7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU"

When set, sol token send is restricted to the listed addresses plus the agent's own wallets (transfers between your own wallets are always allowed). Any send to an unlisted address is rejected.

This means even if an attacker convinces the agent to transfer funds and canTransfer is enabled and the amount is within limits — the transfer still fails unless the recipient is on the allowlist.

Token allowlist

[allowlist]
tokens = "So11111111111111111111111111111111111111112,EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v,DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"

When set, both the input and output token must be on the list for swaps, DCA orders, and limit orders. The agent cannot be tricked into buying a scam token or selling into an illiquid pair — if the token isn't on the list, the command is rejected.

Accepts mint addresses or symbols (SOL, USDC). Prefer mint addresses — symbols are convenient but a malicious token could share a ticker with a legitimate one.

Combined example

A trading agent that can only swap between SOL, USDC, and BONK, with a $500 per-trade cap and $2,000 daily limit:

[permissions]
canSwap = true
canTransfer = false
canExportWallet = false

[limits]
maxTransactionUsd = 500
maxDailyUsd = 2000

[allowlist]
tokens = "So11111111111111111111111111111111111111112,EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v,DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263"

Three layers — permissions, limits, allowlists — all enforced in code, all immune to prompt injection.

How Code-Level Permissions Would Have Saved $250,000

Let's replay the Lobstar Wilde incident with a permissions system in place.

The agent was meant to trade — buy and sell tokens to grow a portfolio. It did not need to send tokens to arbitrary wallet addresses.

With Sol CLI, the owner would configure:

[permissions]
canSwap = true           # the agent can trade
canTransfer = false      # the agent cannot send to external wallets
canExportWallet = false  # the agent cannot access the private key

When the agent, convinced by a sad story on X, attempts to send tokens to the stranger's wallet:

sol token send 52439000 lobstar 7nY...xyz

The response:

error: unknown command 'send'

The command doesn't exist. The tokens don't move. The $250,000 stays in the wallet.

No prompt engineering required. No "but I was told to by the user." The tool physically cannot execute the operation.

Defence in Depth: Securing AI Agents on Solana

Permissions, limits, and allowlists are three layers. A responsible approach to AI agent security uses all of them together:

1. Restrict operations (permissions)

Disable everything the agent doesn't need. If it doesn't need to transfer tokens, remove the capability entirely.

2. Cap spending (transaction limits)

Set maxTransactionUsd and maxDailyUsd so that even permitted operations can't exceed your risk tolerance in a single action or a single day.

3. Restrict targets (allowlists)

Limit which addresses can receive funds and which tokens can be traded. This prevents the agent from interacting with unknown contracts or sending to attacker-controlled wallets.

4. Use a dedicated wallet

Create a separate wallet for agent operations with limited funds. Don't give the agent access to your main wallet.

sol wallet create --name agent-trading

5. Lock the configuration

After setting up permissions, limits, and allowlists, lock the config so the agent can't change its own constraints:

sol config lock

After locking, security settings can only be changed by a human editing ~/.sol/config.toml directly. The agent cannot unlock itself — sol config set will refuse to modify locked settings.

6. Monitor activity

Use Sol CLI's transaction log, portfolio snapshots, and security status to review what the agent has done:

sol wallet history
sol portfolio compare
sol portfolio pnl
sol config status

sol config status shows the full security posture at a glance: which permissions are enabled, current limits with daily usage, active allowlists, whether the config is locked, and warnings about potential risks (like missing limits or a public RPC endpoint).

7. Restrict filesystem access

Do not grant agents read or write access to ~/.sol/. This directory contains your private keys and security configuration. Agents should only interact with Solana through sol CLI commands, never by reading config or key files directly.

Sol CLI's permissions, limits, and allowlists operate at the CLI level. They do not prevent other software on the same machine from reading key files. Any tool, MCP server, plugin, or script running under the same OS user account can read ~/.sol/wallets/ directly. If you grant an agent access to tools that can read arbitrary files or execute shell commands beyond the Sol CLI, those tools can extract your private keys regardless of Sol CLI permissions.

8. Review the agent's skill access

If you're using OpenClaw (Clawdbot) or another platform that supports third-party skills, be selective about what you install. Cisco found that 26% of scanned ClawHub skills contained at least one vulnerability. Stick to skills from known authors with clear documentation — and check that the skill's declared requirements match its actual behaviour.

The Broader Lesson for AI Agent Security

The AI agent ecosystem is moving fast. OpenClaw (originally launched as Clawdbot) went from zero to 140,000 GitHub stars in a matter of weeks. People are building OpenClaw bots and Claude Code agents that manage calendars, send emails, monitor smart homes, and trade crypto.

Financial operations are the highest-stakes use case for these agents. When an agent sends an email to the wrong person, it's embarrassing. When it sends $250,000 to the wrong wallet, it's devastating.

The industry is converging on a few principles for agent security:

1. Least privilege: Give agents only the permissions they need for their specific task.
2. Tool-level enforcement: Don't rely on the AI deciding to be safe. Remove the unsafe capabilities from the tool itself.
3. Human-in-the-loop for high-value operations: Require manual approval for transactions above a threshold.
4. Audit logging: Record everything the agent does for review.
5. Isolated environments: Separate agent wallets from personal wallets, agent data from personal data.

Sol CLI was built with these principles. Permissions enforce least privilege at the tool level. Transaction limits and allowlists add spending and targeting constraints. The transaction log provides audit. Named wallets enable isolation. And sol config lock ensures the agent can't modify its own constraints — only a human editing the config file directly can change them.

Prompt injection may be an unsolved problem. But you don't need to solve prompt injection if the agent can't execute the dangerous operation in the first place.

Getting Started with Sol CLI Permissions

1. Install Sol CLI: npm install -g @solana-compass/cli
2. Create a dedicated agent wallet: sol wallet create --name agent
3. Configure permissions — disable everything and selectively enable what the agent needs:

sol config set permissions.canSwap true
sol config set permissions.canTransfer false
sol config set permissions.canExportWallet false

4. Set transaction limits:

sol config set limits.maxTransactionUsd 500
sol config set limits.maxDailyUsd 2000

5. Set allowlists if appropriate:

sol config set allowlist.tokens So11111111111111111111111111111111111111112,EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v,DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263

6. Review the full security posture:

sol config status

7. Lock so the agent can't change its own settings:

sol config lock

8. Fund the wallet with a small amount for testing
9. Give the agent access and monitor via sol wallet history and sol config status

Full documentation: Sol CLI Complete Guide

Disclaimer: This article discusses security considerations for AI agents with financial capabilities. It does not constitute security advice. You are responsible for your own security posture and should evaluate risks based on your specific use case.