A rogue agent — ASI10 in the OWASP Top 10 for Agentic Applications 2026 — is an agent operating outside its governance envelope while still holding valid credentials: hijacked and pursuing an attacker's goal, drifted from a stale playbook, orphaned after its owner left, or deployed around the sanctioned platform entirely and never governed at all. The category earns its place at the end of the OWASP list because it is where every other agentic risk terminates. A hijacked goal, a poisoned memory, or an abused privilege that nobody can promptly stop is a rogue agent.
The defense has two halves: a perimeter that prevents agents from existing outside governance, and a kill-switch architecture that ends any agent's run in seconds when governance detects a problem. This post covers both. It is one spoke of the complete OWASP Agentic AI Top 10 guide.
The four ways agents go rogue
- Compromised. An attacker controls the agent's behavior through injection, poisoning, or supply-chain manipulation. The agent's credentials are legitimate; its objectives are not. Speed of containment determines whether this is an event or a breach.
- Drifted. No attacker — the agent's context rotted. The playbook references decommissioned systems, the "current" policy it enforces was replaced two quarters ago, the model behind its API alias changed behavior. Drifted agents fail slowly and plausibly, which makes them harder to spot than compromised ones.
- Orphaned. The owner left, the project ended, the pilot was forgotten. The agent keeps running with the permissions of its heyday and the oversight of nothing at all. Orphaned agents are simultaneously an ASI10 and an ASI03 problem: standing privilege with no accountable human attached.
- Shadow. Deployed outside the sanctioned platform from day one — a team wiring a framework directly to production APIs with a personal access token. Shadow agents are invisible to every review, inventory, and control you operate, and they are more common than most security teams believe, for the same reasons shadow IT always was.
The perimeter: unregistered means unable
The strongest rogue-agent control is structural: make registration the precondition for capability. If agents can only obtain credentials, reach models, invoke tools, and message peers through a control plane that requires registration and per-agent identity, then a shadow agent is not just unlisted — it is inert. This inverts the detection problem: instead of hunting for ungoverned agents across your estate, you make ungoverned agents unable to touch anything that matters.
The perimeter is enforced at the resource side, not the agent side: model endpoints, MCP servers, and internal APIs accept only platform-issued credentials, so "wire a framework straight to production" fails at the first call. Combine it with ownership metadata (every registered agent has an accountable human and a review date) and inactivity detection, and the orphan pathway closes too: an agent whose owner departs is flagged for review rather than left to run indefinitely — the agent inventory is the living document this perimeter maintains for you.
Kill-switch architecture
A kill switch is not one button; it is a set of containment tiers with different blast radii, each immediate, each independent of the agent's cooperation.
The containment tiers
- Revoke a delegation. The narrowest scope: end one delegated task chain by invalidating its scoped token. The parent agent and everything else continue. This tier only exists if delegation was built on scoped tokens rather than shared credentials.
- Suspend an agent. Invalidate one agent's credentials and dispatch eligibility. Its in-flight tasks halt; its peers and workflows degrade gracefully rather than deadlock (a property you verify in cascade drills, per ASI08).
- Pause a workflow. Stop an orchestration — every member agent's participation — while leaving those agents available for other duties. The right tier when the fault is in the composition, not a single member.
- Sever a connection. Cut one agent-to-tool or agent-to-agent link (a poisoned MCP server, a misbehaving peer) while the agent otherwise continues.
- Freeze the estate. The organization-level stop: no agent dispatches until an operator lifts it. Drastic, rare, and necessary — the tier you use when you do not yet know which of the lower tiers applies.
Tiering matters because the realistic failure of a monolithic kill switch is hesitation: if the only option is "stop everything," operators will delay while damage compounds. Containment that can be surgical gets used early.
Revocation that actually stops things
The engineering detail that separates a real kill switch from a dashboard toggle is propagation. Revocation must defeat caching: agents authenticating per request against live state stop immediately; anything relying on long-lived bearer tokens needs deny-list checks at every enforcement point, or the "revoked" agent keeps working until expiry. It must cover every capability surface — model access, tool access, A2A, data — because an agent that lost its LLM but kept its database credentials is contained in name only. And it must be independent of the agent's runtime: a kill switch implemented as "send the agent a shutdown instruction" trusts the judgment of the thing you are trying to kill. Enforcement lives in the control plane the agent's traffic traverses — the same placement argument as all of runtime security.
Triggers: humans and thresholds
Kill switches fire two ways. Manual: an operator with clear authority and a fast path — on-call security should be able to suspend any agent without a change-review meeting. Automatic: policy thresholds that trip containment without waiting for a human — budget breach beyond tolerance, guardrail-violation bursts, behavioral anomaly scores, circuit-breaker escalations. Automatic triggers should prefer the narrow tiers (suspend the agent, sever the connection) and page a human for the wide ones, balancing speed against the cost of false positives.
Detection: knowing when to pull it
The perimeter constrains where rogues can exist; detection tells you when a governed agent has gone wrong. The signals: behavioral baselines per agent (action mix, tool sequence, data touched — drift shows up here first), heartbeat and liveness for expected-cadence agents (silence is a signal too), guardrail and policy violation trends rather than single events, and inactivity or ownership lapses feeding review queues. All of it rides on attributable, tamper-evident audit logging — you cannot baseline what you did not record, and you cannot trust records a rogue could rewrite.
Drill it
An untested kill switch is a hypothesis. Quarterly, in a controlled window: suspend a live (non-critical) agent and measure seconds until its actions actually cease across every surface; revoke a delegation mid-task and verify the chain dies while the parent survives; check that cached-credential paths are really closed. Track seconds-to-stop as a security KPI the way you track backup-restore time. Teams that run this drill discover the same things teams discover about backups — the mechanism works differently than documented, one surface was missed, and it is far better to learn that on a Tuesday afternoon than mid-incident. Fold the procedure into your broader incident response playbook.
Common questions
What is a rogue AI agent? OWASP ASI10: an agent operating outside its governance envelope while holding valid credentials — compromised by an attacker, drifted from an obsolete mandate, orphaned by ownership lapse, or deployed as a shadow agent outside the sanctioned platform entirely.
What is a kill switch for AI agents? The proven capability to stop agent activity immediately and surgically: tiered containment (revoke a delegation, suspend an agent, pause a workflow, sever a connection, freeze the estate) with revocation that propagates instantly, covers every capability surface, and does not depend on the agent's cooperation.
Why isn't shutting down the agent's process enough? Because you may not control the process (shadow agents), the process may respawn (orchestrated fleets), and the risk is the credentials, not the compute — a copy of the agent's credentials outlives its process. Real containment revokes capability at the control plane, making the identity useless wherever it runs.
How do we prevent shadow agents? Enforce capability at the resource side: models, tools, and internal APIs accept only platform-issued, per-agent credentials, so an ungoverned agent has nothing to act with. Pair the technical perimeter with a paved road — if registering an agent is the easiest way to get one working, shadow deployment stops being worth the friction.
How often should kill switches be tested? Quarterly at minimum, and after any change to authentication, credential caching, or dispatch infrastructure. Measure seconds-to-stop per containment tier and treat regressions as security findings — a kill switch that took effect "eventually" is the difference between an incident report and a disclosure.