You can revoke an AI agent’s access in the middle of a task without corrupting the work, but only if the agent was built to lose its credentials. Revocation has to be a designed behavior: steps that are safe to repeat, checkpoints that record how far the agent got, and a defined action for when a credential disappears mid-run. Deleting the credential is the easy half. The hard half is what the agent leaves behind when you do.
Most teams test revocation on an idle agent, see the access fail, and call it done. The case that matters is an agent halfway through a multi-step change to a customer record.
A revoked credential stops the agent, not the damage
Picture an agent updating a customer account. It changes the billing contact, then the renewal date, then creates a follow-up task, then notifies the account owner. You revoke its access after step two. The record now has a new billing contact and a new renewal date, and no task and no notification. Nothing is technically broken. The record is just in a state no human intended and no log explains.
It gets worse with the agent’s default behavior. Many agents treat a 401 or 403 as a transient error and retry. Some fall back to another credential they can reach, such as a cached token or a shared service key. That second case is the one that should worry you. If revocation can be routed around, it was never revocation. This is one more reason shared logins break downstream: you can’t kill one agent’s access without killing everyone else’s.
The other common failure is silence. The run just stops, and the only evidence is a gap in a log. Whoever finds the half-updated record next week has to reconstruct what the agent meant to do.
Every step should be safe to run twice
Design the work so that stopping at any point leaves a state you can reason about. That starts with idempotent steps. “Set renewal date to 1 March” can run twice and land in the same place. “Extend renewal date by 30 days” cannot. Where a step can’t be made idempotent, give it a unique operation key so the target system, or the agent’s own ledger, can recognize a repeat and skip it.
Next, checkpoints. Before each step the agent writes what it is about to do, and after each step it writes what happened. That gives you a record of the last confirmed step, not a guess. When access is restored, or a human takes over, the work resumes from the checkpoint instead of from the top.
Group steps into units that should succeed or fail together, and say so in advance. Changing the billing contact and the billing address is one unit. Sending the notification is another. If a unit can’t finish, the agent should be able to either complete it or roll it back to the prior value it recorded. Capturing that prior value is a cheap, boring requirement, and it’s the one most pilots skip.
The agent needs a defined response to losing access
This is where Identity connects to the rest of the design. An agent with its own scoped identity can be revoked on its own, without taking anything else down. The scope also bounds the worst case: the narrower the credential, the smaller the set of records that could be mid-change when you pull it. That is the argument for one identity per system rather than one for everything.
Then specify what the agent does when a call fails with an auth error. Our rule is short: an authorization failure is a stop signal, not a retry condition. The agent does not retry, does not look for another credential, and does not try to finish “just this one step.” It writes a final checkpoint, marks the run as suspended with the reason, and raises it to a named human. What we write at that moment is the run state, the last confirmed step, and the steps not taken, all against the policy that governed the run.
Revocation also needs two modes. A hard revoke is for suspected compromise: access ends immediately and a human reconciles whatever was in flight. A drain is for everything else, including an employee departure or a policy change: the agent is told to finish its current unit, take no new work, and then lose access. Both are legitimate. The mistake is having only the first. The same thinking applies when an agent’s creator leaves, where the access question is usually a planned one and a drain is the better tool.
Where this still gets hard
Idempotency is only as good as the systems the agent writes to. Some APIs have no way to deduplicate a request, and some actions can’t be undone: an email sent, a payment triggered, a webhook fired. For those, the real control is the approval gate placed before the step, because rollback isn’t available after it. Starting with read-only access narrows how many of these you meet on day one.
Checkpoints also cost something. Writing state before and after every step slows the run and adds a store you now have to secure and keep available. Too few checkpoints and you’re back to guessing. Too many and you’ve built a workflow engine for a task a person does in four minutes. That judgment call is different for each process, and it should be made on purpose.
Finally, drills. A revocation path that has never been exercised against a real half-finished run is a theory. We would rather find out in a test environment that the agent retries on a 403.
The question to sit with
If you want to see where your current setup stands, a Book a diagnostic call is the place to start. Before that, try this: pick the agent with the most write access you’ve given anyone, and imagine pulling its credentials at a random moment tomorrow. Could you say which records it was changing, which step it had reached, and whether each one is safe to leave as it is?