AI Agents Need an Offboarding Process Too: The Login Handshake Nobody Revokes

Every company with an identity provider can answer “who still has access, and why” in seconds for its human employees. Ask the same question about the AI agent someone stood up for a two-week pilot four months ago, and the honest answer is usually a shrug. Its OAuth client is still registered. Its API key is still active in a .env file nobody remembers writing. Its scoped token, minted for a project that shipped or died months ago, still authenticates cleanly against your systems today. The login handshake it passes every single call is completely legitimate — and that’s exactly the problem. Nobody ever ran the equivalent of an exit interview.

Why AI agent offboarding is harder than employee offboarding

Employee offboarding has decades of tooling behind it: a joiners-movers-leavers process, a single identity provider, a checklist HR triggers the moment someone’s last day is entered into the system. Agentic actions don’t map onto that process cleanly, for a few reasons specific to how agents get built:

• There’s no HR event. An agent doesn’t resign or get terminated. It just stops being useful — the project it supported wraps up, the team that built it moves on, the prototype quietly becomes “temporary” infrastructure nobody owns. There’s no calendar date that triggers a review.
• One agent, many credentials. A single agent workflow might hold a database credential, three third-party API keys, and an MCP server token, each minted by a different team through a different path. Revoking “the agent” means finding and rotating all of them, not flipping one switch.
• A2A makes the blast radius recursive. Under Agent2Agent, one agent can configure or delegate to another, which can delegate again. Offboard the parent agent’s owning team and the sub-agents it spun up along the way may keep running on credentials nobody traces back to the original grant.
• Tokens outlive the reason they were issued. A long-lived API key handed to an agent for a demo doesn’t know the demo ended. Unlike a human password, nobody is prompted to rotate it, because nobody logs into it — it just sits in a config file, valid, until someone finds it.

What the handshake proves — and what it can’t

This is the same gap we’ve written about with SSRF and MCP tool poisoning: a clean authentication handshake answers one question — is this caller who it claims to be, right now — and nothing about whether it should still be a caller at all. OAuth, MCP’s connection auth, and A2A’s handshake are all point-in-time checks. They were designed to stop an impostor, not to notice that a legitimate credential has quietly become an orphan. An agent that authenticates perfectly today, against a task that ended in March, is not a security bypass. It’s a governance failure that never triggered an alarm, because nothing about the handshake is built to ask “should this still exist?”

That question only gets answered by something that sits outside the handshake entirely: a place that tracks every credential back to an owner, a purpose, and an expected lifetime — the same data-ownership problem we’ve argued shadow AI creates at the front end. Shadow AI agents are the reason nobody’s counting at onboarding; orphaned credentials are what that same gap looks like at the other end of the agent’s life.

The compliance angle: “list every agent with access to X” is now a real question

This isn’t hypothetical for teams working toward ISO/IEC 42001 or the EU AI Act’s oversight requirements. Both ask, in different language, for the same thing: a documented, current answer to what AI systems have access to which data, under whose authority, and how would you know if that stopped being true. We’ve mapped the ISO 42001 Annex A controls a broker covers before — access review is one of the load-bearing ones, and “review agent access” only means something if there’s one place that enumerates every active agent credential, not six teams’ worth of API key vaults and OAuth app registrations. An auditor asking “show me every agent that can read customer records, and prove the ones that shouldn’t anymore, can’t” is not a theoretical question in 2026. Most teams currently answer it by grepping Slack for who remembers.

The business case: revocation as a broker capability, not a project

Fullmakt brokers every credential an agent uses and every call it makes, which means offboarding an agent is a property of the broker’s data model, not a scavenger hunt across every system the agent ever touched:

• One registration, one revocation. Every credential an agent uses is resolved through its broker client registration at call time, never handed to the agent outright. Revoke that registration and every future call — across every protocol, every downstream API — stops immediately, whether or not the agent (or a cached token in an MCP client) still thinks it’s authorized.
• No orphaned long-lived secrets. Because the broker injects scoped, short-lived credentials per call instead of handing agents standing keys, there’s no .env file holding a key that outlives the project — the credential that could be forgotten simply isn’t in the agent’s possession to forget.
• A live inventory, not a Slack thread. Every agent principal, its owning team, and every credential resolved on its behalf is one query away — the answer to “list every agent with access to X” is a lookup, not an investigation.
• Recursive coverage under A2A. Sub-agents created or delegated to under A2A still resolve their credentials through the broker, so offboarding the parent doesn’t leave a trail of descendants running on grants nobody remembers issuing.
• A traceable record of exactly when access ended. The audit log captures the revocation event itself alongside every call made before it — so “when did this stop, and what did it do right up until then” is answerable from the same record, not reconstructed from memory.

FAQ

Why doesn’t OAuth token expiry solve this on its own? Expiry limits how long a single token lives, but most agent integrations renew or refresh automatically, and plenty of long-lived API keys never expire at all. Expiry reduces the window a stale credential stays valid; it doesn’t answer whether the agent behind it should still have access, or notify anyone when a task-scoped credential has outlived its task.

Is this the same problem as shadow AI? They’re the same governance gap at opposite ends of an agent’s life. Shadow AI is credentials nobody centrally tracked getting issued in the first place. Orphaned agent access is what happens next: credentials that were tracked, or at least known, when issued, but never revisited once the reason for issuing them disappeared.

Does A2A make offboarding harder than a single agent would? Yes, because delegation is recursive. If a parent agent’s team is offboarded but a sub-agent it configured under A2A resolves its own credentials independently, revoking the parent’s access doesn’t touch the sub-agent unless every credential in the chain routes through the same broker principal.

What’s the single most useful control for agent offboarding? Route every credential through one broker client registration per agent instead of issuing standing keys directly. Revocation then means revoking one registration, and it takes effect on the next call, everywhere, instead of requiring someone to find and rotate every secret by hand.

A login handshake that passes cleanly was never proof that access should still exist — it only ever proved identity at that moment. Closing the gap isn’t a stronger handshake; it’s a broker that knows, for every agent, who owns it and whether that reason still holds — and can cut it off everywhere, the moment it doesn’t.