An employee creates an AI agent to automate part of their workflow, then leaves the company six months later. That worker may no longer have access to the organization’s accounts and data, but the agent could still be working away in the background, accessing enterprise systems and potentially taking actions, without a clear chain of responsibility for the results.
As companies increasingly incorporate AI agents into their workflows, they put a considerable amount of thought into their design, approval, deployment and monitoring. But what happens when an AI agent outlives its usefulness? Less attention might be paid to this part of the agent’s lifespan and the potential consequences can have real business impacts.
This potential issue is growing alongside the increasing adoption of enterprise AI agents – the average global Fortune 500 company could have more than 150,000 agents in use by 2028, according toGartnerforecasts. With potentially thousands of agents in use in larger companies, informal retirement procedures for the ones no longer in use aren’t reliable and won’t scale.
Josh Piper, product manager at software company Datactics, compares this issue to the orphaned accounts enterprises have already developed onboarding procedures to address. Just as with these accounts, an AI agent may have been deployed for a specific project that has since ended, or whose lead has moved to another role, while its associated API keys, service account, workflow integrations and scheduled triggers stayed active.
“The big difference between an orphaned account and an agent is that an agent can act. Governance debt on an account is dangerous. Governance debt on an autonomous system compounds this,” Piper said.
Why hitting the off switch isn’t enough
The qualities of an AI agent – the ones that make them potentially so beneficial for an organization – are the same ones that make them more difficult to retire than an unused application.
Depending on the capabilities they have and the permissions and credentials they were given, an AI agent might be performing business-related operations like triggering downstream processes, sending tasks or data to other agents, writing to databases or business systems, operating through APIs, or supplying information critical to another workflow. The result is that risk is created in both directions: disabling the agent or leaving it running. Abruptly disabling an agent, without a comprehensive retirement plan in place, could break other processes and workflows in the organization. But leaving an obsolete agent running increases the enterprise’s attack surface and creates potential issues for security, accountability, cost and compliance.
It can be more complicated than expected just to determine if an agent has, in fact, been switched off. Group memberships, API tokens, automation hooks and scheduled triggers can exist independently of the interface that controls an AI agent. This can create a “zombie agent” that appears retired but still has some ability to operate, Piper says.
Genuine agent retirement means understanding its entire operational footprint, not just disabling its front end, he says. That’s why when done well, AI agent retirement needs to go beyond simple deletion into dependency management. For example,AWS’s guidance for agentic AIwarns that organizations without a lack of lifecycle discipline will be left with a growing number of undocumented services with dangling permissions and forgotten owners.
Mapping dependencies and creating an offboarding process
These risks can be prevented by putting a retirement framework in place and doing so beginning with the agent’s creation, not its obsolescence. For example, Microsoft’slifecycle guidance for AI agentsrecommends treating them not as projects but as products, complete with a defined owner and a set route from deployment to monitoring and, when appropriate, retirement.
An agent inventory or registry is a way to track the information that informs that framework. An agent’s operating record should document why it exists, what it can access and do, who owns it, which of its logs should be retained and what could break if it disappeared, says Chris Seymour, cofounder and principal of GS Consulting.
“The purpose of an AI agent should not be a mystery just because the person who created it moved on,” Seymour said.
An inventory can also document the agent’s data sources, other agents connected to it, associated credentials and how critical it is to enterprise operations. Discovering these dependencies once someone wants to shut an AI agent down is much more difficult if they haven’t been documented over its lifecycle.
The information in an agent inventory can then be used to develop a retirement framework that allows you to map the dependencies of your workplace’s AI agents. Before any obsolete or unused agent is shut down, that retirement framework should be used to answer questions around four key concerns:
For dependencies, determine the other processes, workflows, applications, data, etc. that depend on the AI agent in question. What needs to be replaced or rerouted to ensure those continue upon the agent’s retirement? If some of these dependencies are also no longer needed, do they need to be stopped when the agent is gone?
AI agents often have authorities or permissions – including tokens, credentials, service accounts, API access, permissions, or delegated authority – built into their automations. Which authorities should be revoked when the agent is retired and do they need to be reassigned? An agent’s credentials should be revoked as part of the retirement process, instead of planning to do so after the fact, theCloud Security Allianceadvises. But beyond the agent’s obvious credentials, the process should account for credentials, scopes, triggers, budget lines and dependent systems. Piper recommends inventorying all of these, then determining what must be transferred to a successor and revoking what’s not needed. He also recommends “tombstoning” the agent’s identity to prevent its name and credentials from being reused, then verifying that no further traffic is coming from it.
It’s also important to determine who can sign off on an AI agent’s retirement and who is responsible for verifying it has been shut down correctly and is no longer acting. And even when the agent is retired, it might still be necessary for regulatory, legal, or operational reasons to hold on to records and logs of its activity for some period. Before retirement, plan for which logs, outputs, decisions and audit trails should be stored and for how long.
Finally, depending on the number of agents affected and their complexity, it may be advisable to take a staged approach to retirement. For example, the AI agent’s write authority could be removed as an initial step, with a plan to monitor any unexpected downstream effects and watch for broken processes that emerge. Then, the agent’s integrations could be disabled in a progressive manner before it is ultimately deleted.
Enterprises should also establish the events that will trigger a review instead of waiting for someone to notice an AI agent has become obsolete. A change in an agent’s original context should prompt a decision about its continued use, Seymour says. Those changes could include the end of the agent’s original project, changes to the technology or workflows around the agent, the failure of one of the agent’s controls, or a change in its owner’s role.
In addition to applying this framework to individual AI agents, it’s possible to prevent the creation of future orphaned agents by using some best practices. These include ensuring every agent has a named owner along with a procedure for assigning a new owner when the existing one leaves the company or moves to a new role. Enterprises should also set dates for the review or expiry of agents upon their deployment and plan to regularly review and recertify each agent’s permissions and business use cases. And in addition to the use of an agent registry, enterprises can prevent and surface abandoned agents through usage monitoring and automatic flags for those without active owners.
Every AI agent needs an exit plan
To prevent the mushrooming of obsolete, abandoned AI agents as their enterprise adoption continues to grow, agent retirement should become a normal part of their operation, not something improvised every time one has outlived its usefulness to the business.
Planning for an agent’s retirement when it’s deployed is the most effective way to ensure that process goes smoothly. With each new approval, organizations should ask not just what an agent is allowed to do but also who will eventually determine when that agent stops doing those things and what has to happen when that decision is made.
As enterprises move from experimenting with individual agents to incorporating them into business operations, agent retirement processes become increasingly important. “Most organizations are still figuring out how to use agents, never mind how to govern them,” Piper said. As that governance evolves around agent retirement, as with other aspects an AI agent’s lifecycle, he says, it should be proportional to what an agent is allowed to do.
