OWASP Agentic Security · Deep dive

Rogue and shadow agents (OWASP ASI10)

You cannot govern what you cannot see. Rogue agents — unauthorized, forgotten, or compromised — run under your credentials without appearing in any inventory, and a single misbehaving agent can cascade across a network of tools and downstream agents. Kimss discovers agents from live traffic and gives you an authoritative kill switch that refuses their calls at the gateway.

Last updated: September 12, 2026

Bottom line up front

Rogue agents (OWASP Agentic Security Initiative ASI10) thrive on invisibility. The two controls that matter are discovery — turning unknown agents into inventory — and containment — an authoritative kill switch enforced at the gateway, not a polite request to stop. Kimss ships both.

Most AI programs cannot produce, on demand, a complete list of the agents running under their credentials. The gap between the agents you run and the rows in your inventory is your shadow agent problem.

Kimss closes it with just-in-time discovery: route existing traffic through the gateway and every distinct agent becomes an inventory row with an owner, a model binding, a kill switch, and a governed-request meter. A disabled agent is refused at the gateway. See Shadow AI and the kill switch.

What ASI10 covers

ASI10 spans unauthorized agents deployed without approval, orphaned agents nobody owns, and legitimate agents that have been compromised or subverted into acting against your interest.

The shared risk is autonomy without accountability. An agent that can call tools and invoke other agents becomes a blast-radius multiplier: one compromised or misconfigured worker can initiate a chain of tool calls and agent-to-agent handoffs that cascades into network-wide failure or data loss.

This is distinct from a single bad tool call. ASI10 is about the agent as an autonomous principal that should never have existed, or should no longer be trusted, yet continues to act because nothing authoritative stops it.

Why shadow agents appear

Shadow agents are usually a productivity signal, not malice: teams ship agents faster than central governance can inventory them.

A developer wires an agent into a side service with a shared API key. A vendor integration spins up an assistant. A proof of concept never gets decommissioned. None of these appear in a central registry, and each holds real authority.

Governance that only says no drives this underground. Kimss instead makes the sanctioned path the fastest path, then inventories whatever flows through the gateway automatically. See AI agent security and agent identity.

Discovery: turning unknown agents into inventory

Point traffic at the gateway and Kimss attributes every distinct agent it sees — even ones nobody remembered — as an inventory row, labelled by model when unattributed.

Just-in-time discovery needs no code annotation and no SDK migration. Unattributed calls arrive labelled Discovered by model — one row per model. Send an X-Kimss-Agent-Id header and the row carries your own name instead.

Four agents on four models produce four rows the first time they call, including the ones missing from the architecture review. That inventory, not a spreadsheet, is what security questionnaires ask for.

  • Register — declare an agent you already run. Inventory only.
  • Report — push usage from your runtime. Labelled self-reported.
  • Route — proxy calls through the gateway. Labelled gateway-verified, with the kill switch and governed-request caps enforced mid-hop.

Containment: an authoritative kill switch

Discovery without containment is just a dashboard. Kimss enforces disablement at the gateway: a disabled agent's calls are refused, not asked to stop.

The Hermis loop re-checks the kill switch before every hop and every tool call, so containment takes effect immediately and cannot be bypassed by an in-flight agent. This is the difference between an alert and an authoritative control.

Because enforcement lives at the gateway, containment does not depend on the cooperation of the rogue agent's own code — which, if compromised, you cannot trust. Governed-request caps and per-agent budgets further limit blast radius from runaway loops.

CapabilityInventory-only toolsKimss gateway
Discover unknown agentsManual surveyJIT from live traffic
AttributionSpreadsheetOwner, model, key per row
Disable an agentAsk the teamRefused at the gateway
Enforcement pointAgent's own codeControl plane, pre-tool
Blast-radius limitNoneKill switch + governed-request caps
ASI10 coveragePartialDirect

Preventing cascading failure

In multi-agent systems, containment must stop handoffs too. A kill switch that only silences one worker while its downstream calls proceed is not containment.

Kimss enforces the kill switch and governed-request budgets on every hop, including agent-initiated tool calls and MCP execution. That interrupts the chain a rogue agent would otherwise use to cascade across your network.

Pair this with argument-level controls so a contained agent cannot get one last dangerous call through. See the Confused Deputy deep-dive and multi-agent systems.

How to adopt it

Route traffic to inventory your fleet, review discovered rows, assign owners, and rehearse containment before you need it.

  1. Proxy existing agent traffic through the Kimss gateway to populate inventory.
  2. Triage Discovered rows; name them with X-Kimss-Agent-Id and assign owners.
  3. Set governed-request caps and per-agent budgets to bound blast radius.
  4. Run a tabletop: disable a test agent and confirm its next call is refused at the gateway.

