Three Layers of Agentic AI Security, Explained

By Lazar Milicevic · Published October 27, 2026 · 12 min read

Your agent has a real credential, a shell, and a handful of tools. The model-level guardrail you bolted on catches a malicious prompt, but it does nothing when the agent hallucinates its way into a legitimate API call it shouldn't make. This post breaks agent security into three layers that fail independently, shows what each one stops, and gives you configs and checklists you can apply this week.

Why prompt guardrails alone leave the biggest gap

Prompt-level filtering addresses one failure mode: hostile input. Autonomous agents also fail through hallucination, runaway loops, over-broad credentials, and tool misuse, and a guardrail that inspects text does nothing about any of those. Oscar Wahlberg, senior director of product management at Nutanix, argues that model-only security leaves the largest gaps, because a guardrail that catches a malicious prompt does nothing to stop a hallucinating agent from misusing a legitimate credential (VentureBeat, sponsored by Nutanix).

Two caveats on that source. It is a sponsored piece ("Presented by Nutanix"), and the vendor product details in it are marketing, so I'm not going to evaluate or recommend any of them here. The framework itself, though, is a useful way to organize the problem, and it matches what I see when agents break in practice.

The framework's three layers:

The point of separating them is that each layer addresses a distinct category of risk instead of duplicating the same controls up the stack. If your whole security story is "we have a system prompt that says don't do bad things," you have zero layers, not one.

For a solopreneur or a 5-person team, you will not run hardware attestation. But you still have all three layers in some form: where the agent runs, what it can reach, and what permissions and budgets it holds. The rest of this post translates each layer to that scale.

Layer 1: Infrastructure, establishing who is operating

The infrastructure layer's job is to establish a root of trust that answers who is operating in the environment. At enterprise scale that means hardware-rooted technologies such as platform attestation, confidential computing, and secure boot (VentureBeat).

You probably can't buy that, but the principle transfers: the agent should run somewhere with a known, minimal, reproducible footprint, and you should be able to say what is running and under which identity.

Practical equivalents for a small team:

• Run agents in an isolated environment, not on your daily-driver machine. A throwaway container, a dedicated VM, or a dev container beats your laptop with your browser sessions and SSH keys sitting right there.
• Give each agent its own identity. Don't run the agent under your personal account or paste your admin API key into its environment. A separate service account per agent makes the audit trail readable and the blast radius small.
• Treat OS-level sandboxing as part of this layer. Anthropic documents that Claude Code's permissions control which tools the agent can use, while sandboxing gives OS-level enforcement for shell commands. Anthropic recommends using both for defense-in-depth, because sandbox restrictions still apply even if a prompt injection bypasses the model's decision-making (Claude Code permissions docs).

That last point is the core idea of the whole post in miniature. Permissions are a decision the model participates in. A sandbox is enforcement the model can't talk its way out of. You want both.

A note on how much sandboxing helps in practice: Anthropic reports that its OS-level sandbox (Seatbelt on macOS, bubblewrap on Linux) cut permission prompts by 84%, with network access denied by default (How we contain Claude across products). Fewer prompts matters for security, not just convenience, because people who get prompted constantly start clicking "allow" without reading.

Check the current Claude Code docs before relying on any sandbox default. They change often, and whether the sandbox is active out of the box depends on your version and setup. Verify it's actually on in your environment rather than assuming.

Layer 2: Network, treat every agent as a new class of identity

The network layer answers what the agent can reach. Wahlberg's framing is that AI agents should be treated as a new class of network identity that can talk only to agents or data sources where it is explicitly allowed, with dynamic policy enforcement instead of rigid static rules (VentureBeat).

The default posture that matters most is deny-by-default egress. An agent that can reach any host can exfiltrate to any host. Claude Code's sandbox models this well: it has no direct network route out by default, connections go through a proxy that checks each host against an allowed-domains list, and that list starts empty (sandboxing docs).

One detail worth knowing: the built-in file tools (Read, Edit, Write) and WebFetch run outside the sandbox and follow permission rules instead (sandboxing docs). So the sandbox's network allowlist does not cover everything the agent can do. You need permission rules for those tools too. This is exactly the kind of gap that appears when you assume one control covers a whole layer.

