AI Security Controls by Layer: What Each Control Buys You and What It Does Not

Ask three vendors what "AI security controls" means and you will hear filters, identity and compliance paperwork. All three are right, because the phrase has no agreed list. Here the controls are grouped by the question each one answers, which shows at a glance where your coverage is thin.

The layers and rows are an editorial synthesis from public sources, including the OWASP LLM guidance, the MCP specification, NCSC advice and the research cited inline. No standard or audit stands behind it. Every control is paired with what it gives you and what it leaves unsolved.

Seven questions, seven layers

1. Who acted? Identity and access.
2. What did it read? Input and context.
3. What did the model decide with? Model and prompt.
4. What could it call? Tools and integrations.
5. What did it actually do? Action and runtime.
6. What does it remember and expose? Data and memory.
7. What did you load and can you prove it? Supply chain and assurance.

Layer 1, who acted

Control	Buys you	Does not buy you
A distinct identity per agent	Attribution of every action	Protection when a correctly named agent is steered
Narrow tokens with short lives	A smaller yield from a theft or a hijack	Safety inside the granted scope
Delegation carrying an actor claim	Logs naming both the person and the agent	A verdict on whether the step was intended
Workload identity	No stored long-lived secret	Coverage for laptops that cannot attest themselves

Layer 2, what it read

Control	Buys you	Does not buy you
A map of inputs and who writes them	Knowing which sources outsiders control	Removal of hostile content
Labelling content as data	A better chance the model separates data from orders	A promise that it will
Input and output filters	Fewer crude attacks and less noise	Resistance to adaptive attackers

A 2025 paper reports that adaptive attacks bypassed twelve published defences, mostly at rates above 90 percent (arXiv:2510.09023), so treat filters as one layer among several.

Layer 3, what the model decided with

Control	Buys you	Does not buy you
Choosing and pinning a model version	Stable behaviour between releases	Immunity to injection
Rules in the system prompt	A statement of intent	Access control
Vendor adversarial training	A higher cost for attackers	A solution; the NCSC says the weakness may never be totally mitigated

Layer 4, what it could call

Control	Buys you	Does not buy you
A tool list per agent	A cap on what can be invoked	Safety for the tools that remain
Token audience checks	No reuse of tokens meant for other services; the MCP authorization specification requires servers to validate audience	A view on whether tool text is honest
Vetting and pinning tool servers	Less exposure to hostile servers	Detection of later changes unless you re-check
Diffing tool descriptions	A signal when tool text changes	Proof that the original text was honest

The audience rule is in the MCP authorization specification, and the wider picture is in the MCP security guide.

Layer 5, what it did

Control	Buys you	Does not buy you
A checkpoint before tool calls	Allow, deny or ask on each action	Quality beyond its rules and context
Approval screens showing the real action	Facts for the reviewer	Immunity to approval fatigue
Sandbox plus outbound limits	A ceiling on harm from a bad step	Safety when the rules live inside the sandbox
Rate and spend caps	Limits on loops and cascades	Prevention of one harmful action
A stop control	A quick halt for one agent or a group	An undo for what already happened

Anthropic's engineering post on Claude Code sandboxing argues that filesystem and network isolation are both required, since each boundary covers the other's gap (Anthropic engineering). More detail is in the runtime security guide and in controls at the action layer.

Layer 6, what it remembers and exposes

Control	Buys you	Does not buy you
Memory separated by user and task	Less cross-contamination	Reliable spotting of subtle poisoning
Provenance tags on retrieved content	A trail back to a bad source	Truth of the content
Putting less data in context	Less to leak	An end to needing the data

Layer 7, what you loaded and what you can prove

Control	Buys you	Does not buy you
A registry proxy with an approved list	Unknown package names refused	Vetting of the approved packages
Checks at install time	Assurance that the installed tree matches the pin	A read on intent
An allowlist of extensions and plugins	A limit on what runs beside the agent	Protection from a trusted publisher's compromise
An inventory with owners	The basis for everything else	Security by itself
Logs kept outside the agent's reach	Evidence; one September 2026 preprint found agents can erase their own traces	Stopping an incident
Recurring adversarial tests	Discovery of controls that fail	Proof that no flaw exists

The preprint is arXiv:2609.30266, a single study to confirm against your tooling.

How NIST sees the gaps

A Cloud Security Alliance research note of April 2026 argues that older NIST frameworks pre-date production agents and leave systematic gaps in four SP 800-53 families, namely access control, identification and authentication, audit and accountability, and supply chain risk management (Cloud Security Alliance). In this catalog those gaps sit mostly in layers 1, 5 and 7. The note adds that NIST's COSAiS project is developing overlays; we found no final guidance. The NIST status article tracks it.

Prefer controls that refuse by default

Look down the "does not buy you" columns and a pattern appears. The controls that fail worst are the ones that allow by default and try to spot the bad case: filters, classifiers, reviewing models. The ones that hold are the ones that deny by default and name what is permitted: tool lists, outbound allowlists, narrow scopes, approved registries.

The NCSC makes the case in its own terms. It warns against deny-listing known bad phrases because there are endless ways to rephrase an attack, and it says design protections should be deterministic safeguards that constrain the system's actions (NCSC blog). Combine that with the adaptive-attack results above and the catalog's lesson is simple: when you have to pick one more control, pick the one that fails closed.

The lesson has a boundary. Allowlists need a task you can describe in advance. A general research assistant that must read anything and call anything cannot be boxed this way, and there a layered mix of detection, approval and logging is the best available, with a candid view of its limits. That is also a signal to ask whether the agent should hold powerful tools at all.

Using the catalog

1. Take one agent and label each control present, partial or absent.
2. Find the empty layers before anything else, since a bare layer is worse than a layer with a single weak control.
3. Fill the cheapest gap in the layer that protects your most consequential tool.
4. Do the same for each agent, and store the sheet next to the risk register.

Different agents need different starting layers. A coding agent on laptops should start at layers 7, 5 and 1, because plugin, sandbox and token-theft reports concentrate there; the coding agent guide expands on it. An agent that talks to customers ingests untrusted text constantly, which points to layers 2, 4 and 7. An internal operations agent with write access should start at layers 1, 5 and 6.

Unknowns

• Nobody has published an agreed agent control catalog; this one is editorial.
• Public evidence for many controls is argument, not measurement.
• NIST overlays remain in development.

Controls, answered briefly