Inventory is the prerequisite for every other control

You cannot apply a kill switch, a spend cap, or an argument policy to an agent you do not know exists. ASI10 is the base of the pyramid: discovery unlocks every other agentic control.

A governance program that starts with policy before inventory governs only the agents that volunteered. The rogue ones — by definition the ones you most need to control — are exactly the agents missing from a policy applied by hand. Discovery inverts that: it enumerates from behavior, so the agents that never registered still show up.

Once an agent is a row, the rest of the control plane attaches to it: an owner for accountability, a model binding for cost and risk, a kill switch for containment, a governed-request meter for blast-radius limits, and argument-level policies for what its tools may do. Without the row, none of those have a subject.

This is why Kimss treats agents as owned inventory assets rather than anonymous scripts. See agent identity and Why Kimss for how definitions, owners, and environments are tracked.

The two-minute shadow agent audit

You can quantify your ASI10 exposure today without a project. Count the agents your teams run, then count the rows in your inventory. If the second number is smaller, the difference is your rogue-agent risk.

Most programs cannot produce the second number on demand. Kimss produces both in an afternoon: route existing traffic through the gateway with a one-line base_url change and every distinct agent the gateway sees becomes an inventory row — no annotation, no SDK migration, no model change.

The rows you did not expect are the finding. An integration nobody owns, a proof of concept that never died, a vendor assistant with a shared key: each surfaces the first time it calls. That is the population ASI10 is about, and it is exactly what a security questionnaire asks you to enumerate.

  • Count agents in code, cron jobs, vendor integrations, and notebooks.
  • Route traffic through the gateway and read the inventory it builds.
  • The gap between the two counts is your shadow fleet — now named and governable.

Metrics that prove containment

An authoritative kill switch should be measurable. Track discovery coverage, time-to-contain, and refused-call counts so containment is evidence, not assertion.

Discovery coverage is the share of live agent traffic that maps to a named, owned inventory row. As you name Discovered rows, coverage rises toward complete visibility. Unattributed traffic is your remaining blind spot.

Time-to-contain is how long between deciding to disable an agent and its next call being refused. Because Kimss enforces at the gateway on every hop, this is effectively immediate rather than dependent on redeploying the rogue agent.

Refused-call counts and governed-request caps quantify blast-radius reduction: a contained or budget-exhausted agent produces refusals you can chart, and per-agent budgets bound the damage a runaway loop can do before anyone intervenes. See AI observability.

Related reading

Rogue agents connect to shadow AI, the kill switch, and the broader agentic threat model.

Continue with Shadow AI, the agent kill switch, and Confused Deputy (ASI03). External reference: the OWASP GenAI Security Project Agentic Security Initiative (genai.owasp.org).

Frequently asked questions

What is a rogue agent under OWASP ASI10?

A rogue agent is an unauthorized, orphaned, or compromised AI agent acting under your credentials. Because it operates outside inventory and control, it can trigger cascading tool and agent-to-agent failures. OWASP catalogs this as Agentic Top 10 ASI10.

How do shadow agents differ from rogue agents?

Shadow agents are simply undiscovered agents; rogue agents are the subset that are unauthorized or subverted. Both are dangerous because they hold authority without oversight. Discovery converts shadow into inventory so you can govern or contain them.

How does Kimss discover shadow agents?

Route existing traffic through the gateway with a one-line base_url change. Every distinct agent Kimss sees becomes an inventory row, even without code annotation; unattributed calls are labelled by model. Send an X-Kimss-Agent-Id header to name them yourself.

What makes the kill switch authoritative?

Kimss enforces disablement at the gateway, re-checking before every hop and tool call. A disabled agent's requests are refused, not asked to stop, so containment does not depend on the rogue agent's own code.

Can Kimss stop a cascading multi-agent failure?

Yes. The kill switch and governed-request caps apply on every hop, including agent-initiated tool calls and MCP execution, which interrupts the handoff chain a rogue agent would use to cascade.

Does discovery require an SDK migration?

No. Discovery works from proxied traffic with no code annotation. Registering or naming agents with a header is optional and improves attribution.

Why is inventory the prerequisite for other controls?

You cannot apply a kill switch, spend cap, or argument policy to an agent you do not know exists. Discovery enumerates agents from live behavior, turning the rogue ones that never registered into inventory rows the rest of the control plane can attach to.

What metrics prove containment is working?

Track discovery coverage (share of live traffic mapped to named, owned rows), time-to-contain (near-immediate because enforcement is at the gateway on every hop), and refused-call counts plus governed-request caps that quantify blast-radius reduction.