Three Layers Every AI Agent Stack Needs

Catching a malicious prompt is not the same as governing an autonomous agent. The distinction matters enormously as organisations move agentic AI from proof of concept into production — and most current security architectures are still treating the two problems as one.

A guardrail designed to filter model output does nothing to stop an agent from hallucinating and misusing a legitimate credential it was legitimately granted. It does nothing to prevent lateral movement between agents at the network layer, or to flag a runaway agent burning tokens in an infinite loop at the infrastructure layer. Collapsing those risks into a single control surface doesn't simplify the architecture — it creates blind spots.

Why one-size-fits-all fails the agentic model

Traditional application security was designed around a request-response model: a user does something, the system responds, and controls sit at the boundary. Autonomous agents break that model entirely. They reason across steps, call APIs, spin up sub-agents, and execute operations across data stores and enterprise systems — often in parallel, often without a human in the loop for any individual action.

Trying to secure that behaviour with static rules or legacy perimeter controls produces one of two outcomes: the controls block the agent from doing its job, or they leave meaningful exposure wherever the rules don't reach. The architecture needs to assign distinct responsibilities to distinct layers, because each category of risk requires a different kind of containment.

Analysis from Nutanix lays out a three-layer framework — infrastructure, network, and control plane — that maps security responsibilities to where the risks actually live, rather than stacking the same controls repeatedly across the stack.

The three layers and what each one owns

Infrastructure: trust in the environment

Before any governance question can be answered — what is this agent permitted to do, who is it talking to, what data can it access — the environment itself has to be trustworthy. That means rooting identity in hardware rather than software assertions: platform attestation, confidential computing, and secure boot establish that the agent running in the environment is the legitimate agent, not something impersonating it.

For organisations running regulated workloads, this layer also enables isolation of AI production environments so that neither the agent nor its runtime can operate outside its assigned scope. It addresses risks that model-level controls simply cannot reach: supply chain compromise, runtime tampering, and unauthorised access to the underlying AI workload itself.

Network: governing how agents communicate

Once agents begin calling APIs, querying data sources, and spawning additional agents, the communication surface expands in ways that static network rules were never designed to handle. The east-west traffic between agents is dynamic, concurrent, and difficult to reason about — which is exactly what makes it an attractive vector for lateral movement and data exfiltration.

The appropriate response is to treat AI agents as a distinct class of network identity, where access is blocked by default and communication is governed by dynamic policy rather than static rules. Zero trust segmentation and micro-segmentation applied at this layer constrain what an agent can reach, independent of what the model layer has permitted. A hallucinating agent with broad network access is a significantly different risk profile from one confined to the resources it actually needs.

Control plane: what agents are permitted to do

The control plane is where governance becomes operational rather than theoretical. It is the central point for managing agent identities, tool permissions, resource consumption, and runtime visibility — enforced consistently across every agent deployment rather than reinvented for each one.

This layer is the one most enterprises currently underestimate. Organisations often secure model output and apply network controls, but lack the centralised observability to know that agents are stuck in runtime loops, consuming excessive tokens, or accessing data sources beyond their intended scope. A genuine control plane extends across the full agent lifecycle: not just initial deployment, but continuous monitoring, token governance, and the ability to revoke or constrain permissions at runtime.

Governance that lives only in deployment config isn't governance — it's documentation.

What this means for organisations deploying autonomous agents

The practical implication is that governed autonomy requires architecture, not just policy. Deciding what an agent is allowed to do is the easy part; building the stack that enforces those decisions at the infrastructure, network, and control plane layers is where most deployments fall short.

The control plane, in particular, needs to be treated as a runtime control system rather than a compliance exercise. That means managing agent identities and tool permissions in real time, maintaining continuous observability across all agent activity, and enforcing token budgets that prevent runaway consumption. As agent deployments scale from a handful of use cases to hundreds or thousands of autonomous actors, the organisations that invested early in a centralised governance layer will have the operational foundation to expand safely. Those that didn't will be retrofitting controls into architectures that were never designed to hold them.

The three-layer model — infrastructure trust, network isolation, control plane governance — is not a vendor framework. It is the minimum structural requirement for any agentic deployment that intends to operate reliably, safely, and at scale.

Further Reading: venturebeat.com