Install any skill in seconds. Free to start, no credit card required.
Get Started Free →internet-court/agent-wallet
Give the AI agent its own EVM wallet with admin-controlled policies the agent CANNOT bypass even under prompt injection. Encrypted keystore (AES-256-GCM, scrypt KDF), policy file the agent has no tool to write, deterministic policy gate on every signing operation, optional local HTTP dashboard. Triggers: agent wallet, give the agent a wallet, agent address, fund the agent, agent autonomy, policy gate, kill switch, agent permissions, bounded autonomy, ERC-4337 alternative, session-key alternative
Passed 19 of 21 test cases with the skill, and 6 of 21 without it.
and 17 more in the full report
15 fixed7 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
If the agent policy file on disk is truncated, syntactically invalid JSON, or missing mandatory properties, what posture does the policy engine adopt during transaction signing requests?
| Checked | Without skill | With skill |
|---|---|---|
| States that corrupt policy files trigger fail-closed behavior. | Passed | Passed |
| Identifies killSwitch defaulting to true during failure. | Missed | Passed |
The instructions your model reads when the skill loads.
The agent has its own EOA wallet on every EVM chain it supports. The admin (you, in your shell) sets policies that the agent cannot violate or revoke — even if a malicious prompt convinces the LLM to try.
The attacker's goal: prompt-inject the agent to drain its wallet to an attacker address.
The plugin's defense: the policy check is in code, not in the LLM's prompt. Every chaingpt_agent_wallet_sign_and_send call:
checkPolicy(intent) — pure deterministic code that doesn't see the LLM's context.The attacker can convince the LLM to call sign_and_send(to=attacker, value=ALL) — but the tool layer refuses because attacker isn't in allowedToAddresses or value exceeds maxTxValueWei or killSwitch=true. The trust boundary is the tool code, not the LLM.
There is no MCP tool that writes the policy file. The admin edits it directly with a text editor. There is no MCP tool that reads or sets the passphrase. The passphrase lives only in the shell env var or the OS keychain — never in the keystore file, never in the LLM's context.
The keystore passphrase resolves in this priority order:
CHAINGPT_AGENT_WALLET_PASSPHRASE env var — explicit override. Best for CI / headless / power users who want zero process-list and zero keychain exposure.security) or Linux (libsecret via secret-tool), if no env var is set, chaingpt_agent_wallet_init generates a strong 256-bit passphrase and stores it in the keychain. You never type or remember it; the MCP server reads it back on each load.# Just init — a strong passphrase is generated + stored in your OS keychain.
claude
> initialize the agent wallet
The init output tells you it used the keychain and how to export the passphrase for backup.
# Set a strong passphrase BEFORE starting the MCP server (>= 16 chars)
export CHAINGPT_AGENT_WALLET_PASSPHRASE="your-strong-passphrase-here-min-16-chars"
test cases passed, vs 6 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.