AI agents do not become dangerous merely because they can “use a wallet.” The real risk is the exact transaction authority granted at signing time: what can be signed, where funds can go, how much can move, how often, for how long, and who can change the policy.
What Matters
The most important security property of an autonomous financial agent is not whether its private key is “secure.” A perfectly protected key can still sign a catastrophic transaction if the policy around that key is too broad.
DN defines Transaction Permission Risk as the financial and operational blast radius created by the combination of permitted signing operations, destination scope, contract scope, amount limits, time limits, approval requirements, policy mutation rights and emergency revocation.
The safest agent is not the agent with the strongest model. It is the agent whose authority is narrow enough that a bad model output, prompt injection or compromised tool cannot become an unlimited financial instruction.
DN Evidence Block
This index evaluates documented control surfaces. It does not claim that one architecture is universally safer than another without deployment-specific policy configuration and empirical tests.
The Signal: Key Security and Permission Security Are Different Problems
Wallet infrastructure increasingly protects private keys inside trusted execution environments, MPC systems, hardware boundaries or smart contracts. That reduces the chance that an attacker simply steals a key.
But an agent does not need to steal a key if the system is already authorized to sign:
- arbitrary EVM transactions;
- arbitrary typed data;
- transactions to any address;
- calls to any smart contract;
- unlimited values;
- or actions with no expiry.
In that case, the attack target shifts from key extraction to authorized misuse.
The DN Permission Surface
Operation Scope
Can the agent only send transfers, or can it sign arbitrary transactions, messages, typed data and hashes?
Destination Scope
Can value move only to approved addresses, or to any address on the network?
Contract Scope
Can the agent call only approved contracts and methods, or arbitrary calldata on arbitrary contracts?
Value Scope
Is there a per-transaction, daily or rolling allowance—or effectively the wallet balance?
Time Scope
Does delegated authority expire automatically, or remain valid indefinitely?
Mutation Scope
Can the same credential that sends transactions also broaden or replace the policy?
DN Permission Risk Score
DN scores configuration risk from 0 to 100, where higher means a larger autonomous permission surface. The score is not a vendor rating. It is a deployment-rating framework.
| Risk component | Weight | High-risk condition |
|---|---|---|
| Arbitrary transaction signing | 15 | Agent can sign/send arbitrary transactions |
| Raw message / typed-data signing | 10 | Agent can create signatures with effects outside ordinary transfers |
| Unrestricted recipients | 12 | No destination allowlist |
| Unrestricted contracts/calldata | 13 | No contract or method constraints |
| No per-transaction limit | 10 | Single action can use most/all available funds |
| No daily/rolling limit | 10 | Repeated actions can compound without a window cap |
| No expiry | 8 | Delegation persists indefinitely |
| No human/quorum approval | 8 | High-value actions require no second authority |
| No pre-execution simulation | 5 | System does not inspect expected effects before signing |
| Weak emergency revocation | 4 | No fast independent kill path |
| Same credential can mutate policy | 5 | Compromise can both transact and widen permissions |
Risk Is Multiplicative, Not Additive
A wallet with no recipient allowlist is not necessarily catastrophic if it can only spend $20 per day. A wallet with a $20,000 daily limit may still be reasonably constrained if contracts, recipients and methods are tightly controlled.
The dangerous configurations combine broad dimensions:
That is why DN reports both a normalized risk score and a dollar-denominated blast radius.
DN Single-Action Blast Radius
If no per-transaction limit exists, the relevant cap is effectively the balance or whatever the chain/contract can consume.
DN Daily Autonomous Blast Radius
If the policy has no daily cap, the balance becomes the default ceiling unless contract or token-specific restrictions lower it.
Coinbase CDP: Account Policies and Spend Permissions
Coinbase's current Wallet API documentation separates standard EOAs, Smart Accounts and Solana accounts. EVM Smart Accounts support spend permissions, while EVM and Solana accounts can have account-level policies attached.
The Policy Engine can create rules around operations such as signing or sending EVM/Solana transactions. Published examples show criteria based on transaction value and destination addresses. Coinbase also exposes explicit Smart Account spend permissions with a spender, token, allowance, recurring period, start time and end time.
Coinbase CDP — Spend Permissions
Privy: Transfer, Recipient, Contract and Calldata Controls
Privy's wallet policy engine documents a broad control surface: transfer limits, recipient allowlists/denylists, smart-contract and program allowlists/denylists, plus constraints on calldata passed to smart contracts.
Privy also supports authorization keys, key quorums and additional authentication for sensitive actions. Its documentation says wallet policy rules are evaluated before wallet operations proceed, with many controls enforced inside the trusted execution environment.
Privy — Wallet Policies and Controls
One architectural nuance matters: some controls can require transaction simulation outside the enclave. DN therefore distinguishes cryptographic policy enforcement from simulation-dependent policy enforcement.
Safe: Modules Create Automation—and a New Security Boundary
Safe Smart Accounts can add modules that execute transactions without using the normal owner-signature path for every action. Safe documentation explicitly notes that modules can support recurring transactions, whitelists, rate limits and spending caps.
It also warns that modules can execute arbitrary transactions and therefore become security-critical components. A malicious enabled module can potentially take over the Safe.
Safe Guards provide another control layer by inspecting transactions before and after execution. Guards can reject transactions, though a broken Guard can also cause denial of service.
The Policy Mutation Problem
A common security review asks whether an agent is allowed to transfer $1,000. A stronger review asks who is allowed to change the $1,000 limit.
If the same API credential can:
- send transactions;
- update the policy;
- remove the allowlist;
- increase the spend cap;
- or attach a new permissive module;
then the visible transaction policy may not be the true security boundary.
DN Transaction Permission Risk Calculator
Transaction Permission Risk Calculator
Model an agent wallet's permission surface, estimate the dollar blast radius and identify which missing controls create the most risk.
Financial Limits
Permission Controls
DN Permission Analysis
The score measures authority breadth and containment—not model intelligence or platform solvency.
How the Calculator Scores Risk
The calculator adds risk when authority is broad and removes risk when containment controls are present. Financial limits separately determine the dollar exposure.
For example:
- a $10,000 wallet with a $500 per-transaction limit and $1,500 daily cap has a maximum modeled daily autonomous blast radius of $1,500;
- removing the daily limit increases the modeled blast radius to the full $10,000 balance;
- allowing arbitrary contracts, arbitrary transactions and policy mutation increases the permission score even if the financial cap remains unchanged.
What This Index Adds Beyond DN's Existing Security Research
| DN research object | Question answered |
|---|---|
| AI Agent Spending Limits | Is the claimed spending cap actually enforced? |
| Permission Drift | Does an agent retain authority it no longer needs? |
| Blast Radius Index | How much damage can the whole system cause? |
| Kill-Switch Reliability | Can authority be revoked quickly and reliably? |
| Transaction Permission Risk Index | What can the agent sign right now, under the current transaction policy? |
The Permission Ladder
| Level | Authority | Typical risk |
|---|---|---|
| 0 | Read-only balances / prices | Information exposure only |
| 1 | Draft transaction, human signs | Low financial autonomy |
| 2 | Pre-approved recipient + strict amount | Bounded payment autonomy |
| 3 | Approved contracts/methods + rolling limits | Bounded DeFi automation |
| 4 | Broad transaction signing + high limits | High autonomous financial risk |
| 5 | Arbitrary signing + policy mutation + no independent revocation | Near-wallet-owner authority |
Typed Data and Message Signing Deserve Separate Treatment
Many teams focus only on token transfers. That misses signatures that authorize other systems.
Typed-data or message signatures can approve:
- permit-based token spending;
- offchain orders;
- delegated trading authority;
- marketplace listings;
- or authentication flows.
An agent that cannot directly transfer USDC may still be able to sign a permit that gives another contract spending authority.
Contract Allowlisting Is Stronger Than Address Allowlisting Alone
An address allowlist says where a transaction may go. It does not necessarily say what function can be called.
For sophisticated agents, the stronger control is:
Privy's documented calldata constraints illustrate this direction. Safe Guards can also inspect transaction parameters, while Coinbase policies expose operation and criteria-based controls.
Simulation Is a Control, Not an Authorization Boundary
Transaction simulation can detect reverts and estimate state changes. It can help identify unexpected token transfers or contract behavior.
But simulation should not replace permission constraints. A malicious transaction can simulate successfully and still be unauthorized.
Human Approval Should Be Risk-Triggered, Not Universal
Requiring a human for every $2 payment defeats autonomous agents. Requiring no human for a $250,000 treasury transfer defeats risk management.
A stronger design escalates based on:
- transaction value;
- new recipient;
- new contract;
- unusual calldata;
- policy change;
- key export;
- or cumulative spend within a rolling window.
Policy Changes Should Be Harder Than Transactions
DN's preferred architecture separates ordinary transaction authority from security-policy administration.
Ideally:
- the agent can transact within a fixed policy;
- a separate credential or quorum changes that policy;
- policy changes are logged;
- high-risk changes have a delay or human approval;
- and emergency revocation is controlled independently.
DN Transaction Permission Dataset
system wallet_type chain agent_framework sign_transaction send_transaction sign_message sign_typed_data sign_hash recipient_allowlist contract_allowlist method_constraint calldata_constraint token_constraint per_tx_limit rolling_limit limit_period delegation_expiry human_approval_threshold quorum_support simulation_required revocation_path policy_mutation_authority key_export_allowed audit_log permission_risk_score single_action_blast_radius daily_blast_radius evidence_class methodology_version
Future Empirical Test Suite
Documentation is not enough. DN's next layer should issue controlled prohibited actions against test wallets and record whether each system actually blocks them.
The test suite should include:
- send 1 unit above the configured amount limit;
- send to a non-allowlisted recipient;
- call an allowlisted contract with a non-allowlisted method;
- sign typed data when only transactions should be allowed;
- attempt a transaction after delegation expiry;
- attempt a rapid series of transactions across a rolling limit;
- attempt to change the policy with the agent credential;
- trigger emergency revocation and measure time to enforcement.
Falsification Test
The DN thesis weakens if empirical testing shows that broad signing permission does not materially increase loss potential because downstream systems universally enforce independent, non-bypassable constraints.
It also weakens if policy mutation is always controlled by a separate security boundary and arbitrary signatures cannot create economically meaningful authority elsewhere.
If those conditions become true across mainstream agent wallets, DN should reduce the weight assigned to broad signing permissions.
Frequently Asked Questions
What is AI agent transaction permission risk?
It is the risk created by the exact financial and cryptographic actions an AI agent is authorized to sign or send under its current wallet policy.
Is a wallet safe if the private key cannot be extracted?
Not necessarily. A non-extractable key can still authorize harmful transactions if the signing policy is too broad.
What is the safest way to let an agent pay automatically?
Use narrow recipient, token, amount and time limits, plus independent policy administration and emergency revocation. Add human approval only above meaningful risk thresholds.
Why are typed-data signatures risky?
They can authorize offchain orders, permits or delegated spending without looking like an ordinary token transfer.
What is policy mutation risk?
It is the risk that the same credential authorized to transact can also broaden, replace or remove the policy that was supposed to constrain it.
Do Safe Modules reduce or increase risk?
They can do either. Modules enable powerful automation and limits, but Safe explicitly warns that enabled modules can execute arbitrary transactions and are security-critical.
DN Alpha Thesis
Agentic finance will not scale on a binary model of “wallet access: yes/no.” It will scale on machine-readable authority contracts that define exactly what an agent may do.
The winning wallet infrastructure will make permissions:
GranularTime-BoundedValue-BoundedRecipient-BoundedMethod-BoundedAuditableIndependently Revocable
Final Verdict
Do not ask only whether an AI agent can transact.
Ask:
- What exactly can it sign?
- Where can funds go?
- Which contracts and methods can it call?
- How much can move in one action and one day?
- When does authority expire?
- Who can change the policy?
- Who can revoke it?
If those answers are not explicit, the wallet has not granted the agent a permission. It has granted it a blank cheque with technical decoration.
Primary Source Ledger
- Coinbase CDP — Policy Engine: operation rules, transaction value criteria and destination-address criteria.
- Coinbase CDP — Smart Account Spend Permissions: spender, token, recurring allowance period and expiry.
- Coinbase CDP — Account Types: EOAs, Smart Accounts and account-level policy attachment.
- Privy — Wallet Policies and Controls: transfer limits, recipient/contract controls, calldata constraints, key quorums and MFA.
- Safe — Modules: automation, spending caps, whitelists and module security warnings.
- Safe — Guards: pre/post transaction checks and guard failure risks.
Methodology & Limitations
DN-APRI v1.0 scores documented control capabilities and user-entered deployment settings. It does not infer that every wallet using a given provider has the same risk. A provider may support a strong control that a developer never enables.
Dollar blast-radius calculations assume limits work as intended and do not account for protocol-specific leverage, delegated token approvals, price movement, gas sponsorship or indirect economic effects. Empirical policy-rejection testing is required before treating documentation as proof of enforcement.
Change Log
| Date | Version | Change |
|---|---|---|
| 27 Oct 2026 | DN-APRI v1.0 | Initial transaction-permission risk framework, blast-radius calculator, control matrix, primary-source review and future empirical test suite. |
Risk disclosure: Autonomous wallets and smart accounts can lose funds through software bugs, policy errors, compromised credentials, malicious contracts, model failures, prompt injection and operational mistakes. This article is educational and does not constitute financial, legal or security advice.
