An engineer builds an agent. It has an API key, a schedule, and permission to write to a system that matters. It works, so nobody thinks about it again.
Eighteen months later the engineer leaves. Human resources triggers offboarding. The account is disabled, the laptop is returned, and the agent keeps running, because the agent was never the engineer's account. It was a separate identity the engineer created, and no process in the company knows it exists.
This is not hypothetical and it is not new. The same story has been true of cron jobs and service accounts for twenty years. What changed is the scale and the reach.
Why agents make an old problem harder
Three properties that a cron job did not have.
They act without a specific instruction. A scheduled script does the same thing every night. An agent decides what to do within a granted scope, which means its effect cannot be fully enumerated from its configuration. Reviewing it requires understanding what it is allowed to decide, not just what it runs.
They are created casually. Standing up a service account historically required someone with infrastructure access and usually a ticket. Creating an agent takes a developer minutes and often no approval at all, so the population grows the way shadow software as a service grew, from the bottom.
They accumulate delegated authority. An agent frequently acts on behalf of a person, using that person's context or tokens. When the person leaves, the authority should end. In most implementations it does not, because the delegation was recorded in the agent's configuration rather than in the identity system that offboarding actually touches.
Verizon's 2026 report recorded shadow AI use at 45% of employees, up from 15% a year earlier. That is the population this problem is drawn from, and it tripled in twelve months.
What makes this different from the cron job problem
Fair objection: unattended automation with credentials has existed since the first scheduled script, and organizations have muddled through. Three things have changed enough to make the muddling stop working.
Volume and rate of creation. Verizon recorded shadow AI use rising from 15% to 45% of employees in a single year. A problem that grows threefold annually stops being manageable by institutional memory, which is how service accounts were actually governed at most companies: somebody remembered.
Reach per identity. A cron job usually did one thing to one system. An agent given a broad scope can touch many systems and compose actions across them. The blast radius per unowned identity is larger, and it is harder to predict from the configuration.
Non-determinism. This is the one that genuinely breaks existing controls. A scheduled script does the same thing every run, so reviewing it once is close to reviewing it forever. An agent decides within its scope, which means a review tells you what it is permitted to do rather than what it will do. Change review, which assumes you can inspect the change, does not fit that shape.
None of this makes the old controls wrong. Ownership, least privilege, and lifecycle are still the answer. It makes them insufficient on their own, because all three assume you can enumerate behavior in advance.
The short answer
Require two fields at creation: a named human owner, and an expiry date.
Not a review date. An expiry. The agent stops working on that date unless somebody renews it. This inverts the incentive that creates orphans, in the same way that time-bound access does for humans, and for the same reason: an entitlement that expires does not need anyone to remember to revoke it.
Everything else in agent governance is downstream of those two fields, and no amount of downstream tooling compensates for their absence.
The discriminating variables
Does offboarding touch anything the agent depends on?
The test: if you disabled a specific engineer's account right now, would any agent they built stop working? If the honest answer is no, then agents in your environment are independent identities and offboarding will never catch them.
Can an agent's actions be attributed?
The test: pick a write that an agent made last week and trace it to the human accountable for that agent. If the trail ends at a service account, you have attribution to a credential, which is not accountability.
What is the blast radius of the largest agent?
The test: rank agents by what they can change rather than by how often they run. The agent that runs hourly and reads a dashboard is not the risk. The one that runs monthly and can modify a production configuration is.
Is there a kill path that does not require the creator?
The test: can somebody who is not the author stop this agent inside an hour, at 2am, without breaking anything else? If stopping it requires knowledge that left with the engineer, the agent is unsupervised regardless of what the inventory says.
Why offboarding is the wrong trigger anyway
A deeper point, since the departure case is only the most visible instance of it.
Offboarding is an event-driven control, and it catches exactly one event. An agent also becomes orphaned when its owner changes teams, when the project it supported is cancelled, when the team that ran it is reorganized, and when nothing happens at all and everyone simply forgets.
Only one of those four produces a human resources trigger. The other three produce nothing, which is why organizations that fix offboarding still accumulate orphans.
Expiry catches all four, because it does not depend on detecting the event. That is the whole argument for time-bounding over event-handling, and it is the same argument that makes time-bound access work better than perfect deprovisioning for humans.
Decision table
| Situation | Action | Why |
|---|---|---|
| Agent with no named owner | Assign or expire within 30 days | Unowned authority is the whole problem |
| Agent with write access to production | Named owner plus a second approver | Blast radius justifies the friction |
| Agent using a departing employee's delegated tokens | Revoke at offboarding, force re-delegation | The authority should not outlive the person |
| Read-only agent, low blast radius | Expiry date only | Do not spend governance on it |
| Agent nobody can stop without the author | Treat as an incident, not a backlog item | An uncontrollable production actor |
The offboarding checklist item that is missing
Concretely, what to add. Most organizations have an offboarding checklist that covers accounts, devices, physical access, and licence reclamation. Almost none of them cover delegated authority.
Three lines to add:
"List automations, agents, and scheduled jobs owned by this person." Owned, not created. If your inventory cannot answer this, that is the finding, and it is better to discover it during a routine departure than during a contentious one.
"Reassign or expire each one, with a named new owner." Not "review". Reassign or expire. A review step in an offboarding checklist becomes a ticket that closes without action.
"Revoke delegated tokens issued to automations on this person's behalf." This is the one that actually bites, because the agent keeps working after the human account is disabled and nobody notices until an audit or an incident.
The awkward part is that human resources triggers offboarding and human resources cannot answer any of these. The trigger has to fan out to whoever owns the automation inventory, which means the inventory has to exist first. That circular dependency is why this stays broken, and it is why the expiry-date rule matters so much: an expiring agent fails safe even when the checklist does not run.
What good looks like in a year
Not a maturity model, just the observable end state worth aiming at.
Every agent in production has a named human owner who would be paged if it misbehaved. Every agent has an expiry date, and renewals are a small recurring piece of work somebody actually does. Agents that can write to production carry a second approver, recorded. And somebody who is not the author can stop any of them inside an hour without breaking something else.
Four properties. None of them require a product. All of them are difficult to retrofit at scale, which is the entire argument for deciding them while the population is small enough to count by hand.
What changes the answer
A platform that mints agent identities natively. If agents are created through a platform that already requires an owner and issues short-lived credentials, most of this is solved by construction. Check before building process around it, because this is the fastest-moving part of the tooling market and the answer may have changed since the last time somebody looked.
A regulated environment. ISO 42001 and the EU AI Act both push toward an enumerated inventory with accountable owners, which means the governance work is required anyway and should be sequenced against the compliance date rather than against your own risk appetite.
Very small engineering teams. Under ten engineers, everybody knows what everybody built and the ownership problem is genuinely not real yet. The expiry-date rule still pays for itself, because it costs nothing to adopt now and a great deal to retrofit at forty engineers.
The objection worth taking seriously
The reasonable pushback on all of this is that expiry dates on agents will break production, and the person who set the policy will not be the one paged at 2am when a renewal is missed.
That is a real risk and it is manageable with two things. Make the expiry warning loud and early: thirty days, seven days, and one day, to the owner and their manager, not to a shared mailbox. And make renewal genuinely cheap, one click by the owner, no ticket, no review board. A renewal process with friction converts an expiry policy into an outage generator, and engineering will route around it within a quarter by creating agents outside whatever system you built.
The version that works is boring: expiry is long, usually ninety or a hundred and eighty days, warnings are loud, and renewal is trivial. The point is not to make people justify their agents every quarter. It is to guarantee that an agent nobody is watching eventually stops.
What to do Monday
List every credential in your environment that was created by a human but is not used by one. For each, name the accountable person and the date it should stop working.
The entries where you cannot fill in either field are your orphans. Do that exercise before buying anything, because the count it produces is the only input that tells you whether this is a policy change or a project.