What Actually Revokes an AI Agent’s Spending Permission?

The signal

The operational weakness to investigate is a mismatch between the authority an interface says it removed and the authority the underlying contracts still recognise. A credible agent product should make that boundary visible before the first permission is granted.

Start with the permission, not the agent’s name

An agent name is a poor primary key for an authority register. A single application may use several spenders, and the same wallet address can exist on several chains. DN’s proposed register therefore begins with chain ID, asset-owning account, token or account contract, implementation version, and the precise spender, permission ID or module address. Keep exact identifiers as hexadecimal strings rather than rounding them into spreadsheet numbers.

The next field is what the authority permits: a token amount, a recurring allowance, a single signed transfer, or a class of account operations. The final field is the revocation evidence required. This makes the response reviewable by someone who did not configure the agent.

Consider a hypothetical service that trades two tokens through a shared router and also holds a session key. There are several possible authority paths. Deleting its local API key might stop the service’s normal process, but the review must still ask which on-chain paths remain. This is a proposed inventory method, not a claim that every agent uses this architecture.

ERC-20: read the allowance that matters

ERC-20 defines an allowance for an owner and spender. A later approval overwrites the amount, and the allowance query reports the remaining authorised quantity. The standard also warns integrations to handle a false return value rather than assume every token call succeeds. [1]

For an ordinary approval, a useful postcondition is therefore a zero allowance for the intended owner–spender pair on the intended token. Record the transaction receipt and a subsequent state read at an identified block. An Approval event helps explain the change; the resulting state is what the review is trying to establish.

The scope matters. Zero for one spender says nothing about a second spender, another token, another chain or a separate account-level authority. The phrase “all approvals revoked” should only appear beside an inventory that makes “all” testable. Otherwise write the narrower result: this allowance was zero at this block.

An unused permit can be a separate authority

ERC-2612 adds signed approvals to token contracts. Its acceptance conditions include a matching owner nonce and a valid deadline; successful use changes the allowance and advances that nonce. This creates a second question beside the current allowance: can a previously signed message still change it? [2]

An approve-to-zero transaction alone is not evidence that every unused permit has become invalid. Check the actual token implementation, the signature’s domain and deadline, and the nonce it requires. A message that can still satisfy those conditions deserves its own unresolved entry.

This is especially relevant when a permission was signed off-chain but never submitted. A transaction history cannot, by itself, enumerate every message someone previously signed. The operating procedure should preserve signing records where practical and distinguish known messages from unknown exposure. Expiry can close a known time-bounded path, but the reviewer must compare the signed deadline with chain time rather than a stale application badge.

Permit2 has two layers and two kinds of permission

Permit2 requires a token-level approval to the Permit2 contract. Inside it, AllowanceTransfer maintains time-bounded standing permissions, while SignatureTransfer authorises a nonce-scoped transfer. Removing the outer approval and changing an inner permission act at different layers. [3]

The AllowanceTransfer implementation provides a particularly instructive distinction. Its lockdown operation sets the amount to zero for specified token–spender pairs. Its invalidateNonces operation instead advances the relevant nonce. The code does not make either operation a substitute for the other: clearing the amount does not itself advance that nonce, and advancing the nonce does not clear the stored amount. [4]

DN’s inference is to record two postconditions when both risks are relevant: the standing amount is no longer usable, and the known outstanding permit cannot satisfy the required nonce. Do not silently collapse these into one green tick.

Removing the outer token approval can block that token’s Permit2 transfer route, but a later reapproval deserves a fresh review of inner state and signed messages. Treat temporary containment and permanent disposal of known authorisations as different tasks. That distinction makes it possible to restore a legitimate workflow deliberately, rather than rediscover an old permission during the next trade.

A single-use signature needs the right nonce bit

Permit2 SignatureTransfer tracks unordered nonces in a bitmap. The implementation’s invalidation function sets selected bits for the calling owner; the transfer path rejects reuse of a consumed or invalidated nonce. A nonce identifies both a bitmap word and a bit within it. [5]

The proof is correspondingly specific: the correct owner’s relevant bit is set in the correct contract on the correct chain. Invalidating an unrelated word does not answer the question. Neither does observing that a different transfer signature has already been used.

This is a good place to resist an attractive but unreliable spreadsheet shortcut. Contract identifiers and large nonce values should be handled with exact integer or hexadecimal representations. The calculator below deliberately does not accept nonces or generate transaction payloads. It estimates a response budget; it cannot decide which authorisation a wallet should invalidate.

Delegated sessions need implementation-specific evidence

The SmartSessions source examined separates session membership from enable-signature replay protection. SmartSessionBase removes a named session and its associated policy state; its isPermissionEnabled function exposes membership for a permission ID and account. [6] NonceManager separately offers revokeEnableSignature, which increments that account’s nonce for the permission ID. [7]

This is a concrete example, not a universal session-key standard. A review should identify the deployed implementation and compare both the permission state and any still-usable authorisation to enable it. The source files accessed here are a moving repository branch; matching them to a particular deployment is additional work, not something this article has completed.