A minimal Claude Code settings sketch showing the idea (field names change between versions, so confirm against the current docs before copying):

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(./src/**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(~/.ssh/**)",
      "WebFetch"
    ]
  }
}

The shape is what matters: an explicit allowlist for what the agent needs, an explicit deny for secrets and for network tools you haven't decided to trust yet.

For agents you run yourself outside Claude Code, the same posture applies at the container level. A Docker Compose sketch that cuts off direct egress and forces traffic through a proxy you control:

services:
  agent:
    image: my-agent:latest
    networks: [internal]
    environment:
      HTTPS_PROXY: egress-proxy
    read_only: true
    cap_drop: [ALL]

  egress-proxy:
    image: my-allowlist-proxy:latest   # your proxy, with an explicit domain allowlist
    networks: [internal, external]

networks:
  internal:
    internal: true     # no direct route to the internet
  external: {}

The internal: true network means the agent has no route out except via the proxy, and the proxy only forwards to domains you listed. Start the list empty and add hosts as you hit a real need, the same way the Claude Code sandbox does.

Layer 3: The control plane, where most small teams have nothing

The control plane is the central point for managing agent permissions, tool access, resource consumption, and runtime visibility. It targets risks such as privilege misuse, runaway agents, unauthorized tool usage, data leakage, and excess token consumption from runtime loops (VentureBeat). Wahlberg says enterprises underestimate this layer the most. That's one executive's opinion in a sponsored article, and no survey backs it, but it matches my experience that the control plane is the layer small teams skip entirely.

The article recommends a centralized governance layer that manages agent identities, tool permissions, and token budgets in real time. For a small team, that means four concrete things:

1. A registry of agents. A list of which agents exist, who owns each, and what each is for. A spreadsheet is a legitimate v1.
2. Per-agent tool allowlists. The invoicing agent does not get shell access. The research agent does not get write access to your CRM.
3. Hard budgets. A cap on tokens, tool calls, and wall-clock time per run, enforced outside the model.
4. Logging you'll actually read. Every tool call with its arguments, the agent identity, and the outcome.

Here's a runtime budget wrapper in Python. It's deliberately simple, and the point is that the limits live in your code, not in the prompt:

import time

class BudgetExceeded(Exception):
    pass

class RunBudget:
    def __init__(self, max_tool_calls=50, max_seconds=300, max_tokens=200_000):
        self.max_tool_calls = max_tool_calls
        self.max_seconds = max_seconds
        self.max_tokens = max_tokens
        self.calls = 0
        self.tokens = 0
        self.start = time.monotonic()

    def charge(self, tokens_used: int):
        self.calls += 1
        self.tokens += tokens_used
        if self.calls > self.max_tool_calls:
            raise BudgetExceeded("tool call limit")
        if self.tokens > self.max_tokens:
            raise BudgetExceeded("token limit")
        if time.monotonic() - self.start > self.max_seconds:
            raise BudgetExceeded("time limit")

ALLOWED_TOOLS = {"search_docs", "read_invoice", "draft_email"}

def call_tool(budget: RunBudget, agent_id: str, tool: str, args: dict, tokens: int):
    if tool not in ALLOWED_TOOLS:
        log(agent_id, tool, args, outcome="denied")
        raise PermissionError(f"{agent_id} may not call {tool}")
    budget.charge(tokens)
    result = TOOLS[tool](**args)
    log(agent_id, tool, args, outcome="ok")
    return result

(log and TOOLS are your own logging function and tool registry.) The numbers in RunBudget are placeholders; tune them to what a normal run of that agent costs. A runaway loop that burns tokens until your monthly bill arrives is a control-plane failure, and no amount of prompt hardening prevents it.

Map the layers to OWASP's agentic risk list

The OWASP GenAI Security Project published its Top 10 for Agentic Applications 2026 on December 9, 2025. The list runs ASI01 to ASI10: Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain Vulnerabilities, Unexpected Code Execution (RCE), Memory and Context Poisoning, Insecure Inter-Agent Communication, Cascading Failures, Human-Agent Trust Exploitation, and Rogue Agents (Cycode summary, HYDN summary). I'm citing secondary summaries here, and exact risk-name wording varies slightly between sources, so check the OWASP GenAI Security Project site for the canonical text.

It's voluntary and has no legal status by itself. It extends the OWASP Top 10 for LLM Applications rather than replacing it (Modulos guide).

Here's my own mapping of which layer does the heavy lifting for each risk. It's an engineering judgment, not an official OWASP or Nutanix mapping, and most risks touch more than one layer:

Notice how many land on the control plane. That's consistent with the claim that it's the layer people neglect, even if the "most underestimated" ranking itself is unproven.

Applying this to MCP servers and tools

If you're connecting agents to tools through the Model Context Protocol, the spec itself backs a defense-in-depth stance. It says tools represent arbitrary code execution and must be treated with caution, that tool descriptions and annotations are untrusted unless they come from a trusted server, and that hosts must get explicit user consent before invoking any tool (MCP specification).

On the identity side, the spec's authorization security considerations require MCP clients to include the resource parameter (RFC 8707) in authorization and token requests, require MCP servers to validate that tokens were issued specifically for them, and say authorization servers should issue short-lived access tokens (MCP authorization security considerations). In plain terms: a token minted for one server shouldn't work on another, and tokens should expire fast so a leaked one has a short useful life. I saw the 2026-07-28 version in my research but didn't confirm it's the latest release, so check the spec index before treating any specific MUST or SHOULD as current.

A practical MCP checklist for a small team:

• Install only servers you can read or trust. An MCP server is code your agent will execute against. Treat adding one like adding a dependency, because it is one (ASI04 territory).
• Scope tokens narrowly. One token per server, short-lived, with the minimum scopes the task needs.
• Never auto-approve write or destructive tools. Read-only tools can reasonably be allowlisted; anything that sends, deletes, pays, or publishes should require confirmation.
• Don't trust tool descriptions. A description is text an attacker may control. Review what a tool actually does, not what it says it does.
• Log every call. If you can't reconstruct what an agent did last Tuesday, you can't investigate an incident.

The honest limits of every layer

No single control here is sufficient, and the vendors building them say so. Anthropic reports that Claude Code's auto mode, a model-based classifier, blocks roughly 0.4% of benign commands, while about 17% of overeager actions still get through. They position it as one layer of defense-in-depth inside a sandbox, not a substitute for one (How we contain Claude across products).

That is the strongest argument for layering. If a model-based check lets roughly one in six overeager actions through, you want the sandbox, the network allowlist, the budget cap, and the human approval step standing behind it. Each layer is leaky; the stack is what holds.

Also keep expectations calibrated on standards. In February 2026 NIST's NCCoE released a concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," proposing a demonstration project on agent identity and authorization (summary). NIST also has a broader agent standards effort that began around February 2026, but I couldn't confirm a final standard or published guidelines, so don't describe anything from it as binding. Check nist.gov for current status. Agent identity is an open problem, and anyone selling you a finished answer is ahead of the standards.

A starting order if you're doing this from zero:

1. Move the agent off your personal machine and personal credentials (Layer 1).
2. Set egress to deny-by-default and add hosts as needed (Layer 2).
3. Write a per-agent tool allowlist and a hard run budget (Layer 3).
4. Add human approval for any irreversible action (Layer 3).
5. Turn on logging and read it weekly (Layer 3).

That's a day or two of work for one agent, and it covers more of the OWASP list than any prompt rewrite will.

How I approach hardening an agent

When I harden a Claude or MCP-based agent, I work along the same axes this post describes: identity (a separate credential per agent, narrow scopes), tools (an explicit allowlist, with approval gates on anything irreversible), and runtime (sandboxed execution, restricted egress, hard budgets, and call-level logging). I don't treat the system prompt as a security boundary.

If you already run an agent, a good exercise is to take the five-step list above and check your setup against it, one layer at a time.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.