ShrikeThe AI Agent Security Stack
The AI agent security stack is the set of complementary control layers that together secure an autonomous agent: model and input security, application and tool security, execution sandboxing, identity and access, runtime action governance, detection and response, and compliance. No single layer secures an agent; each answers a different question, and defense in depth requires several.
Agents collapse risks that used to live in separate places (identity, application, data, and execution) into one operating model. The controls that govern them stay separate, and that is a feature: each layer is strong at one question and structurally unable to answer the others. This page maps the layers, the question each answers, and where the gaps sit, so the stack you assemble is a decision, not an accident.
The layers
Read top-down as "proof to prevention," or bottom-up as the path a request travels. These are complementary controls that coexist, not competing products:
A different question at each layer
| Layer | Core question |
|---|---|
| Model & Input Security | Can the model be manipulated? |
| Application & Tool Security | Can the agent's tools and workflows be abused? |
| Execution & Sandbox | Where can the agent operate? |
| Identity & Access | Who is the agent, and what credentials does it hold? |
| Runtime Action Governance | What is this agent allowed to do right now? |
| Detection & Response | What happened, and how do we respond? |
| Governance & Compliance | Can we prove the system operates within our requirements? |
The fifth question is the one most stacks cannot answer today. Model filters evaluate words; sandboxes evaluate boundaries; IAM evaluates credentials. None of them evaluates a specific action, in context, against policy, before it executes. That is the action-governance gap, and it matters because an agent can be unmanipulated, inside its sandbox, using credentials it legitimately holds, and still do the wrong thing.
Prevention, containment, response
- Model security tries to prevent the agent from being manipulated.
- Sandboxing contains the blast radius when the agent behaves incorrectly.
- Identity contains what credentials and resources are reachable at all.
- Runtime action governance prevents a specific action from executing when policy says it shouldn't.
- Detection and response catches what gets through, and drives the investigation after.
A stack that is all prevention has no answer when something novel gets through; a stack that is all detection meets every incident after it happened. The layered argument is not that any one control is best; it is that the modes cover for each other.
Why guardrails aren't enforcement
A guardrail can tell an agent: "Don't delete production data." But if the agent is the entity deciding whether to follow that instruction, the control lives inside the system being constrained, subject to the same reasoning that gets manipulated, and to whatever an attacker injects over it. Runtime enforcement changes the architecture: the agent requests an action, an independent policy layer evaluates it, and the underlying system executes only if policy permits. Instructions influence behavior. Policy at an enforcement point governs it. (The longer version of this argument is in what is action governance?)
Where each control lives
The practical test for any agent control: does it live inside or outside the agent's reasoning, and can it actually prevent an execution?
| Control | Inside the agent's reasoning? | Independent of it? | Can prevent execution? |
|---|---|---|---|
| System prompt instructions | Yes | — | Sometimes: the agent can reason around them |
| Model safety training | Yes | — | Not reliably under adversarial pressure |
| Output filter | — | Yes | Sometimes: sees content, not actions |
| Sandbox | — | Yes | Yes, at its boundary |
| IAM | — | Yes | Yes, at the permission boundary |
| Runtime action policy | — | Yes | Yes: per action, before execution |
| SIEM / SOC | — | Yes | Rarely: primarily detection |
| Compliance framework | — | Yes | No: governance and evidence |
The Agent Security Control Matrix
Objectives down, layers across. A check marks the layer(s) where an objective is primarily enforced. Read the empty cells too: no column covers everything, including the runtime-governance one; that is the point of a stack.
| Security objective | Model | Sandbox | IAM | Runtime Governance | SIEM / SOC |
|---|---|---|---|---|---|
| Filter manipulative or harmful prompts | ✓ | ✓ | |||
| Vet model provenance and training data | ✓ | ||||
| Isolate process execution (kernel, container) | ✓ | ||||
| Bound filesystem and network reach | ✓ | ✓ | |||
| Authenticate the agent's identity | ✓ | ||||
| Enforce least-privilege credentials | ✓ | ✓ | |||
| Screen tool definitions and schemas | ✓ | ||||
| Control which tools an agent may invoke | ✓ | ||||
| Evaluate each action against policy before it executes | ✓ | ||||
| Require human approval mid-workflow | ✓ | ||||
| Screen tool output before the agent reasons over it | ✓ | ||||
| Correlate behavior across a multi-turn session | ✓ | ✓ | |||
| Investigate incidents after the fact | ✓ | ||||
| Produce per-action audit evidence | ✓ | ✓ |
Download the matrix (CSV) → Use it as a coverage worksheet against your own stack.
Layering in practice: sandbox + action governance
A concrete example of two layers composing rather than competing. A kernel-level sandbox (such as NVIDIA's NemoClaw/OpenShell execution environment) answers "where can the agent run?" (process isolation, filesystem bounds, network egress). Action governance sits above it and answers "what may it do?". An agent legitimately inside the sandbox, with legitimate database access, still gets each query evaluated against policy before it runs. Neither control replaces the other; an agent with both is governed at two independent boundaries. (Walkthrough: securing NemoClaw agents.)
Where Shrike fits
Shrike operates at the runtime action governance layer: between an agent's decision to invoke a capability and that capability's execution. The agent decides what it wants to do. Whether it executes is decided by your policy: declared by you, enforced by Shrike at a point the agent's reasoning can't route around, with graduated verdicts (allow, warn, require human approval, block) and a per-action evidence record. Shrike doesn't replace the other layers; it fills the action-governance gap between agent intent and execution.
Go deeper
- What is action governance? The canonical definition of the layer this page places.
- The 17 agentic attack techniques: the published threat taxonomy mapped to inline controls, gaps printed.
- What is MCP security? Tool poisoning, rug pulls, and shadowing in the application/tool layer.
- Agent scope declaration, the authorization surface: declare what an agent is for, and enforce it.
- OWASP Agentic Top 10 mapping: the risk catalog, mapped to enforcement.
- Why agents need independent governance: the self-certification problem in depth.