AI Blue Teaming Explained: The Three Layers a Control Can Actually Live In

Ask a security team where its AI guardrails live and the answer usually names a policy document, a system prompt, or a vendor feature. None of those is a control. A control is something that decides, at the moment of an action, whether the action happens — and for an AI agent there are only three places that can decide: the model, the gateway in front of it, and the environment around it. Everything a blue team can honestly promise comes from the second and third of those. This is the layer question, and it is prior to every other blue team decision, including what to log and who to call. It is also why the field evidence matters: the AI incident archive holds 400 agent incidents from 2024-12 through 2026-10-17, and most of them are not stories about a model behaving badly. They are stories about a deployment with no layer that could say no.

Blue teaming in the AI sense is the work of putting those layers in, tuning what they notice, and having a rehearsed answer for the day one of them fires. It is unglamorous, it does not produce a score, and it is the only half of the red-team/blue-team pair that changes the risk number.

What a blue team inherits, and what it does not

Traditional blue teaming rests on a set of assumptions that AI deployments quietly break. Logs were assumed to be complete, because the network saw every packet. Assets were assumed to be enumerable, because someone had to provision them. Behaviour was assumed to be deterministic, because a program does the same thing given the same input. None of the three survives contact with an agent.

What a blue team inherits instead is a system where the most consequential decisions happen inside a request the network layer treats as ordinary HTTPS traffic to one hostname. The prompt, the retrieved context, the tool calls, the completion — all of it is inside a request body, and if nobody is capturing and parsing that body, the deployment is functionally unmonitored regardless of how good the perimeter is. The first blue team task is therefore not detection; it is establishing a sensor. Without request-level and tool-level visibility there is nothing to detect on, and every downstream control is decorative.

Who can actually enforce the control

Once there is a sensor, the question becomes where each control is allowed to sit. The useful way to draw this is by ownership rather than by technology, because ownership is what determines whether a control survives the next release.

The model layer belongs to whoever trained it. You do not configure it, you cannot see inside it, and its behaviour moves when the vendor ships a new version — which may be any Tuesday. What you can do is pin a version and treat a version change as a change to your risk posture requiring a re-test. What you cannot do is claim a control here. "The model refuses harmful requests" is a property you are relying on, not a mechanism you operate.

The gateway layer is where every prompt and completion passes through a component you own. This is where budget and rate limits live, where allow-lists and tool permissions are enforced, where request and response logging is complete by construction, and where a request can be rewritten, blocked or rerouted before any token is billed. Gateway controls are also the only ones that remain attached when you change models, which matters more than it sounds: teams that put their controls in prompts lose them entirely the day they migrate.

The environment layer is the one that is entirely yours: credentials and their scopes, network egress, file access, sandbox limits on wall-clock time and spend. It is also where a compromised run does its damage. An agent that has been talked into acting maliciously is dangerous in exact proportion to what the environment allowed that action to reach — and the environment is the one place where "least privilege" is a configuration change rather than a research problem.

The practical test for any proposed AI control is one question: which of these three layers enforces it? If the answer is the model layer, the control is a hope. If the answer is "the system prompt", it is a suggestion inside the model layer, which is worse than a hope because it comes with documentation claiming otherwise.

Detect: what an agent actually emits

Detection for agents runs on a different signal set from detection for people. There is no login anomaly to correlate. What there is instead is a request stream with unusually rich structure, and four families of signal worth alerting on.

• Volume and shape of tool calls. An agent that suddenly calls a file-read tool forty times in one task, or whose tool sequence changes from three steps to thirty, is worth a look — not because it is malicious, but because the distribution moved.

• Content provenance at the boundary. Which text in the prompt came from the user, which from retrieval, which from a tool result, and which from memory. Most prompt-injection detection reduces to "instructional text appeared in a channel that should only carry data", and you cannot compute that unless the gateway labels provenance on the way in.

• Egress and scope edges. Requests for destinations outside the allow-list, reads of paths outside scope, attempts to use credentials outside their intended service. These are high-precision signals and they are cheap, because the environment already knows what was permitted.

