Build an unsigned approve(spender, 0) transaction that revokes the allowance the wallet previously granted to spender on token. Pre-flight check refuses when the live allowance is already 0 — that call would burn gas for nothing, and almost certainly means the user named the wrong (token, spender...
AI agents call prepare_revoke_approval to permanently remove resources in VaultPilot MCP — typically in cleanup and lifecycle workflows. It does its job in a single call, and there is no undo.
| Parameter | Type | Required | Description |
|---|---|---|---|
chain | string | — | |
token | string | Yes | ERC-20 contract address. Must be the actual token contract — wrappers and aTokens have their own approval surfaces and aren't supported here. |
wallet | string | Yes | EVM wallet that owns the existing allowance. Must be the address that originally called approve(spender, value); only the owner can set the allowance back to ze |
spender | string | Yes | Address whose allowance to revoke. Typically a protocol contract (Aave V3 Pool, Uniswap SwapRouter, etc.) or any EOA the user previously approved. Get the live |
Parameters from the server's own tool schema.
An AI agent that decides to call prepare_revoke_approval doesn't hesitate, doesn't double-check, and doesn't stop at one. Whatever it removes from VaultPilot MCP is gone — there is no undo for destructive operations.
Risk signalsHandles credentials or secrets (token)
Attacks that exploit this kind of access
Build an unsigned approve(spender, 0) transaction that revokes the allowance the wallet previously granted to spender on token. Pre-flight check refuses when the live allowance is already 0 — that call would burn gas for nothing, and almost certainly means the user named the wrong (token, spender) pair. Resolves a friendly spender label from the canonical CONTRACTS table when one matches (Aave V3 Pool, Uniswap V3 SwapRouter02, Lido stETH, Compound V3 cUSDCv3, Morpho Blue, etc.) so the description + Ledger preview reads as "Revoke USDC allowance for Aave V3 Pool (0x...)" instead of a raw hex address. Description includes the previous allowance amount so the user sees what's being zeroed out. EVM-only — TRC-20 has the same approve(spender, value) shape but its prepare path runs through the TRON builder pipeline; surface in a prepare_tron_trc20_revoke if asked. Pair with the read-side get_token_allowances to enumerate what's currently approved. It is categorised as a Destructive tool in the VaultPilot MCP MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
prepare_revoke_approval accepts 4 parameters: chain, token, wallet, spender. Required: token, wallet, spender. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for prepare_revoke_approval: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
prepare_revoke_approval is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the prepare_revoke_approval rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for prepare_revoke_approval. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
prepare_revoke_approval is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.