How to Offboard AI Agents and Prove Their Access is Revoked

Say someone on your team resigns, and their offboarding goes by the book: HR closes the ticket, IT disables their account, and their laptop comes back wiped. Weeks later, the agents they set up are still opening pull requests and calling model APIs on keys and tokens they created in other apps. Disabling their account in the identity provider never revoked those credentials, because the identity provider never issued them. Nobody approved that access for the agents, since as far as anyone could tell, the access was the person's own.

AI agent offboarding is ending an agent's authority, handing off or closing the work it does, and proving it can't act again, whether the agent is leaving or the person who owned it is. Agents usually run on authority someone else granted them, and that authority lives in the apps that issued it, where an HR ticket doesn't reach on its own.

A departing owner is only one of three ways an agent's access outlives its purpose. An agent whose job ended can keep a working key long after anyone remembers it, and a vendor can shut down a product while the grants your people gave it stay valid in your tenant. Below, you'll learn how to review a departing owner's agents during the notice period, hand them off on new credentials, retire idle ones by cadence, revoke a vendor's grants, and prove the access is gone.

When does an AI agent need to be offboarded?

An AI agent needs to be offboarded when its owner leaves, when its job ends, or when the vendor behind it goes away, and only the owner's departure shows up in your HR platform. How you end each one depends on whose authority the agent runs on, which is also the first question in working out how to secure AI agents. An agent's authority comes from a person's session, a grant someone clicked, or a key someone minted.

Ending the agent means ending that authority where it was issued, and each exit gets there by a different route. That's why AI agent offboarding can't hang off a single trigger. How agents gain and change authority over their whole life belongs to AI agent lifecycle management. The table below covers the way out.

‍

Movers belong in the first row, just as they do in an automated non-human identity lifecycle. When an owner changes teams and the new team won't own the agent, run that exit as if the owner had left.

An exit goes faster when it starts from an inventory of who answers for each identity. Lumos's non-human identity inventory, in beta, pulls service accounts and other machine identities from the sources you connect, starting with AWS, Entra ID, and OpenAI. Each one sits in a single table with its last activity and status. You set an owner and a business justification on each one, and the security agents and remediation that read from the same inventory reuse that ownership.

For your ten busiest agents, write down which exit each is most likely to take and what would fire today if it happened. Start with the ones where the honest answer is nothing.

Review a departing employee's AI agents during the notice period

The notice period deserves its own agent review, because people may automate their own hand-off before they go. That might be a scheduled summary for a successor, or an export job that copies their work to the team drive. Those agents get built in a hurry by someone on the way out, and nobody may be lined up to own them after the last day.

Four signals cover most of it. New tool servers show up in the person's agent call history, and new keys show up in model-provider consoles. New grants to AI apps appear in your identity provider's consent logs, and new scheduled runs appear under their name in your automation tools. For engineers, check these signals in the same pass as their personal keys and tokens, a step any plan for how to offboard an employee needs for technical roles.

For coding agents, you don't have to ask the person what they connected. Lumos MCP Governance, in beta for the coding agents it covers, keeps a call history you can filter by person, server, or tool, including servers people added on their own machines. Albus answers usage questions over that history, such as which servers someone started calling after their notice date.

Checking at notice and again in the final week catches the hurried hand-off work while the person who built it can still say what it's for. Once they're gone, the agent's purpose has to be reconstructed from its logs. Most resignations are clean, and a review done this way protects the person leaving too, since it shows exactly what they handed over.

Hand off a departing employee's AI agents on new credentials

When an agent's owner leaves, hand the agent off to a successor by default, and don't call the hand-off finished while anything the agent does still runs on the departing owner's authority. Stopping every agent the moment its owner's account is disabled breaks production work along with the risk, while handing it over intact keeps the old owner's access alive under a new name.

Offboarding AI agents through a hand-off means the successor re-decides the agent's credential, its scope, and its memory. Move the work onto a credential the service owns before you revoke the departing owner's token or key, since revoking first is how you find out what depended on it, usually in production. Where an app offers no service credential, use the successor's grant and flag it for review at their own departure.

Next, the successor approves the agent's access fresh, at the narrowest the job needs. The old grant was sized for the previous owner's role, and the agent probably uses only part of it. GitLab used Lumos to remove unneeded admin access and set up just-in-time access for critical entitlements. The same order works for an agent: cut what the previous owner held that the agent never used, then give the agent access that expires instead of the old standing grant.

Memory is the easiest of the three to overlook. An agent's memory can hold whatever the previous owner could read, from mail threads to customer records, and the successor may have no right to see any of it. Check the memory settings in the agent's own app, the files it was given as knowledge, and any vector store it searches. Review what's there, or reset it, before the successor takes over.

