Switch it off today: why revocation is the hard part

A small business uses an AI agent to file its monthly GST returns. The accountant who set it up left the firm on a Monday, and the owner, being careful, withdrew the agent's permission that same afternoon. A tidy afternoon's work.

On Wednesday, a return gets filed. The agent did it. The permission had been withdrawn, but the office that took the filing had checked it on Friday and remembered the answer.

Nobody was hurt this time, because the return was right. But the owner now knows something uncomfortable. Withdrawing a permission and the world noticing are two different events, and the gap between them can be days.

Granting is a click, withdrawing is a campaign

Issuing a permission is a local act. One person decides, one system records it, and the agent starts working.

Withdrawing is different, because the permission has by now been shown to many offices. Each of them looked at it once and decided to trust it. To make the withdrawal real, every one of them has to find out, and the person who withdrew it may not know who they are. The agent has been calling a bank, a tax portal and a vendor's service. You can switch off your own system in a second. The others are not yours to switch off.

So revocation is less about the act of deciding and more about telling people who weren't in the room. Think of cancelling a credit card. The bank blocks it in seconds, but a shop that took a note of the number last week can still try it, and it takes the shop's own check to catch that. An agent's permission behaves the same way, except that the agent can try again a hundred times before lunch.

The picture shows the same two requests at an office, first with no register to ask and then with one. The part we care about here is the second half. An office that can ask "is this still good?" at the moment of the request can turn away a withdrawn agent. An office that can't ask will keep letting it in until its memory runs out.

Four places it goes wrong

Memory. An office that checks once and then remembers is the Wednesday story. Remembering is fast and cheap, and it's the reason the problem exists. How long an office may remember an answer is a real design choice. We don't think the right answer is zero, because a desk that must ask every second will fall over. We also don't think it's a week.

Distance. Some offices are slow to reach. A clinic in a town with patchy internet can't always ask, and its options are to refuse everything or to guess. Neither is pleasant.

Work in flight. What about a task that started at 3.58 pm and was withdrawn at 4.00? Half a booking may be done. Do we stop mid-step and leave a mess, or finish the step? Different actions need different answers, and cancelling a payment halfway is a worse outcome than letting a calendar entry through.

Proof of timing. Later on, someone will ask exactly when the withdrawal took effect, and whether the Wednesday filing came before or after. If the office can't show what it knew and when it knew it, the argument becomes one side's word against the other's. That's why the office keeps its own record, and why we'd want it written before the agent's request is acted on.

Short lives help, and they aren't enough

An obvious answer is to make every permission short-lived, so that forgetting is automatic. We like that, and in the on-device piece we lean on it ourselves.

But short lives have their own cost. Someone, or something, has to renew them constantly, which means more traffic and more chances for a renewal to fail at the wrong moment. And some permissions legitimately need to last: a monthly filing that the owner has approved for the year shouldn't need a fresh approval every hour. A window of minutes can still hold plenty of harm, if the harm is quick.

So we'd treat expiry and revocation as two tools. Expiry cleans up after quiet mistakes. Revocation is for the afternoon when you find out something is wrong and want it stopped now.

We're deliberately not saying how

This piece doesn't say how a register might publish that status. The requirement is clear without it, and the how is a separate conversation we'll have when the specification is public. What we're sure of is the shape of the requirement. An office must be able to learn about a withdrawal quickly. It must be able to prove what it knew at the time. And when it can't find out, it should fail closed, which is the habit we describe in Who is the relying party.

What we don't know

We don't know how fresh an answer an office really needs. Seconds for a payment, perhaps, and minutes for a calendar. We haven't asked enough offices, and we'd like to.

We don't know whether a receiving office should be able to stop trusting an agent on its own, without the owner's say, because it's seen something odd. That sounds sensible and also sounds like a way for one office to quietly blacklist a competitor's agents.

We don't know what should happen to work already in flight. And we have no figures for how often a withdrawn permission is still being used, in India or anywhere. We would rather say that than quote a number we can't source.