An operations lead builds an agent that pulls invoice data from the ERP and drafts approval requests in Slack. To get it working fast, she authenticates it with her own SSO login and generates a personal API token for the ERP connection. It works well, gets adopted by two other teams, and six months later she takes a new job elsewhere. Her account is deactivated on her last day, per the standard offboarding checklist. The agent keeps running for another three weeks before anyone notices, because nobody put it on that checklist in the first place.
This is not a hypothetical edge case. It is the default outcome of how most agents get stood up, because the fastest way to authenticate an agent is to borrow a person’s credentials.
An agent built on a person’s login has no owner but a person
When an agent authenticates as “Sarah” instead of as itself, every system it touches only knows about Sarah. IT offboarding checklists are built around employee accounts, SSO groups, and device wipes — not around the list of automations quietly running under someone’s name. Revoking Sarah’s access revokes the agent’s access too, but only by accident, and only if someone remembers the agent exists.
More often, nobody remembers. The API token was generated once, dropped into an environment variable or a workflow tool, and never tied back to an HR event. The agent keeps running on a credential that technically belongs to someone who no longer works there, with no one accountable for what it does next. If it fails, breaks a downstream system, or gets flagged in a security review, the trail leads to a departed employee who can’t explain it and a manager who didn’t know it existed. That’s not an audit trail — it’s a dead end.
Agent identity needs its own lifecycle, not a borrowed one
The fix is to stop treating an agent’s credential as an extension of whoever built it. An agent needs its own identity — created, scoped, and revocable independent of any single employee’s account, the same way a production database shouldn’t depend on one engineer’s personal SSH key just because they were the one who provisioned the server.
Concretely, that means three things. First, the agent gets a service identity at creation — its own credential, its own entry in the identity system, scoped to exactly the systems and actions it needs and nothing else. It is not “Sarah’s automation.” It is “the invoice-approval agent,” owned by a role or a team, not a person. Second, that credential goes through the same rotation cadence as any other service credential — not “whenever someone remembers,” but on a schedule, independent of whether the original builder is still around. Third, and most overlooked: revocation gets tied to the event that should trigger it. If an agent’s approval policy or scope was designed around one person’s judgment or one person’s access level, that agent needs to be re-reviewed — not just re-keyed — whenever that person leaves the process, not just the company.
This is what we mean by identity as one of the five things a production-grade agent deployment has to get right, alongside orchestration, knowledge, governance, and audit. When we design a deployment, the agent’s credential is never a stand-in for a person’s login — it’s issued to the agent as its own scoped identity from day one, which means offboarding an employee never has to be the moment someone discovers an orphaned automation. If your organization is running agents today and isn’t sure whether any of them would survive their builder’s departure, that’s a reasonable thing to check before it becomes a problem — book a diagnostic call and we’ll walk through what’s actually running and under whose name.
Where this still takes real judgment
Giving every agent its own identity is straightforward for agents with a clear, narrow job — the invoice-approval agent, the ticket-triage agent. It gets harder for agents that were built organically, stitched together from someone’s personal scripts and one-off API keys across three different systems, where nobody can fully enumerate what it touches anymore. Untangling that is real work, not a checkbox.
There’s also a temptation to over-formalize this and create a heavyweight provisioning process for every small automation, which just pushes teams back toward personal tokens because they’re faster. The goal isn’t bureaucracy — it’s making the scoped, owned path the easy path, so nobody reaches for a personal login just to ship something by Friday.
The question to sit with
Pull up the list of AI agents or automations running in your business right now, and for each one, ask whose login or API key it’s actually running under. If the honest answer is a specific person’s name rather than a role or a system account, ask what happens to that agent the day that person’s account gets deactivated — and whether anyone would notice if it didn’t.