Skip the credential or the scope and you've built orphaned AI agents in practice, with a successor on paper and the previous owner's access underneath. For the credentials, follow the same hand-off rules for the service accounts and keys a departing person owned. Skip the memory review, the one step agents add, and the previous owner's data stays with the agent.

Build the hand-off list before the last day. Lifecycle Management in Lumos runs the leaver workflow from the HRIS event, so the hand-off review can start the day HR enters the departure. Alongside it, the Anthropic NHI connector, in beta, inventories the Managed Agents, service accounts, and API keys in a Claude Console org with the workspaces and roles each can reach. It also flags keys with no expiry and keys tied to a person, which go to the top of the hand-off list.

Before your next technical departure, pull the keys and tokens tied to that person in your model-provider consoles, code host, and automation tools, and mark each one "hand off" or "revoke." Have their manager sign the list before the last day.

Retire inactive AI agents before they become zombie agents

For an agent whose job ended, the leaver event is usually silence, so you decide in advance how long silence has to last. Set the window as a number of missed runs, three to start, based on the cadence recorded when the agent was registered. A monthly reconciliation agent looks dead after 30 days and isn't, while a daily triage agent idle for two weeks probably is. Keep a flat window of 30 to 90 days only for agents with no recorded cadence.

Automated dormancy rules last longer when they have an exception path. Marqeta automated onboarding and offboarding across more than 150 apps with Lumos. Its inactivity workflows reclaim unused licenses with exceptions built in, because pulling access from key stakeholders without warning costs you their support. Agents with no regular schedule, like a year-end close agent or an incident-response agent, need the same kind of exception, written down with the name of whoever approved it.

Silence only catches the agents that stop. An agent whose job ended can also keep running on schedule, filing reports nobody reads with keys nobody reviews, and the industry calls both kinds zombie agents. For those, the trigger has to be set up front: an end date when the agent is registered, or a question to its owner at each recertification about whether the work still matters.

A quiet agent is still a working credential, since it can hold a refresh token that keeps working. Access that outlives the task is one of the agentic AI governance challenges that offboarding has to close. To decommission an AI agent, disable it, revoke its grants at each issuer, and delete it only after nothing breaks.

Some of that cleanup can run without a ticket. In Lumos's Identity Agent Force, the NHI Owner Hunter watches service accounts and API keys and shuts down the dormant or over-scoped ones. For findings that need a decision, Remediation Workflows attach a proposed fix to the Identity Intelligence issue. A person reviews and launches it, with manual task steps for apps Lumos can't write to.

Both triggers depend on two fields captured when the agent is registered: its expected cadence and its end date. Add both to the intake for your AI agent identity and access management program. Agents registered before those fields existed need them backfilled by their owners, starting with the ones that hold production or customer-data access.

What happens to OAuth grants when an AI vendor shuts down?

When an AI vendor shuts down a product, the OAuth grants your people gave it can stay valid in your tenant until someone revokes them. A vendor can revoke the tokens it holds before it goes, but nothing makes it do that, and you can't tell whether it did without checking your tenant. Context.ai's AI Office Suite shows how far one of those grants can reach.

According to Context's April 19, 2026 statement, it released the suite in June 2025 as a consumer workspace whose AI agents could act across users' external apps. After stopping unauthorized access to its AWS environment in March 2026, Context closed the environment and hosting to fully deprecate the product. It later learned, with Vercel's help, that the attacker had likely taken OAuth tokens for some users before the shutdown. At least one Vercel employee had signed up with an enterprise account and granted "Allow All" permissions.

Vercel's security bulletin says the attacker used that access to take over the employee's Google Workspace account and then the employee's Vercel account. From there it pivoted into a Vercel environment and decrypted environment variables that weren't marked sensitive. Vercel also told its own customers to rotate secrets before deleting a project, since deletion doesn't retire them, and a product shutdown leaves the same gap for grants.

Context's statement doesn't say the deprecation revoked any of those grants. They were authorizations inside each affected organization's Google Workspace tenant, so confirming they were revoked was each organization's job. Vercel published the app's OAuth client ID to help other organizations investigate, noting the compromise potentially reached hundreds of users across many organizations.

Keep a list of the AI vendors holding grants or keys in your tenants, each with an internal owner. When a vendor deprecates a product, discloses a breach, or reaches the end of its contract, revoke its app's grants tenant-wide and block its client ID. Rotate any key you issued it and remove its tool servers from your clients' configs. Then review what its agents wrote while they had access.

Context says Vercel's OAuth settings appear to have allowed the employee to grant those broad permissions, which points to a cheaper fix earlier. Require admin consent for scopes that reach mail or files, and each approval adds a vendor to your list as it happens.

