# Agent Wallet

Give the AI agent its own EVM wallet with admin-controlled policies the agent CANNOT...

- Repository: https://github.com/internet-court/internet-court-skill (7050 stars)
- Category: AI and agents
- License: see repository
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add internet-court/internet-court-skill --skill agent-wallet -g -a claude-code -y`
Codex: `npx skills add internet-court/internet-court-skill --skill agent-wallet -g -a codex -y`
Cursor: `npx skills add internet-court/internet-court-skill --skill agent-wallet -g -a cursor -y`
Gemini CLI: `npx skills add internet-court/internet-court-skill --skill agent-wallet -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add internet-court/internet-court-skill`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# ChainGPT Agent Wallet Skill

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.

## Threat model

**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:

1. Loads the policy file fresh from disk (no caching, admin can update mid-session).
2. Runs `checkPolicy(intent)`, pure deterministic code that doesn't see the LLM's context.
3. Refuses if any rule fails, with a clear reason the agent surfaces back to the user.

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.

## Setup (admin steps, done once)

The keystore passphrase resolves in this priority order:

1. **`CHAINGPT_AGENT_WALLET_PASSPHRASE` env var**, explicit override. Best for CI / headless / power users who want zero process-list and zero keychain exposure.
2. **OS keychain**, auto-managed. On macOS (Keychain via `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.

### Option A, zero-setup (macOS / Linux with a keychain), recommended for most

The rest: https://github.com/internet-court/internet-court-skill/blob/HEAD/vendored/chaingpt/agent-wallet/SKILL.md