A wallet permission is revoked, but a signed operation is still sitting in a queue. What happens when the runner submits it?
That is the test worth keeping. A disabled payment button only tells you what the interface allows. A useful revocation check takes an operation signed while the session was active, confirms the revocation, and tries the old operation against the execution path. Record the reason for rejection and check that the intended transfer did not happen.
Agent Wallet Guard provides a concrete example. Its local demonstration includes both an API refusal and a direct bundler rejection after revocation. The contract also checks the session again during execution. These checks cover different places where an operation can be stopped.
Preserve a valid operation before revoking access
Use an isolated account and test token. Start with an active session, an allowed recipient and an amount inside the policy. Prepare and sign an operation, then retain its exact bytes without submitting it. Record the chain, account, EntryPoint, session address, policy and nonce beside it.
A failing operation is only useful evidence if it was otherwise eligible. If it has an expired validity window, an already-used nonce or a disallowed recipient, rejection cannot tell you whether revocation worked. Use a fresh operation for the revocation test and arrange a separate successful control while the session is active.
The retained operation should stay private in the test environment. Publishing a live signed operation can allow someone else to submit it. A public report can describe the fields and outcome without including a usable signature.
Test the API and the contract separately
An API may refuse to prepare another payment after it learns that a session is revoked. That protects the normal client path. A previously signed operation may still reach a bundler without using that API.
In the local demonstration recorded on 19 October 2026, the API refused a new prepare request. A correctly signed operation prepared before revocation was also submitted directly to Alto. The recorded result was rejection during Guard validation, with no change to the account or recipient token balances, recorded spending or EntryPoint nonce.
This was a local Anvil demonstration using MockUSDC and an independent Node runner. It did not involve a live merchant, mainnet funds or an autonomous LLM. The recorded run was reviewed for this article; the full environment was not rerun.
| Check | What to keep | What it establishes |
|---|---|---|
| New API prepare after revocation | Request context and refusal reason | The API knows the session is unavailable |
| Previously signed operation sent directly | Original operation identity and validation error | The normal API cannot be bypassed with that operation in the tested state |
| Validation followed by revocation before execution | A focused contract test and transfer assertion | Execution checks the current session again |
| Before and after observations | Token balances, spending and relevant nonces | The intended payment did not occur through the tested path |
The bundler result above is a validation rejection, not a mined failed payment. If a different test reaches an onchain transaction, inspect its receipt and account for fees separately. Unchanged token balances do not mean that every possible test costs no gas.
Check again at execution
The current Guard implementation recovers the signer in validateUserOp and checks that the session is active, belongs to the current installation, matches the agent and policy, and is inside its validity window. revokeSessionKey changes the stored session status to Revoked.
The execution function, executeValidatedUserOp, recovers the signer again and calls _requireActiveSession before transferring. A focused test in the repository first validates an operation, revokes the session, and then expects execution to fail with SessionNotActive. It also checks that the recipient received no tokens. That test was inspected, not rerun for this article.
The diagram separates checks that can be exercised in different tests. It does not describe one failed operation passing through all three.
ERC-4337 describes validation and bundler simulation, including checks before inclusion. Those mechanisms are useful context for this test design. They do not certify a particular wallet implementation. See the ERC-4337 specification.
Define when revocation takes effect
A click on “revoke” starts a transaction. The test should record the successful receipt and the resulting session state before it submits the retained operation. A pending revocation cannot establish that an earlier payment has been stopped.
If the payment executes first, revocation does not undo that transfer. Your acceptance criteria should state the ordering being tested and the confirmation policy used by the deployment. Network reorganization and stale infrastructure reads need separate recovery tests.
The Guard also prevents a session public key from being enabled a second time within the same installation epoch. A new authorization should follow the intended new-key workflow. Reinstallation and upgrade behavior deserve their own tests; the same-epoch rule alone does not establish what happens across every upgrade.
Keep a small evidence sheet
Download the revocation test matrix and fill in the actual results for your environment. It includes the active-session control, retained signature, confirmed revocation, direct submission and execution-time check. Leave unrun cases marked as pending.
For a first integration, the wallet access guide covers the account, network and purchase scope you need to decide. Agent Wallet Guard shows the local prototype behind this walkthrough. An integration discussion is easier to scope with your runner environment, allowed actions and required revocation behavior in hand.
