The core idea
Before your agent touches a single token, you set the terms. That’s a pact. In Cobo Agentic Wallet, a pact is a structured delegation agreement between you and your agent. It defines what the agent is authorized to do and enforces those boundaries automatically — at the infrastructure level, not by trusting the agent to follow rules. Your agent operates within the pact. It cannot go around it — not even if it’s compromised.Four elements of a pact
Every pact consists of four elements:| Element | What it defines | Example |
|---|---|---|
| Intent | The job the agent is being authorized to carry out | ”Execute a DCA strategy on Base” |
| Execution plan | A reviewable plan for how the agent intends to carry out that job | ”Swap USDC → ETH on Uniswap every Monday at 9am” |
| Policies | Budgets, approvals, allowlists, chain/token/contract constraints, and other guardrails | ”Max $200 per transaction, only Uniswap on Base, only USDC and ETH” |
| Completion conditions | What triggers automatic completion and revocation | ”Complete after $3,000 total spent or 30 days elapsed” |
How a pact works
See it end-to-end: Pact flow.Your agent submits a pact
The agent declares its intent, proposes an execution plan, proposes the policies that should govern execution, and specifies completion conditions. You see a plain-language summary alongside the full details.
You review and approve
You review the pact in the Cobo Agentic Wallet app. You can approve it as-is, adjust the policies or completion conditions, or reject it. No access is granted until you explicitly approve.
Your agent operates within boundaries
Once approved, every transaction the agent submits is checked against the pact’s policies before execution. The agent cannot exceed its authorized operations — enforcement is architectural, not best-practice.
A pact isn’t a leash — it’s a license
A pact doesn’t restrict your agent. It empowers it. Without a pact, an agent either has unrestricted access (dangerous) or no access at all (useless). A pact gives your agent a clear operating mandate — “here’s what you’re authorized to do, here are the guardrails, here’s when it ends” — and the infrastructure guarantees those boundaries hold. Think of it like a corporate expense card — but with a compliance department that cannot be fired, bribed, or overridden. Not even by the agent itself. When the project is over, the card shreds itself. That compliance department? It’s the pact.Enforced by infrastructure, not trust
The critical difference between a pact and a conventional access-control system: enforcement is structural.- The agent’s credentials cannot modify pact policies — credential separation is architectural
- Policy limits use atomic reservation with sliding-window counters — no race conditions, no workarounds
- When a pact ends, the API key is invalidated server-side instantly — there is no grace period
Further reading
- How pacts work — the full technical specification: PactSpec fields, state machine, pact-scoped API keys
- The policy engine — how every agent operation is evaluated before execution
- Spend limits — how per-transaction and rolling limits are configured and enforced
- Freeze and revoke — how to immediately terminate agent access