Documentation
Learn how to use Aegis to manage permissions for your AI agents.
Architecture Overview
A technical deep dive into how Aegis enforces policy on-chain — the ERC-8004 / ERC-4337 model, the v14 spend-resolver registry, and the trust boundary. Start here for a system-level view.
Get an Agent Running End-to-End
The complete path from connecting your wallet to a policy-bounded agent trading on-chain. This is the exact flow used to stand up a live trading agent — follow it in order.
Connect your wallet in the dashboard
Go to app.projectaegis.ai, click Connect Wallet, and sign the Sign-In with Ethereum (SIWE) message. This wallet becomes the owner of everything you create — the fully-trusted principal. It stays in your control the whole time; the agent never gets this key.
Create an agent with a generated signer bot & deploy its account
On the Agents page, click Register Agent and choose Generate Bot Signer. Aegis generates a fresh keypair in your browser and reveals the private key exactly once — save it now. This is the bot's low-privilege signer key (the account's signer), not your owner key: it can only sign UserOperations that pass policy, and it can never withdraw beyond what you authorize. Registration then deploys the agent's ERC-4337 AgentSmartAccount via AgentAccountFactory.createAccount at a deterministic CREATE2 address, and registers its ERC-8004 identity in IdentityRegistry.
Create a policy — what the agent is allowed to do
On the Policies page, click Create Policy and define the rules: allowed actions(swap, transfer, …), the tokens and their per-asset limits (per-tx, daily volume, daily tx count, in each asset's own base units), allowed protocols and chains, and — on v14 — the recipients the agent may send to. Activate it to write the policy to PolicyRegistry on-chain, where permissions can reference it.
Create a permission binding the agent to the policy, and mint it on-chain
On the Permissions page, click Grant Permission and select the agent + policy (with an optional validity period). Then click Mint On-chain: PolicyRegistry.grantPermission registers the agent→policy binding and PermissionEnforcer.setConstraints pushes the per-asset limits on-chain. Only minted permissions enforce — this is what the contract checks at runtime. Note the resulting permissionId; the agent references it in every transaction.
Give the agent runtime its credentials
Hand your agent process a .env file with everything it needs to sign and submit — and nothing more:
# .env for the agent runtime — the bot's low-privilege signer only BOT_SIGNER_PRIVATE_KEY=0x... # the generated signer key from step 2 AEGIS_API_KEY=aegis_... # create in Settings -> API Keys (sent as X-API-Key) AEGIS_AGENT_ID=<agent-uuid> # the agent's UUID from the dashboard RPC_URL=https://... # JSON-RPC for the target network (e.g. Base / Sepolia)
The owner key is never placed in this file. If the runtime environment leaks, the blast radius is capped by the policy — the signer cannot exceed its limits or move funds to unapproved destinations.
Point the agent at the Aegis skill and MCP server
Give the agent the downloadable Aegis skill (aegis-smart-accounts) so it knows how to build the prefixed execute() calldata, sign UserOperations, and handle DeFi and x402 flows. Then wire up the MCP server for live contract metadata, DeFi-support checks, amount conversion, and pre-flight:
npx -y @project-aegis/mcp-server
The MCP tools (aegis_get_contracts, aegis_get_defi_support, aegis_amount_to_base_units, aegis_preflight_transaction) let the agent verify an action will pass before it spends gas submitting it.
Fund the account and let the agent run
Send the tokens the agent will trade to its smart account address, and make sure it can pay for gas (keep a little native balance in the account, or top up its EntryPoint.depositTo deposit — the ERC-4337 prefund comes from the account, not the bot signer). Now let it loop: the agent signs ERC-4337 UserOperations from its account, and every one runs through AgentSmartAccount.validateUserOp → PermissionEnforcer. Anything outside policy — wrong token, over a limit, unapproved recipient — reverts before execution. Every allowed action is indexed into your audit log with its tx hash.
What you end up with
An autonomous agent running against its own ERC-4337 smart account, signing with a low-privilege bot key that is bounded by an on-chain policy. The agent can trade 24/7 without a human in the loop, yet it physically cannot exceed its per-asset limits, touch a disallowed protocol, or move funds to an unapproved address — enforcement is in the contract, not in the agent's software. Meanwhile your owner key stays cold and never appears in the agent's environment: it retains full withdrawal rights and can revoke the permission at any time.