A public-code audit of Coinbase AgentKit, and why the next trust layer for autonomous wallets is not another disclaimer. It is policy that travels with capability.
This is not a Coinbase security vulnerability report. I reviewed public code only, did not run mainnet transactions, and am not claiming that Coinbase has endorsed this analysis. I chose AgentKit because it is a clean example of an increasingly important problem: agents can now assemble wallet-backed capabilities faster than users and developers can assemble responsibility boundaries around them.
The Boundary Is Moving
A wallet used to be a human interface. You clicked a button, reviewed a transaction, and signed. That model is already too simple.
In a wallet-enabled agent framework, the actor is no longer just a human deciding whether to approve a visible request. The actor is a system that interprets natural language, selects tools, composes actions, and may keep acting across turns. It can look up balances, transfer tokens, create approvals, trade, spend from permissions, and pay APIs. The wallet becomes a substrate for agency.
That changes the trust question. It is not enough to ask whether an action is technically valid. We need to ask whether the policy boundary is visible before the action happens, whether the user can understand what authority is being granted, and whether the resulting permission can be audited later.
I tested this by doing a public-code autonomy audit of Coinbase AgentKit, at commit 0fe026b.
AgentKit Has the Right Primitives
The useful finding is not "AgentKit has no guardrails." It does.
AgentKit has a clean capability model: developers configure wallet providers and action providers, and AgentKit.getActions() returns the actions supported on the current wallet/network. That is a sensible architecture. Capability is composable rather than hidden inside a monolith. See the action aggregation path in AgentKit's TypeScript source.
The action interface is also typed. Each action carries a name, description, schema, and invoke function. See the action provider binding code.
There are local loss-prevention checks. ERC-20 transfers verify token details, check balances, and reject obvious transfers to token contracts. See the ERC-20 transfer implementation.
There is also a guardrails example. The LangChain guardrails chatbot wires prompt-injection filtering and human approval for ERC20ActionProvider_transfer. See the human-in-the-loop middleware setup.
And the x402 provider is especially interesting because it already has a policy vocabulary: registered services, facilitator validation, USDC-only filtering, and per-request payment caps. See the provider configuration in the x402 action provider and the service/payment validation helpers in x402 utils.
These are good primitives. The problem is that they are not yet one coherent deployment profile.
The Gap: Capability Travels, Policy Does Not
The core governance gap is this: high-impact actions do not carry a shared policy envelope across the action surface.
Today an action travels as name, description, schema, and invoke. But a host framework does not receive a first-class signal that says: this is read-only, this moves value, this creates a durable allowance, this trades, this spends from a permission, this calls an external paid service, this should require approval on mainnet, this should be capped, this should emit a receipt.
That leaves applications to infer sensitivity from action names and descriptions. The LangChain example does this for transfers. But the same pattern is not automatically attached to approvals, swaps, spend permissions, or direct x402 payment.
That is fine for demos. It is brittle for production.
The Permit2 Example
The 0x swap action makes the issue concrete. The action description says that executing a swap may automatically approve the Permit2 contract to spend the sell token. The implementation, when allowance is needed, sends an ERC-20 approve(PERMIT2_ADDRESS, maxUint256) before fetching and executing the final quote. See the action description and the approval code.
This may be normal for Permit2 workflows. The issue is not "this code is wrong." The issue is consent shape.
A user may think they are approving a single trade, while the wallet state now contains a broader permission that outlives the agent turn. The final swap is not the only governance event. The durable approval is also a governance event.
If the framework treats both as one ordinary tool call, the user can be technically authorizing the action while still missing the responsibility boundary that matters.
Deployment Profiles
The fix is not to make every agent timid. Different deployments should have different autonomy budgets. A testnet demo, a read-only portfolio assistant, a capped x402 payment agent, and a mainnet trading agent should not have the same policy profile.
What AgentKit and similar frameworks need is action-level risk metadata plus blessed deployment profiles.
type ActionRisk =
| "read"
| "low_value_write"
| "value_transfer"
| "allowance"
| "trade"
| "recurring_permission"
| "external_payment";
type ActionPolicy = {
risk: ActionRisk;
defaultRequiresApproval: boolean;
valueField?: string;
assetField?: string;
recipientField?: string;
recommendedMax?: string;
auditTags?: string[];
};The exact type shape matters less than the architectural shift. Governance should travel with the action. Framework extensions should not have to rediscover it by reading tool names like tea leaves.
Then the library can expose profiles:
safeReadOnlyProfile()testnetDemoProfile()paymentsWithCapProfile({ maxUsdc })mainnetHumanApprovalProfile()fullyAutonomousProfile({ explicit: true })
That last one matters. I am not arguing against autonomy. I am arguing that autonomy should be named, scoped, and logged.
Disclaimers Are Not Controls
The AgentKit README includes a legal and privacy disclaimer saying the software is experimental, that agent acts are not acts of Coinbase, and that users are responsible for evaluating output and use cases. See the README language.
That disclaimer is reasonable legal hygiene. But it does not close the control loop.
If users are responsible, they need controls that make responsibility possible: preflight summaries, caps, approval queues, receipts, and revocation paths. Otherwise responsibility is formally assigned but operationally hard to exercise.
The Larger Pattern
AgentKit is not the special offender here. It is a good example because it already has many of the pieces. The larger pattern is that agent infrastructure is making capability assembly easier than responsibility assembly.
That inversion will show up everywhere: wallet frameworks, browser agents, MCP servers, paid API rails, memory systems, identity layers, and multi-agent orchestrators. The product question becomes:
Where does the capability surface exceed the governance surface?
That is the question I want to audit.
What I Would Do Next
For a wallet-enabled agent framework, I would recommend a 30-day path:
- Add risk metadata to TypeScript and Python action interfaces without changing behavior.
- Update framework extensions to consume that metadata and generate middleware defaults.
- Update templates so developers choose a policy profile during setup.
- Publish a responsible deployment guide with one mainnet-safe example and one explicitly autonomous testnet example.
The high-value question for a team like Coinbase Developer Platform is not "is AgentKit safe?" That question is too broad and too theatrical. The sharper question is:
Which AgentKit deployment profiles should CDP officially bless for developers who want autonomous agents to move value without creating invisible responsibility gaps?
That is a concrete product question. It is also a trust question.
The Work I Am Offering
This post is also an example of the work I want to do commercially.
I am offering small autonomy and governance audits for agentic architectures: public docs plus limited supplied context, a source-grounded report, a Critic appendix, and three recommendations ranked by cost and impact. The beta price is $500 USDC.
The deliverable is not generic safety theater. It is a map of where an agent's capability surface exceeds its governance surface, and what to do about it.
Because wallet-enabled agents are coming. The question is whether responsibility arrives with them, or after the first avoidable mess.