Disabling an employee’s account does not necessarily stop an AI agent they set up. The agent can keep reaching production if it holds a separate API key, service token, OAuth grant, session, or cloud credential that was never tied back to the employee’s identity.
That is the access gap security teams need to close as agents move from drafting text to calling internal tools. A departed employee may lose SSO access at 8:12 AM, while an agent they configured continues to run scheduled tasks, query data, or trigger production actions under a derived credential.
Account disablement only revokes one identity
Offboarding workflows are usually designed around human access. Disable the identity-provider account, remove device management, revoke VPN access, rotate a few shared passwords, and close the ticket.
AI agents complicate that model because they can act through credentials created during setup. An agent may have a personal access token in a secret store, an OAuth refresh token issued to a third-party service, a cloud role with a long-lived trust relationship, or a Slack-connected workflow authorized months earlier.
Each credential can remain valid after the human account disappears.
The problem becomes harder to see when the agent’s activity looks ordinary. It may call the same internal API every morning, use a predictable service account, or run from an automation platform that security does not classify as a production client. The former employee is gone from the access review. The agent’s credential is still active.
That distinction matters. Human offboarding answers, “Can this person log in?” Agent offboarding must also answer, “What can still act because this person once authorized it?”
Derived credentials turn ownership into an investigation
A security lead confronting this situation needs more than an account-disable confirmation. They need an inventory that connects every agent to an accountable owner, every action to an identity, and every credential to a revocation path.
Start with the agent itself. Identify where it runs, which tools it can call, which secrets it can read, and whether it acts on a schedule or in response to events. Then trace each permission back to its source.
That trace often crosses systems:
- An employee authorizes an agent through an OAuth consent screen.
- The agent stores a refresh token in an automation platform.
- The platform calls an internal API using a service account.
- The API grants production access because the service account belongs to a broad role.
No single dashboard necessarily shows the whole chain. The identity provider may show the employee disabled. The cloud console may show a healthy service principal. The automation platform may show a successful run.
This is why “disable the user” cannot be the end of the control. It is the beginning of the investigation.
Governed agent access needs an expiry date
Salesforce’s expansion of Headless 360, including MCP servers, reusable agent skills, Slack integrations, and developer tools, reflects a wider enterprise push to expose governed capabilities to authorized AI agents. The word that deserves scrutiny is authorized.
Authorization needs to stay current after the person who created an agent changes roles or leaves. That calls for controls built around agent identity rather than assumptions about the identity of the original builder.
A practical baseline includes short-lived credentials, narrowly scoped permissions, explicit agent owners, and automated review when an owner is offboarded. An agent that can read a production database should not inherit broad access because its creator once needed it for a prototype. An agent that can make changes should produce logs that distinguish its actions from those of a human user.
Ownership also needs a fallback. Teams should decide in advance whether an unowned agent is disabled automatically, reassigned to a manager, or placed in a restricted mode pending review. “Someone will know what it does” is not a control.
The same principle applies to connected tools. A Slack integration, a code repository token, and a cloud workload identity can each give an agent a route around a disabled account. Review them together, because attackers and accidents both follow the available path rather than the intended policy.
For a related example of how access failures surface at the worst possible moment, see Tuesday, 9:17 AM: Access Denied.
The offboarding test is an actual agent run
The useful test is operational: after disabling an employee, attempt the agent’s normal production action in a controlled way. Check its scheduled jobs, webhooks, API calls, queued tasks, and delegated permissions. Confirm that the expected revocation actually happened.
A clean identity-provider audit log proves only that the user account was disabled. It does not prove the agent stopped.
Teams should also review what happens when an agent loses access. Does it fail closed? Does it retry indefinitely? Does it fall back to a shared credential? Does an operator receive a clear alert? These details determine whether a revoked credential produces a safe failure or a quiet workaround.
The goal is simple: when a person leaves, every agent they owned should either have a documented new owner or lose the ability to act. At 8:13 AM, the production logs should show a stopped job, a denied request, or a controlled handoff. They should not show an autonomous process carrying on with yesterday’s authority.
Comments
No comments yet.