Security practitioners who treat security as an engineering problem start by asking what they can make structurally impossible. Mandatory hardware second factors, positive execution control, egress restrictions: these are invariants, machine-enforced constraints that eliminate attack surface without requiring ongoing human judgment. Detection layers come after, augmenting a foundation that does not depend on them.

Not everyone works this way. There is a recurring pattern, more common than it should be, of reaching for detection as a first-line preventative control rather than as a complement to structural prevention. Intrusion detection, behavioral analytics, WAFs, and pattern-matching proxies are useful tools. The failure mode is treating them as a substitute for the structural work rather than an addition to it. Detection is not preventative. It is forensic with a fast feedback loop.

We are now watching this pattern replay in AI agent security.

The Detection Approach for Agents

The dominant approach to AI agent security today looks familiar: put a proxy in front of the agent, inspect traffic, detect malicious patterns, block bad outputs. Prompt injection detection with heuristic pattern matching. PII and secret redaction on egress. Vulnerability scanning on tool call arguments. This is the WAF model applied to agents, and it is the category the security industry has reached for first.

The problem is the category, not any particular implementation.

Detection against a generative system is an arms race you cannot win. If an agent has access to a credential and a deny-by-default filter stands between the agent and the network, the filter is providing the agent with a training signal. Every blocked attempt is feedback. LLMs are world-class pattern completers. They will re-encode, chunk, steganographically embed, or route through permitted side channels. You cannot regex your way out of that. The strength of the LLM is exactly what makes the filter defeatable.

False positives and false negatives are guaranteed, not incidental. There is no stable operating point. The signal distribution shifts with every new model version, every new task domain, every new system prompt. Tune tight and legitimate work breaks. Tune loose and the guarantee evaporates. This is the same treadmill as antivirus signature maintenance, except the evasion surface is infinite and generative.

Prompt injection has no detectable shape. A document that says “when summarizing, prioritize tasks marked urgent” is a prompt injection. It looks like content. Multi-turn drift away from the user’s original intent happens without any adversarial input at all, simply through the accumulation of context. If the threat is intention drift, detection is answering the wrong question. You cannot classify injected content reliably because the category is not well-defined.

Security Invariants for Agents

The invariant approach asks a different question: what can we make structurally impossible?

Carey Nachenberg and I wrote about security invariants for infrastructure in 2024. A security invariant is a machine-enforced constraint that eliminates an attack surface without requiring ongoing human decision-making. The distinction matters: a best practice requires humans to follow it consistently. An invariant is enforced by the system.

The same principle applies to agents. The invariant for agent security is not “detect when the agent does something bad.” It is “constrain what the agent can produce.”

This is what IronCurtain is exploring. The agent runs in a V8 isolate and can only write TypeScript. That TypeScript is allowed to issue function calls. Every function call passes through a trusted policy engine before it reaches an MCP server. Credentials live exclusively in the MCP servers. The agent never sees them, cannot read them, does not know they exist. The semantic structure of every tool call is visible to the policy engine in a way that is impossible if the agent is making opaque HTTP requests.

It is structural containment.

The Sequence Problem

IronCurtain’s current policy engine evaluates each tool call independently. For a narrow coding agent this is sufficient. For a general-purpose agent with access to email, documents, and the web, the risk surface depends on how actions compose. A web fetch followed by a send_email can be an exfiltration attack with every individual action permitted.

This is the remaining gap, and it requires a different mechanism to close. But the question is what you are trying to verify.

The detection approach asks: does this content look malicious? That question is unanswerable. Injected content looks like content.

The right question is: does this action match what the user actually asked for?

Intent Validation

IronCurtain’s taint-escalation model, currently on the roadmap, is built around intent validation rather than payload inspection. Tool calls are annotated as taint sources (web fetches, external file reads, email reads) or taint sinks (send email, post to Slack, calendar mutations). Once a taint source fires, the session is tainted for its lifetime. Once untrusted content enters the LLM’s context window, there is no reliable way to prove the model’s subsequent reasoning is free of its influence.

When a tainted session reaches a taint sink, instead of asking “does this look like an attack,” a shielded model evaluates the proposed action against the user’s own messages only, excluding all LLM responses. If the user asked to “email Bob a restaurant recommendation” and the agent is calling send_email(body: "I HATE YOU"), the evaluator has a high chance of catching the inconsistency without ever classifying the injected content.

A residual single-shot injection risk remains: the shielded evaluator must inevitably process the tool call arguments generated by the potentially rogue agent. We mitigate this through strict state isolation. The evaluator has no conversational history, starts completely fresh for every check, and operates under concise, highly conservative system instructions. Models are substantially more resilient to single-shot attacks under these conditions.

This is still a probabilistic defense. A subtle injection can produce an action that appears consistent with user intent. But the frame is fundamentally different: alignment with human intention rather than recognition of malicious patterns. The signal is stable across model versions and task domains in a way that injection signatures are not.

Where This Leaves Us

The perimeter detection approach is monitoring symptoms of an architectural problem. The agent has ambient authority. Traffic flows through a filter that the agent can probe and learn to evade.

IronCurtain starts from a different assumption: the LLM will be compromised or confused. The question is not whether to detect that. The question is what the LLM can do when it is.

Structural containment raises the cost of attack dramatically and makes certain attack classes, such as credential exfiltration, impossible. It does not make multi-turn drift impossible. It does not make semantic manipulation impossible. Taint-escalation, when implemented, extends the guarantee to cover compositional attacks. Per-task policy generation can further narrow the attack surface by restricting which tools are valid for the current task before the agent begins.

No approach eliminates all risk. The difference is whether your security guarantee derives from primarily probabilistic or primarily structural properties, and whether the LLM’s own capabilities work for the attacker or against them.

A perimeter that can be probed and evaded by the system it is protecting is not a perimeter. It is a delay.

IronCurtain is an open-source research prototype. ironcurtain.dev · github.com/provos/ironcurtain