Your team spun up AI agents across Notion, Jira, and GitHub over the past two weeks. Onboarding was almost insultingly easy — one API key (a password that lets software talk to other software), a few clicks, maybe a coffee break. The agent reads your tickets, pushes code, posts in Slack. You felt like the future had finally arrived.

Then the pilot ended. Or your security team woke up. Or you switched vendors. And now you need to answer a question nobody thought to ask: how do you actually turn an agent off?

The Cloud Security Alliance survey, released just yesterday on April 21, puts a number on the gap: only 21% of enterprises have any formal decommissioning process for AI agents. Meanwhile, 65% have already experienced agent-related security incidents in the past year. Anthropic shipped Managed Agents on April 8, OpenAI updated its Agents SDK on April 15, and Google unveiled its agent platform at Cloud Next on April 22 — three production-grade launches in a single two-week window. Each platform published detailed onboarding guides. None — literally zero — published an offboarding guide.

What "turning off" an agent actually means

Decommissioning an agent isn't flipping a switch. It's more like firing an employee who has keys to every office, remembers every conversation, and set up a dozen automated workflows that nobody else understands.

Here's the real checklist nobody wrote:

  • Revoke OAuth tokens — OAuth is the system that lets an agent access your tools (GitHub, Jira, Slack) on your behalf. When you "connect" an agent to a tool, you grant it a token — a digital pass. That pass doesn't expire when you stop paying for the agent. It just sits there, valid and forgotten.
  • Purge memory stores — Agents now have persistent memory: they remember past conversations, decisions, and your data. Anthropic's Memory Stores API lets you delete memories one at a time, but offers no bulk-delete endpoint. You want to wipe everything? Enumerate every single memory and delete them individually. Fun.
  • Cancel scheduled actions — Agents can run on cron schedules (automated recurring tasks, like "check this repo every morning at 9 AM"). Those schedules persist under the creating user's identity. The user leaves the company, the cron keeps running.
  • Reassign open work — If the agent had open pull requests, assigned tickets, or pending reviews, those now belong to a ghost.
  • Notify dependent agents — In multi-agent setups, other agents may call the retired one. They'll fail silently or, worse, hang forever.

No platform automates any of this.

The numbers are worse than you think

According to Token Security CEO Itamar Apelblat, interviewed on April 9: 65.4% of agentic chatbots have never been used since creation, yet retain live access credentials. More than half of external agent actions rely on hard-coded credentials instead of OAuth — meaning you can't even revoke them through standard identity management.

"Many organizations are still treating AI agents more like disposable productivity experiments than governed identities," Apelblat told Help Net Security.

He's being polite. What he means is: you set up a bot with read access to your production database, got bored, and left it running with the keys in the ignition.

The real threat: zombie credentials

The danger isn't the zombie agent itself. A dead agent that can't run is harmless. The danger is the zombie credentials — the OAuth tokens, API keys, and service account permissions that outlive the agent.

An agent authorized to read your Jira, push to your GitHub, and post in your Slack doesn't lose those permissions when you stop paying Anthropic or OpenAI. Those grants live in your identity provider, your SaaS apps, your cloud IAM (Identity and Access Management — the system that controls who can access what). The agent platform doesn't even know they exist, because it never granted them.

Microsoft recognized the problem three weeks ago when it open-sourced its Agent Governance Toolkit on April 2 — seven packages covering all 10 OWASP Agentic AI risks (OWASP is the standard catalog of application security threats), complete with an emergency "kill switch" and a "trust decay" model that reduces agent permissions over time. Sounds great. But read the docs carefully: they cover runtime security — what happens while the agent is alive. They don't cover decommissioning or credential cleanup. The toolkit helps you watch the agent. It doesn't help you bury it.

CSA's Hillary Baron, AVP of Research, summarized it on April 21: "AI agent security and governance encompass an interconnected system spanning visibility, lifecycle management, policy, and monitoring." Translation: you need to see every agent, manage its entire life from birth to death, set rules, and watch everything. Enterprises currently do approximately none of this.

You've been here before

Employee offboarding — the formal process of revoking access when someone leaves a company — took enterprises roughly 20 years to codify into standards like SCIM (a protocol for automatically managing user accounts across services) and JML provisioning (Joiners, Movers, Leavers — the HR-to-IT workflow). Twenty years, and most companies still get it wrong.

Agent offboarding is at day zero. But enterprises deploy agents faster than they ever hired humans. The CSA survey found 51% of shadow agents — agents nobody officially approved — emerge from internal automation and scripting. Your developers spin up agents the way they once spun up EC2 instances in 2012: fast, cheap, and with zero thought about who cleans up.

The platform that ships agent lifecycle management — a complete deploy-to-decommission workflow with credential cascade, memory purge, and dependency notification — wins enterprise procurement. Until then, every retired agent is a door you forgot to lock. And you have a lot of doors.