A broader containment route exists in Safe’s module system: disableModule removes the specified module through a Safe transaction, and isModuleEnabled provides the corresponding state query. [8] [9] This checks a module boundary, not every owner, module or token approval associated with the account.

The operational choice is between a narrow change with limited disruption and a wider change that may disable legitimate automation. Document which boundary was chosen and why. An emergency operator should not have to infer that choice from a button labelled “revoke”.

Build a proof record that survives a handover

DN proposes a short evidence packet for each affected permission: identifiers; the authority before intervention; the intended postcondition; the submitted transaction; its receipt and block; and an independent state read after the chosen confirmation policy. Add who checked it and which implementation assumptions remain unresolved. This is a review method, not a substitute for contract-specific validation.

Keep three times separate: when the operator requested revocation, when a transaction was included, and when the team accepted the state as sufficiently confirmed. A queued request should remain visibly pending. A reverted transaction should not turn the permission green. If a transaction is replaced, the record should follow the transaction that actually changed state.

A local simulation can help diagnose a proposed call, but its result is tied to the state it simulated. Record its block context and do not treat it as proof of later inclusion. Similarly, an earlier successful revocation does not prove that a legitimate owner, another module or a later operation has not granted authority again.

The strongest countercase is a deliberately simple account with one short-lived, tightly scoped authorisation. Such a design can make the evidence burden much smaller. Complexity is not automatically unsafe, but each independent authority path adds something the operator must identify and verify. Product selection should reward understandable boundaries, not the sheer number of security controls advertised.

Fund the response without pretending to score safety

EIP-1559 distinguishes the transaction’s gas limit and maximum fee per gas from the effective fee paid on inclusion. [10] The tool uses those limits to budget execution fees for a planned number of transactions. It does not estimate confirmation time or certify an adequate gas limit.

All defaults are hypothetical. Three planned transactions, one additional included attempt, a 55,000-gas limit per attempt, a 25-gwei maximum fee and a native-asset price of $2,500 produce a maximum modelled execution-fee budget of 0.0055 native units, or $13.75. Doubling the fee cap doubles that budget; it says nothing about whether the permissions have changed.

Use one chain and one native fee asset per calculation. The additional-attempt input is for an extra included transaction that may consume gas, not an unmined replacement automatically billed twice. Different calls can need different gas limits, so the common limit is a planning simplification. Data-availability fees, account-abstraction service charges and other network-specific charges are excluded.

The decision this tool supports is modest but practical: whether the designated response account has enough fee funding for the plan being considered. The security decision remains in the proof record. Before restoring automation, require a clear explanation of which permissions are intentionally being granted again and which historical authorisations have been invalidated.

The evidence, side by side

DN Emergency Revocation Fee Budget

Hypothetical execution-fee planning only; no live gas estimate, transaction generation or revocation verification.

Finite inputs; whole nonnegative transaction counts; positive whole gas limit; nonnegative fee cap; positive native-asset price.

Excludes chain-specific data fees, service fees and token price movements. A sufficient budget does not establish correct calldata, inclusion, finality or removal of every permission.

Scenarios to watch

Default hypothetical response

Three planned transactions and one additional included attempt; 55,000 gas each; 25 gwei; $2,500 native price.

0.0055 native units; $13.75 execution-fee cap.

Fee-cap stress

Same plan at 50 gwei.

0.011 native units; $27.50. No implication for inclusion or security.

No transactions budgeted

Both transaction counts are zero.

Zero modelled fee; no assertion that any permission has been removed.

Method and limitations

We compared published token standards, Permit2 source, SmartSessions implementation files and Safe reference documentation. The review maps authority types to observable postconditions; it does not test deployed wallets or send transactions.

SmartSessions files were retrieved from the repository’s raw main-branch URLs and retained with SHA-256 hashes in the research receipts. Other references are current accessed documentation or dated standards. Moving sources must be matched to deployed code before operational use.

The fee-budget equations are DN calculations with synthetic inputs. Default, changed-fee and zero-transaction cases are tested separately from the documentary findings.

No claim is made that this inventory covers a particular user’s unknown signatures, compromised keys, upgrade rights, off-chain accounts or every chain. These require a deployment-specific review.

The article explains evidence boundaries. It does not provide an audited transaction builder, incident-response guarantee or proof that an account is secure.

Primary sources and evidence register

Source dates and reporting periods differ. Several documents from one issuer are one source family, not independent confirmations. The evidence download contains the observations used in this article.

Frequently asked questions

Does disconnecting a wallet revoke spending permission?

Disconnection should be treated as an interface event until the relevant authority has been checked. Ask for the exact permission and its resulting contract state.

Does a successful receipt prove everything was revoked?

It identifies an included transaction outcome. The scope of the call and the post-transaction state still determine which permissions changed.

Can I use this calculator to select the right nonce?

No. It accepts only fee-planning inputs. Permission identifiers and nonce handling belong in exact, implementation-specific tooling.

What should an agent provider export?

A useful export includes permission identifiers, chain and contract addresses, grant records, revocation transactions, postconditions and unresolved assumptions. DN proposes this as a procurement criterion, not a certification standard.