Here's a pattern I've watched repeat across more than a few engineering orgs in the last couple of years. A team gets excited about agents. Someone wires up a model with tool access, hands it an API key or an IAM role, points it at a real system, and it works. It books the meeting, reconciles the ledger, opens the pull request, triages the ticket. Everybody claps. The demo becomes a service. The service becomes load-bearing.
And then nothing. The agent just keeps running. It keeps its credentials. It keeps its access. Nobody scheduled its review, nobody owns its lifecycle, and six months later it's still holding a token that can read production data — and the person who created it has changed teams.
We got very good at onboarding agents. We never built the offboarding. And in security, the part you didn't build is the part that hurts you.
Agents are joiners, movers, and leavers too
For human employees we have a mature, boring, well-instrumented process. We call it joiner-mover-leaver, or identity lifecycle management, and we treat it as table stakes. A person joins, gets provisioned with least-privilege access tied to their role. They move teams, and their access is recalculated. They leave, and within minutes — ideally automatically — every credential they held is revoked. We audit it. Regulators ask about it. In financial services, you do not get to hand-wave this.
Now look at how we treat autonomous agents, which are arguably more dangerous than any single employee because they operate at machine speed, around the clock, without a conscience or a sense of self-preservation. They join with no formal provisioning record. They never "move" — their scope only ever expands, because the easy fix for "the agent couldn't do X" is to grant it one more permission. And they essentially never leave. There is no exit interview for a process.
This is the non-human identity problem, and agents are the sharpest edge of it. We've had service accounts and machine identities for decades, and we already manage those badly — most shops have a graveyard of stale service accounts nobody will turn off because they're afraid something breaks. Agents take that existing mess and add reasoning, initiative, and a willingness to chain tools together in ways you didn't anticipate. A stale service account sits there. A stale agent acts.
The real mechanic: you can't deprovision what you can't enumerate
Let me name the actual failure, because it's more basic than people want to admit. The reason most organizations can't offboard their agents is that they can't list them. Ask a security leader to produce, on demand, a complete inventory of every autonomous agent operating against their systems — what each one is, who owns it, what it can touch, what credential it presents, and when that credential expires — and watch the room go quiet.
That inventory is the whole game. Everything downstream of it — review, rotation, revocation — is impossible without it. And it's hard to build precisely because onboarding was so easy. Agents got created in notebooks, in CI pipelines, in a SaaS tool's "connect your account" flow, in someone's personal automation that quietly became critical. They authenticate as a human user with a long-lived personal token, or as a generic service account shared across five workloads, which means when something goes wrong you can't even attribute the action to a specific agent. The identity is smeared.
So before anyone buys a shiny agent-governance platform, the unglamorous first move is the one that actually matters: establish identity. Every agent gets its own distinct, attributable identity — not a shared key, not a human's borrowed credentials. If you can't tell which agent did a thing from the logs, you have no lifecycle. You have a fog.
Scoped, short-lived, and revocable by default
Once an agent has a real identity, the credential model has to change. The default pattern I see — a long-lived API key or static access key pasted into an environment variable — is exactly the wrong shape for something autonomous. Long-lived secrets are the thing you forget to rotate and can't easily revoke without breaking the workload, which is why nobody revokes them.
The public cloud already gives you better primitives, and they're not exotic. On AWS, an agent running on your infrastructure should assume a role and receive short-lived STS credentials scoped to exactly the actions it needs, rather than carrying a permanent access key. You can attach session policies that further narrow what a given invocation is allowed to do, and you get the assume-role event in CloudTrail as a clean audit anchor. The pattern generalizes: OAuth with narrow scopes and short token lifetimes, workload identity federation so the agent proves what it is instead of presenting a secret, per-task credentials that expire on their own. The principle underneath all of it is the same — make the credential scoped, short-lived, and revocable so that the absence of cleanup isn't catastrophic.
This is also where least privilege stops being a slogan. An agent's blast radius is the union of every permission it holds times its willingness to use them creatively. Scope it to the task. Resist the reflex to grant the broad permission because it's faster. And treat permission expansion as a change that requires the same scrutiny as giving a human elevated access — because functionally, that's what it is.
Build the leaver event before you need it
The piece everyone skips is the actual deprovisioning. Decide, at creation time, what kills this agent. What's the revoke path? Who can pull it, and how fast? If an agent is compromised — prompt-injected into exfiltrating data, or simply behaving in a way you didn't sanction — can you cut its access in seconds without taking down half the platform? If the honest answer is "we'd have to find the key and figure out what it breaks," you don't have a security control, you have a hope.
A few things make the leaver event real rather than theoretical. Give every agent credential a hard expiry, so that doing nothing results in deprovisioning rather than indefinite access — fail closed, not open. Tie the agent's existence to an owner who is a current employee, and re-validate that ownership on the same cadence you re-validate human access. Run a recurring review that flags agents which haven't been used, haven't been confirmed, or have quietly accumulated scope. And rehearse the kill switch, because a revocation path you've never tested is just documentation.
None of this is conceptually new. It's the same identity lifecycle discipline we already apply to people, pointed at a population of non-human actors that is growing faster than any headcount plan and operating with far less oversight. The organizations that get this right won't be the ones with the most agents. They'll be the ones that can answer, without scrambling, a deceptively simple question: show me everything that has access right now, and show me how you'd take it away.
So here's the challenge. Don't start with a governance framework or a vendor. Start with a list. Go enumerate the agents holding live access to your systems this quarter, name an owner for each, and find the ones you can't account for. The gap between what you find and what you expected is the size of the problem you've been carrying. Better to measure it yourself than to have an auditor — or an attacker — measure it for you.