Grants are half of a vendor exit. The other half is any tool server your coding agents call at the vendor's endpoints. For the agents it covers, MCP Governance can deny those tools on their next call through per-tool policies, where the first matching rule wins. Its one-click Block writes is a quick first step that still lets reads through, and the product ships set to Allow, so the full deny is a move you make on purpose.

If the vendor's servers turned hostile instead of just going quiet, don't wait for a planned removal. Switch to the 15-minute deny that the MCP security best practices call for in an incident.

This week, export your tenant's third-party app grants, mark each app that runs agents or touches mail and files, and name an internal owner and a vendor contact for each. That export is the list you'll work from when the next vendor goes quiet.

How do you prove an AI agent's access is revoked?

You prove an AI agent's access is revoked at the app that issued it, after its tokens have had time to expire. For a key or token you hold, try it and watch it fail. For a grant a vendor holds, confirm the grant is gone from the app's admin console and that its logs show no successful calls once the token lifetime has passed.

Timing matters because a revocation doesn't always take effect everywhere at once. A deny rule in your AI agent access control can stop an agent's calls sooner, but it doesn't revoke anything, so the test still has to run at the issuer.

Under RFC 7009, the OAuth standard for token revocation, authorization servers must support revoking refresh tokens and should support revoking access tokens. Revoking a refresh token should also invalidate the access tokens issued under the same grant where the server supports that, and it can end the grant itself. So revoke the refresh token, and treat revoking a single access token as a partial step.

Access tokens already issued may keep working until they expire, especially self-contained ones that an app checks without calling back to the issuer. The RFC also notes that some servers can learn about a revocation before others. So wait out the longest access-token lifetime the issuing app allows before you test. Then run the test and read the app's logs with the at-source checks for a revoked AI agent's access.

After the test passes, keep the action log (who the agent acted for, which tool or app it used, when, and which decision applied) alongside the removal record for each credential. The agent's stored context and memory follow your retention policy, and legal decides anything under hold before it's deleted.

For the access Lumos removes, your auditor gets a removal record instead of a screenshot. Lumos offboarding runs on Account Workflows, so each removal it performs leaves a step-level removal record, and a removal that fails becomes an error task with a retry rather than a silent gap. That removal record shows the step ran, and the test at the issuer shows it held. If a retired agent's credential still works after the test date you set, the exit isn't over, and the ticket should reopen.

Build an AI agent registry that ends access in one change

The agent offboarding to aim for is one change to one registry entry, after which the agent's next call fails. In May 2026, CISA and the NSA joined four allied cyber agencies to lay out the controls behind that.

Their joint guidance, Careful adoption of agentic AI services, asks organizations to give each agent a distinct identity and to keep a trusted registry that binds identities to authorized roles. It also calls for the registry to be reconciled regularly against the agents that are live, and for access to be denied to any agent or key that isn't in it. Identity and authorization get checked on each request through a central policy decision point.

With those controls in place, offboarding an agent gets close to deleting a registry entry. Many of your agents borrow a person's session today, so they have no identity of their own to register, and the earlier steps still carry most of the load.

At Lumos Labs, we've said that making it safe to give agents more access requires interoperating with identity providers, agent runtimes, and emerging standards such as XAA for cross-app agent access. XAA is the informal name for a pattern in a draft IETF standard, the Identity Assertion JWT Authorization Grant. Under it, the identity provider decides whether an app or agent can get a token for another app's API, and the receiving app still applies its own policy.

Pull that permission at the identity provider, and no new tokens get issued. Lumos Labs is starting with agents that move money, change production infrastructure, or touch sensitive customer data, which are also the agents to put in your registry first.

A monthly reconciliation of the registry against tool-call and consent logs is what keeps it honest. An agent that shows up in the logs but not in the registry is the one your next offboarding will miss.

Take back the access every AI agent borrowed

A retirement checklist covers the exit where an agent's job ends. The other two start with an owner leaving or a vendor going quiet, and neither one files a ticket for the agents involved. So the agents still holding access after an offboarding are usually the ones nobody chose to retire. They run on a departed person's token, sit idle on a key nobody rechecked, or hold a grant to an app that no longer exists.

Start with the agents tied to your next three departures, while each owner can still explain what their agents do. Then set dormancy windows by cadence, give each AI vendor holding a grant an internal owner, and don't close an exit until the revoked credential fails at the app that issued it. Offboarding an agent turns out to be less about the agent than about whose access it was using.

Each of those steps goes faster when ownership is written down before anyone resigns, and Lumos keeps that inventory next to the controls that act on it. The leaver workflow starts from the HRIS event, the keys and service accounts a person owned sit under their name, and their coding agents' tool servers can be denied on the next call. Dormant credentials get shut down without a ticket, and each removal Lumos makes leaves a step-level removal record, so the evidence your auditor asks for arrives with the exit. See how Lumos ties people, the non-human identities they own, and their agents' tool calls together before your next departure.

‍

‍