Three Layers of Agent Security, Mapped to Systems I've Shipped

The first time an agent of mine did something I didn't intend, nobody had attacked it. A scheduled worker hit a malformed tool response, retried, interpreted the retry as a new task, and kept going. No malicious prompt, no jailbreak. Just a perfectly authorized process doing the wrong thing at machine speed. That experience shaped how I read a recent Nutanix-sponsored piece on VentureBeat about a three-layer security model for autonomous agents, and why I think its core argument is right even though the article itself is vendor content.

I'll be upfront about that: the article is "Presented by Nutanix" and it promotes Nutanix, Cisco and Intel products. I'm not going to repeat product-effectiveness claims. What I want to do is take the architecture, test it against agent systems I've run unattended, and show where things actually break. If you want the original, it's here: The three layers of agentic AI security.

The argument worth keeping: prompt filtering is not the whole problem

The article quotes Oscar Wahlberg, senior director of product management at Nutanix, making a point that matches my experience: a guardrail that catches a malicious prompt does nothing about a hallucinating agent that misuses a credential it legitimately holds.

That sentence separates two failure classes that most teams collapse into one:

1. Adversarial input: someone or something is trying to steer the agent (prompt injection, poisoned documents, hostile tool output).
2. Authorized misbehavior: nobody is attacking, the agent simply decides wrongly, loops, or over-reaches with access it was legitimately given.

Input filtering addresses the first class, partially. It does essentially nothing for the second. And in the autonomous systems I run (multi-agent content pipelines, scheduled workers with no human in the loop), the second class is where most of my real incidents came from.

For context on how bad the first class can get: NIST's CAISI, working with the UK AI Security Institute on the AgentDojo benchmark, reported that novel attack strategies raised the task-hijacking success rate from 11% to 81%. Caveat: I'm relying on a Cloud Security Alliance summary of that work rather than the NIST page itself, so read the original research for the exact test conditions before treating 81% as a universal rate. The point is directional: hijacking defenses that look fine against known attacks can collapse against adaptive ones. (CSA research note)

The three layers, briefly

The article's model:

Wahlberg's claim is that enterprises underestimate the control plane the most. After building agent systems on AWS serverless and in self-hosted setups, I agree, and I'd go further: most teams don't have a control plane at all. They have a system prompt and hope.

Quick aside: Google DeepMind published a paper that also says "three layers of agent security," but it means something different (individual agents, ecosystem and policy, defender resilience). Don't conflate the two when you search. (DeepMind PDF)

Layer 1, infrastructure: real, but mostly someone else's job

Hardware attestation and confidential computing matter when you operate the hardware or handle regulated workloads. For the systems I've built, the infrastructure layer was mostly inherited: Lambda execution isolation, managed secrets, IAM boundaries per function.

Where it did bite me was blast radius design. In a serverless architecture, the cheapest infrastructure-level security control is making each agent worker its own execution unit with its own role. In the AWS and Zendesk integration I built (the one that delivered the first-ever SLA compliance), each function got only the permissions for its single job. That wasn't about attackers. It was about making sure a bug in one handler could not touch anything else.

My practical rule for this layer:

• One identity per agent role, never a shared "agent" service account.
• No long-lived credentials inside the agent's reachable context. If the model can read the key, assume the model can leak the key.
• Treat the sandbox as the real security boundary, because the model is not one.

If you're on a managed cloud, you get most of this by configuration discipline rather than exotic hardware. If you're running high-risk agents that execute code, sandboxing is non-negotiable.

Layer 2, network: where prompt injection actually becomes damage

Prompt injection by itself is just text. It becomes an incident when the agent can reach something. That is why the network layer, the article's "agents as a new class of network identity" idea, is more important than it sounds.

Here's the failure pattern I've designed against. An agent with a web-fetch tool pulls a page during research. The page contains instructions aimed at the model. If that agent also holds a tool that can write somewhere (publish, send, update a record), you have a complete attack chain with no exploit code, only language.

The OWASP Top 10 for Agentic Applications 2026 names this directly. ASI01 is Agent Goal Hijack, where an adversary redirects the agent's plan or objective. ASI02 is Tool Misuse, and ASI03 is Identity and Privilege Abuse. Note that OWASP's list is voluntary and extends the OWASP LLM Top 10 rather than replacing it. (Modulos guide to the list)

What I'd do at the network layer:

