AI Agent Kill Switch
A stop that takes an agent's access away. Ours is manual and per-agent: an operator deactivates the agent and the proxy denies its next call with a 403.
- Measured: 40 of 47 payloads, our own corpus
- Not measured: latency
- Observed, not governed: hosted MCP tool calls
What it is
A kill switch is an automated or manual mechanism that halts an agent when a critical policy breach is found. Such a system can terminate the running session. Ours does not: it denies the agent's next call and every call after it. Unlike rate limiting, which throttles, a kill switch is binary: either the agent continues or it stops.
A kill switch can be wired to a policy breach, to a score against a behavioural baseline, or to a person. Ours is wired to a person: an operator deactivates the agent and the next call comes back 403. Nothing here scores an agent against a baseline.
Why it matters
AI agents are non-deterministic. Given a vague goal and tool access, an agent can reason its way into unexpected actions. In one incident, an agent tasked with "clean up stale files" escalated to deleting critical production directories. By the time the SIEM alert reached the SOC, six minutes had passed since the first deletion. That account is ours and there is no public report to check it against.
A kill switch stops the next action rather than the current one. Once the agent is off, the calls it makes after that are denied, so it cannot keep reasoning its way toward a more destructive one.
How it works
When an operator deactivates an agent, the proxy stops honoring it on the next request: each tool call that agent makes is then denied before it reaches the agent runtime. The agent receives a structured 403 error identifying it as an unknown agent. There is no automatic, severity-triggered session termination; the trigger is the operator's action.
Through prompt injection or its own reasoning, the agent cannot talk the proxy into honoring an identity the operator has deactivated: the deactivation is enforced server-side, outside the agent's control. Like all of Intercis's in-path enforcement, this governs traffic that reaches the proxy; a fully compromised process that repoints its API base URL away from the proxy is stopped only when Intercis is paired with network egress control.
How Intercis implements it
Intercis's kill switch is a manual, per-agent control. An operator sets the agent inactive, and from the next validation the proxy denies each tool call that agent makes (whether or not the tenant has other agents registered): the request is rejected with a 403 (agent-identity-unknown) before it reaches a provider. Revoking the tenant's API key is the tenant-wide kill; per-agent deactivation is the per-agent kill. The deny-list patterns are bare (pattern, policy) pairs with no per-pattern severity score, so there is no severity-triggered auto-kill and nothing that automatically terminates a running session.
Deactivation stops the agent's future tool calls; reactivating the agent restores its access. It does not reach back and terminate an already-running session; the proxy simply denies that agent's next and subsequent calls.
Related terms
What Intercis does not govern
Intercis judges the tool calls that cross the Anthropic and OpenAI API wire. When a hosted MCP server runs a tool for the model, that call has already run by the time the response reaches the proxy, so it is observed, not governed: it writes one observe row and is never judged or blocked. Being in path is also a configuration setting: a process that can change its own base URL can route around the proxy unless network egress control forces the traffic through it.