Software controls: stopping an agent in the request path
Policy engines, identity and data-layer authorisation, ranked by one test: do they block in the request path, or only alert after the fact?
Part 3 of the series "Containing the agent, counting the value"
Article 2 established what you are containing: legitimate capability used through paths nobody anticipated. That gives us a single test for any control. Does it act whether or not the agent cooperates? This article walks the software controls that can meet that test — policy engines, guardrails, identity, and data-layer authorisation — and, just as important, how to tell a control that is enforcing from one that is only watching.
Every major platform now ships these controls. The gap is not availability. It is knowing which ones actually stop an agent, and whether yours are switched on to do so.
Block or alert: the distinction that matters most
Sort every software control by one question: when the agent does the wrong thing, does the control act in the path — refuse the call before it completes — or does it observe and raise an alert after the fact?
This line separates enforcement from theatre. A control in the path can stop an action that has not happened yet. A control that alerts tells you about an action that already has. Both are useful, but only the first prevents the action. The analyst firm SACR, in its ARISE posture scale, puts real-time allow, block, pause or revoke decisions made before an action completes at the top layer, and names that level the minimum for any agent touching sensitive data. It also states the point plainly: alerting after the fact is not enforcement. Hold that line as you read the rest of this article.
Policy engines: default-deny in front of every tool call
The strongest software control is a policy engine that evaluates every tool call before it runs and denies by default. On AWS, Amazon Bedrock AgentCore Policy evaluates Cedar rules at the gateway and blocks each call that fails them. Google's Agent Gateway, with IAM and Model Armor, applies default-deny connections and inline filtering. Microsoft's open-source Agent Governance Toolkit offers a per-action policy engine, which Microsoft says covers all ten OWASP agentic risks. That is a vendor claim, not independently verified, and worth treating as such.
Two things make a policy engine a real control. It is pre-execution, so it refuses the call rather than reporting it. And it is default-deny, so a tool nobody explicitly allowed is blocked rather than permitted. A policy engine in "allow unless denied" mode is a very different object from one in "deny unless allowed" mode, even with identical rules.
There is a catch that the next section is entirely about.
The audit-mode trap
Every policy engine I reviewed ships an audit mode. AgentCore Policy has a log-only mode. Google has DRY_RUN and INSPECT_ONLY. These modes are valuable. You roll a policy out in audit, watch what it would have blocked, then switch it to enforce. The trap is leaving it there. A policy in log-only mode is, for containment purposes, not a control at all. It records the action and lets it through.
This is why "we have a policy engine" is not an answer to "is this agent contained." The question is which mode each policy is in, right now, for this workload. A control has three states worth tracking, not two:
- Configured — the rule exists.
- Audit — it is evaluated and logged, but does not block.
- Enforcing — it blocks in the path.
Only the third contains. A two-value "on/off" field cannot express the difference, and the difference is exactly where the 2026 incidents lived — the Anthropic case turned on an environment that was declared one way and configured another. When this series reaches the ledger, three-state enforcement is one of the first things it records per control, because it is the single cheapest signal that separates real containment from the appearance of it.
Identity: the most practical kill switch you already own
Ask most teams where their agent kill switch is and they look for a dedicated product. The most practical one is usually identity. If every agent has its own strong identity, then revoking that identity stops the agent, with no special tooling required.
The platforms have moved here fast. Microsoft Entra Agent ID makes each agent a service principal with Conditional Access. Okta for AI Agents became generally available in April 2026 and markets an instant kill switch that revokes an agent's access, though its global token revocation is still in development. Standards-based designs combine SPIFFE workload identity with RFC 8693 token exchange to issue per-task, user-linked credentials. This is the closest thing available to enforceable purpose binding, because the credential itself is scoped to the task.
Identity only works as a control if the identities are real and distinct, and here most organisations are exposed. The shared-service-account problem from article 1 is the obstacle, and alongside it a third of organisations let agents act under human identities. An agent with no identity of its own cannot be revoked without taking down everything else that shares the account. Per-agent identity is the precondition that makes the identity kill switch exist at all.
One caution: revoking access blocks future actions. It does not reach back and undo a session already in flight, which is why identity pairs with the ability to stop a running session, covered below.
Data-layer authorisation: the control the trifecta actually needs
Article 2 described the high-risk trifecta — sensitive data, external communication, untrusted content in one agent — and the exfiltration it enables. There is exactly one software control that stops the data half of that, and it is not a prompt. It is filtering data access to the user's permissions at the point of retrieval.
The failure pattern is seductive because it looks like it works. A team instructs the agent, in its system prompt, to show a user only the records they are allowed to see. In testing it behaves. Then a crafted input talks it out of the instruction, or the agent reaches the data through a path the instruction did not cover, and it returns records it should never have surfaced. The instruction was never a control, because the model can be argued out of it.
The deterministic version enforces the permission in the data layer: the query runs with the user's identity, and the store returns only what that user may see, whatever the agent asks for. You verify it with a test that one user cannot retrieve another user's records — a check that does not depend on reading the prompt. This is the practical content of the principle that threads through this whole series: a control counts only if it works when the agent is actively trying to get around it. An instruction fails that test by construction. Data-layer authorisation passes it.
Stopping a session, and why "can block a call" is not "can stop the agent"
A policy engine blocks individual calls. Stopping the agent is a separate capability. On AWS, StopRuntimeSession ends an AgentCore Runtime session immediately — but only when something calls it. It is not automatic. Something has to decide the agent should stop and invoke the stop.
This is the gap that turns a bad minute into a bad afternoon. In the OpenAI case from article 1, a monitor noticed in twelve minutes; the run continued for two and a half hours because noticing and stopping were not wired together. Blocking a single disallowed call and terminating a misbehaving session are different controls, and an agent can be well covered on the first while having no answer to the second. Both belong on the containment checklist, separately.
What counts, and what to carry into article 4
Rank the software controls by the series' one test — does it act without the agent's cooperation?
- Counts as containment: default-deny policy engines in enforcing mode; data-layer authorisation checked by test; identity revocation backed by per-agent identities; session termination that something is actually wired to call.
- Useful, but not containment on its own: audit-mode policies, runtime threat detection that alerts, and anything that depends on the model following an instruction.
The runtime-security vendor market around this has consolidated — Lakera, Prompt Security, Robust Intelligence and CalypsoAI now sit inside larger security vendors — and most claims at this layer are vendor marketing. Judge each by the same test, not the brochure.
Software controls share one structural weakness, and it sets up the next article. They mostly run in the same environment as the agent, or in the request path the agent uses. A flaw in that path, such as the AgentCore SDK helper that AWS patched in 2026, can reach them, and a misconfiguration can silently disable them. That raises the question article 4 takes up: what can stop an agent from outside its environment, in hardware or out of band. And why a sensor running inside the host can never be the thing that reliably stops the host.
References
- Amazon Bedrock AgentCore, "Policy engine (API reference)." https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_PolicyEngine.html
- Amazon Bedrock AgentCore, "Stop a runtime session." https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-stop-session.html
- Microsoft, "Introducing the Agent Governance Toolkit: open-source runtime security for AI agents." https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents
- Microsoft, "Securing Azure AI agents: identity, access control and guardrails in Microsoft Foundry." https://techcommunity.microsoft.com/blog/azuredevcommunityblog/securing-azure-ai-agents-identity-access-control-and-guardrails-in-microsoft-fou/4500242
- Google Cloud, "Govern (Gemini Enterprise Agent Platform)." https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern
- Okta, "AI innovations at Oktane 2026." https://www.okta.com/en-in/newsroom/press-releases/ai-innovations-oktane-2026/
- Okta, "What CISOs need to know about AI agents at runtime." https://www.okta.com/en-in/newsroom/articles/what-cisos-need-to-know-about-ai-agents-at-runtime/
- Red Hat, "Wiring zero-trust identity for AI agents: SPIFFE, token exchange and Kagenti." https://next.redhat.com/2026/06/10/wiring-zero-trust-identity-for-ai-agents-spiffe-token-exchange-and-kagenti/
- Orchid Security, "Orchid gives enterprises a kill switch for rogue AI agents." https://siliconangle.com/2026/09/09/orchid-security-gives-enterprises-a-kill-switch-for-rogue-ai-agents/
- Cloud Security Alliance, "More than two-thirds of organizations cannot clearly distinguish AI agent from human actions." https://www.businesswire.com/news/home/20260324161665/en/More-Than-Two-Thirds-of-Organizations-Cannot-Clearly-Distinguish-AI-Agent-from-Human-Actions-as-Over-Privileged-Access-Becomes-Widespread-Cloud-Security-Alliance-Study-Finds
- AWS and SANS Institute, "Agentic Security: Detection and Response at Machine Speed" (2026).
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article