COMMENTARY: With the explosion of AI and agentic systems, businesses have inevitably launched (and abandoned) numerous pilots, programs, and agentic initiatives. Maybe a data team built an AI assistant to investigate support tickets, pull information from the data warehouse, and share findings in Slack. Or a marketing team experimented with an agentic workflow that could analyze campaign performance and make updates to the website.
But then priorities shifted; a better solution came along, or the project simply lost momentum. It doesn't matter the cause. What does matter is what’s left behind: the API keys in the config file that are still valid, the OAuth grant in the SaaS admin console that is still active, and the scheduled job still re-indexing customer records.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
These abandoned projects are hardly isolated incidents. IT has a long history of leaving legacy applications running, long after their intended usefulness. AI is simply allowing those same teams to build new POCs and MVPs at an unprecedented rate. And no one is “Starting with the end in mind,” planning the decommissioning when they start up the app.
The share of companies abandoning most of their AI initiatives before they ever reach production leaped from 17% to 42% year over year. At that scale, offboarding can't be an afterthought. In fact, improper offboarding ranks No. 1 on OWASP’s Top 10 Risks for Non-Human Identities. Every AI pilot needs an offboarding plan. The experiment isn't over until its access is shut off.
You offboard employees. Why not AI pilots?
The agents behind your pilot programs act, from a security standpoint, in a fashion not dissimilar to your workforce. They use credentials to authenticate as trusted identities, often operating through service accounts or relying on OAuth permissions granted by users or administrators. While the mechanism may vary, the result is the same: they access systems, retrieve data, and perform actions using real permissions.
When an employee leaves, offboarding kicks in. HR records the departure, and established IAM or IT processes revoke access. There is a clear lifecycle event that tells the organization this person should no longer have access. There is no standard process for offboarding an AI pilot. Sometimes there isn’t even a clear sign that it has ended. It might be shut down due to a major business shift. Or it may die a slow death; someone stops maintaining the workflow until, six months later, it’s obsolete. A 2026 Cloud Security Alliance survey found that just 21% of organizations had formal processes for decommissioning AI agents.
A canceled pilot leaves more than code behind
While the employee analogy works, it is important to recognize that it isn’t deep enough to capture the true exposure a pilot can create. Because a pilot isn’t a single identity. It might involve service accounts, API keys, OAuth grants, cloud IAM roles, vendor integrations, and MCP configurations. Some of these connect to real production systems, creating a complex web of access. Archiving the repo or shutting down the application doesn't revoke any of that access on its own.
This is further complicated by the fact that, even if the project itself has an owner, credentials and permissions it creates can end up spread across different systems and teams. The team that built the pilot may have shelved it months ago, but the cloud team still sees an active service account, and IT still sees an authorized SaaS integration. Neither necessarily knows those permissions belong to an abandoned experiment.
How to actually offboard an AI pilot
The good news is that we don't need to invent an entirely new security process to solve this. NIST's October 2026proposed design tenets call for agents to have their own identity, credential, and access management lifecycle, with short-lived, revocable permissions. But that lifecycle needs to account for what happens when an experiment ends, too.
Here's where to start:
- Assign an owner before the pilot starts: Give one person responsibility for the pilot’s identities, integrations, and eventual shutdown. That responsibility needs to survive cancellation, even when the team has already moved on.
- Inventory access as you build: Track credentials, service accounts, OAuth grants, cloud roles, vendor integrations, and scheduled jobs. Record what they can reach, who owns them, and whether other workloads depend on them.
- Give experimental access an expiration date: Use narrowly scoped, time-bound access and make renewal explicit. Short-lived credentials help, but the authority that issues them needs an expiration or revocation path too.
- Revoke access, don't just delete the project: Revoke API keys and OAuth grants at the issuer, disable dedicated accounts, and stop scheduled jobs and integrations. Check shared dependencies first. Deleting a config file doesn't invalidate its key.
- Verify before calling the pilot closed: Confirm revoked credentials can no longer authenticate, check logs for activity after shutdown, and make sure automations have stopped. Document the results and periodically review canceled pilots for anything missed.
Think about the AI pilots your organization abandoned this year. Could anyone tell you what access they created, who owns it, and whether that access has truly been revoked? If not, what exactly did you shut down?
