Agent Authorization Revoked: Why Old Sessions Can Still Pay

Revoking authorization is not the same as taking back a key copy that has already been handed out. If an old session can still make payments, it means the key it holds was copied before you revoked it.

Last year, a friend on a quant trading team had an agent running well. When they saw a risky strategy, they revoked the agent's permissions. The next day, another 30 U disappeared from the account. After checking for a long time, they found that an old test session was still running. They had never revoked that session's session key. They had only clicked "disconnect" in the wallet.

The truth: You may have revoked a "connection," not "payment permission"

In most wallets, the "revoke authorization" action can mean two completely different things:

Case A: You revoked the "connection permission" for an app

• Path: wallet settings → connected websites → disconnect
• What actually happens: it only removes the app's visibility from the wallet interface. It does not stop the app from signing on your behalf.
• As long as the session key is still registered on-chain, the other side can still send transactions.

Case B: You revoked a specific session key or spending approval

• You need to send an on-chain transaction to mark the related authorization contract state as "revoked."
• This requires paying a gas fee. It is not a simple click.

Many wallets put these two actions under the same button, so users think one click is enough.

Step 1: Identify which authorization mechanism the old session uses

Different agent wallets have different authorization models. Understand the type before you act:

• Session key mode (most common): The user creates a temporary key and gives it to the agent. The agent uses this key to sign independently. Revoking a session key must be done on-chain or through the official SDK.
• Spending approval mode: The user allows a contract address to spend a set amount of tokens. To revoke it, change the approved amount to 0.
• Application-layer token mode: The agent holds a JWT or API token to call the payment interface. Revoking the token means marking it as invalid on the server side.

Completion standard: Confirm which mode your agent tool uses (check the docs or ask the developer).

Step 2: Use the right fix to really close the old session

Case A: Session key mode

• Privy example: Call removeSessionSigners to remove all session signers. This revokes all agent signing permissions. Only the user can continue to operate the wallet.
• CHIPI example: Use the SDK's sessions.revokeSessionKey method and pass in the session public key you want to revoke.
• ZeroDev example: Revoking a session key is itself an on-chain transaction. After it executes, the smart account will reject any request beyond the revoked permission.

Completion standard: You sent an on-chain transaction. After it is confirmed, any payment from the old session will be rejected with an error like SessionKeyRevoked or Unauthorized.

Case B: Spending approval mode

• Use Revoke.cash or a similar tool, find the related token approval record, and click revoke.
• Revoking means setting the approved amount to 0. This is an on-chain transaction that requires gas.
• After revocation, the approved contract address can no longer use your tokens.

Completion standard: Check on a block explorer or Revoke.cash that the approval amount is 0.

Case C: Application-layer token

• Go to the agent tool's backend or dashboard and find "session management" or "API keys."
• Manually delete or disable the related session token.
• If the tool has a kill switch, use it to cut off all session access at once.

Step 3: If you already lost money, check whether the old session is still running

• Open the agent tool's audit log or transaction history. Check whether any payments came from the old session after the time you revoked it.
• Check the wallet address's recent transactions on a block explorer. See if the recipient and amount match the old session's behavior.

High-risk reminder: On-chain session key revocation only stops new actions, not old ones. If an old session signed a transaction before the revocation and did not broadcast it yet (for example, it was saved in a local queue), it can still broadcast that signed transaction after revocation. This is like a signed check that has not been mailed yet—revoking authorization cannot control documents that were already signed. Vanguard's Full Agent Authorization has a similar rule: after an agent is revoked, the bank may still pay items the agent signed before the revocation for up to 10 days after receiving written notice.

Final verification

After you finish revoking, do two things:

1. Use the old session credentials (session key or API token) to make a very small test payment. It should be rejected.
2. If it is an on-chain session key, find a revoke transaction on a block explorer and confirm its status is Success.

Verification channel: Check the "active sessions" list in the agent tool's dashboard. The old session should disappear from the list or be marked as Inactive.