• Spend and latency as a proxy. A runaway loop and a compromise both look like a cost curve changing slope. Budget alerts are the least glamorous detection in the stack and among the fastest to pay for themselves.

What is deliberately absent from that list is a classifier asked to judge whether a completion was harmful. It is the detection idea teams reach for first and the one that ages worst: it drifts with the model, it has a false-positive rate that trains your analysts to ignore it, and it gives you nothing to put in a runbook.

Contain: the three knobs that stop a bad run

Containment for an agent is simpler than it looks, because three knobs cover almost everything. Budget caps what a run can spend, which bounds both financial damage and the blast radius of a loop. Scope caps what a run can touch — the tools enabled for that task, the paths, the tenants. Sandbox caps how long it can run and what it can reach while running. All three are gateway or environment settings, which is another way of saying they are enforceable.

The design principle that matters is per-task scope rather than per-agent scope. An agent with a standing permission set is an agent whose permissions will accumulate until someone audits them; an agent that receives a task-scoped credential for the length of a task has a boundary that expires on its own. The second is more work to build and much cheaper to defend.

It is also where a gateway earns its name. Controls that live in front of every model call — tool and MCP calls graded before they run, content policy and personal-data masking applied before the request is billed — are the same controls whether the model behind them is the one you used last quarter or the one that shipped last week. That continuity is the actual product: not a better filter, but a place for the filter to live that does not move when the model does.

Recover: replay, patch, retest

Recovery for AI incidents has one advantage over recovery for network incidents: the entire run is usually recorded. Prompt, context, tool calls, completions, timings — if the gateway logged them, the incident can be replayed, which is a stronger starting point than most forensics gets.

Replay serves three purposes in sequence. It establishes what actually happened, rather than what the transcript suggests happened after several people summarised it. It identifies the control that should have fired, which is the difference between fixing a symptom and fixing a boundary. And it produces the regression case: a recorded input that must now be blocked, run against the new configuration to prove it is.

The patch step is where blue teams most often mis-aim. If the finding was a model behaviour, the available mitigations are all outside the model — a scope reduction, a filter at the gateway, a permission removed from the environment. If the finding was a system behaviour, the fix is in the configuration and the regression test is cheap. Either way, retest is not optional, because the fix and the model version both move, and a control that was verified against last month's build is a claim about last month.

Rehearsing the day it fires

A runbook that has never been read under pressure is a document, not a capability. The rehearsal that pays is narrow and specific: take one plausible agent incident, walk it end to end, and time each step. Who notices? How long until a human is looking at the right log line? Who can stop the run — one named person, or a committee? Who can revoke the credential, and how long does revocation take to propagate? Who decides whether to notify anyone outside the company?

Two of those questions catch teams out reliably. "Who can stop the run" fails when stopping requires someone who is asleep, so the answer needs to be a mechanism rather than a person — a budget cap or a kill switch that a duty engineer can pull alone. "How long does revocation take" fails because credentials are often cached in components that were not in the diagram.

Reading the archive is the cheapest form of rehearsal available, because it lets you inherit other people's incident structure instead of inventing your own. Take a handful of entries that resemble your deployment, and for each one ask the three questions above. The entries where you cannot answer them are the gaps in your runbook, and you found them before the incident rather than after.

The asymmetry worth stating plainly

Red teaming and blue teaming are not symmetric activities and should not be budgeted as if they were. A red team run is bounded by a schedule and produces a set of findings that decay as the target changes. A blue team's controls persist, compound and are the only thing actually standing between a bad input and a bad outcome. One engagement can find a boundary; only the other can hold it.

Which makes the honest standard for a blue team unglamorous and checkable. For every control you claim, you should be able to name the layer that enforces it, the log line that proves it fired, the alert that tells you when it did not, and the person who can turn the run off. Four sentences. If one of them is missing, the control is a policy document, and policy documents do not read request bodies.