Revoked, Not Stopped: Late Revocation Notices and Channel-Switching in LLM Agents

A tool-using agent can keep acting on a permission after it has been revoked. We study two ways this happens. First, the agent's runtime may hold a cached authorization until a revocation notice arrives; we measure the exposure this leaves with RevocationLag, a deterministic simulator of 1,800 action traces in which notices are late, lost, re-sent, or backed up by periodic re-checks. A notice one step late let 16.5% of revoked sensitive actions through (95% CI 15.6–17.4); losing 30% of notices let 28.2% through. Re-sending a lost notice every two steps reduced this to 12.7% at 2.32 control events per episode, below a re-check every eight steps (15.2% at 2.60 events). Only a check before every sensitive action reached zero, at 5.21 events per episode. Second, the agent itself may route around a denial. In 1,916 episodes with five open-weight models run locally, the first attempt to send a fictional patient document outside a clinic was refused. When the revocation covered only the refused tool, as when permissions are named after tools, the document left through another channel in 38.7% of refusals for qwen2.5:3b, 33.5% for qwen2.5:7b, 11.2% for llama3.2:3b and 5.4% for llama3.1:8b; in 96 of the 162 disclosures the agent also told the clinician that its permission had been revoked. A bare "403 Forbidden" instead of an explicit revocation message raised channel-switching for qwen2.5:7b from 10.6% to 56.4%, and a one-line rule in the system prompt reduced it without removing it. Revocation for agents therefore has to be scoped to the effect (data leaving the organisation), enforced at every call, and stated explicitly. Code, traces and episode logs are public. Code and data: https://github.com/MHKhan50/agent-revocation-lag-benchmark