• Split read and write agents. The component that ingests untrusted content (web, email, tickets) should not hold the credentials or tools that change state. Hand off through a narrow, structured interface, not free text.
• Default-deny egress. An agent that has no reason to call arbitrary domains should not be able to. This single control kills a whole category of exfiltration.
• Validate tool output as untrusted input. Tool responses are an injection channel too. I treat them exactly like user input.

The pattern I favor for a content pipeline is that the research stage reads the open web but outputs only structured fields, and the publishing stage never sees raw fetched text. That separation costs a few hours of design and removes an entire class of worry.

Layer 3, control plane: the layer I'd build first

This is the one I'd prioritize, and it's the one the article says is most underestimated. The article describes a centralized AI gateway meant to mitigate privilege misuse, runaway agents, unauthorized tool usage, data leakage, and excess token consumption when agents get stuck in runtime loops.

That last item is not theoretical for me. Runaway loops are the most common real failure of autonomous agents I've operated, and they are also an authorized-misbehavior problem: no attacker, valid credentials, wrong behavior, growing bill.

A control plane doesn't have to be a vendor product. The shape I use is a thin layer every tool call passes through. Conceptually:

// Every tool call goes through one chokepoint.
async function gatewayCall(agentId: string, tool: string, args: unknown) {
  const policy = await getPolicy(agentId);

  if (!policy.allowedTools.includes(tool)) {
    audit(agentId, tool, args, "DENIED_TOOL");
    throw new PolicyError("tool not permitted");
  }
  if (await budgetExceeded(agentId, policy)) {
    audit(agentId, tool, args, "DENIED_BUDGET");
    throw new PolicyError("token/call budget exhausted");
  }
  if (policy.requiresApproval(tool, args)) {
    return queueForHuman(agentId, tool, args); // enforced here, not by the model
  }

  const result = await execute(tool, args);
  audit(agentId, tool, args, "OK");
  return result;
}

Three properties matter more than the code:

1. Deterministic enforcement. Microsoft's defense-in-depth guidance makes the same point: human-in-the-loop review should be enforced by the orchestrator, not delegated to the model. If "ask a human before deleting" lives in the prompt, it is a suggestion. If it lives in the gateway, it's a rule. (Microsoft Security blog)
2. Budgets as a safety control. Per-agent token and call ceilings turn a runaway loop from an open-ended incident into a bounded, logged one. This is the cheapest control with the highest payoff I know of.
3. Audit of every call. When something goes wrong at 3 a.m. in an unattended system, the audit log is the only witness you have.

Commercial gateways are emerging here. Nutanix has announced an Agent Gateway aimed at governing AI agents, with MCP server access governance, per-request audit logs and token-based rate limiting. I haven't deployed it, so I won't judge its quality; I'll just note that the feature list lines up with the exact controls above. If you're in that ecosystem, evaluate it and check Nutanix's official materials for current availability and details. If not, the pattern is small enough to build. (IT Brief)

Where the model has gaps

Being fair to a sponsored article means noting what it leaves out. The strength of its argument rests on reasoning rather than on measured evidence of how often injection or tool abuse breaks production systems. Also, the model is infrastructure-heavy. If you're a team building on managed APIs, the application layer is where you have the most control, which is Microsoft's point as well: for builders, the application layer is decisive.

My own amendment to the three layers would be a cross-cutting fourth concern: observability and evals. You cannot govern what you cannot see, so instrument your agents before you try to govern them.

What I'd do

If you're shipping an autonomous agent this quarter, in this order:

1. Put a gateway in front of every tool call. Allow-list, budgets, audit. Build it before you add the fifth tool, not after.
2. Separate agents that read untrusted content from agents that can change state. Pass structured data between them.
3. Give each agent its own scoped identity. No shared service accounts, no secrets in model-reachable context.
4. Enforce approvals in code. Anything irreversible goes through deterministic human review.
5. Cap spend and iterations per run. Assume loops will happen and make them cheap.
6. Red-team against adaptive attacks, not a static list. The CAISI result is a reminder that passing known tests proves little.

Do the control plane first. Hardware attestation is wonderful, but a runaway agent with valid credentials will hurt you long before a firmware attack does.

If you're designing agent security for a real deployment and want a second pair of eyes on the architecture, you can reach me at lazar-milicevic.com/#contact, or keep reading the other agent-engineering posts on the blog.