AI Agent Guardrails Answer What, Not Where

Most AI agent guardrails are built to answer one of two questions. Who is this agent, and what is it doing right now? Identity vendors own the first. Governance vendors, most recently Akamai, are staking out the second. Both are real progress, and both leave a third question sitting in the open: where does the action land?

That third question is the only one of the three that can be enforced before an action completes, but is also the one most deployments never ask.

The Two Questions the Industry Settled On

Identity came first, for good reason. An agent running on a shared service account cannot be audited, so the first wave of agent security gave every agent its own identity, scoped its permissions, and shortened its credentials. That is the who question. It gets answered once, at the door.

In September, Akamai pushed past it. Its report, Speed, Scale, and Nonhuman Identity: The Agentic Threat Landscape, argues that identity-based security was built for humans and that agents need behavioral governance instead. Akamai's definition is precise: "Rather than controlling who accesses systems, it focuses on monitoring and controlling what autonomous AI agents do once granted access."

That is the what question. It gets answered continuously, as the agent works.

What Behavioral Governance Gets Right

The premise holds, and the data behind it is hard to argue with. Akamai found that more than 40% of enterprise users have installed AI browser extensions, that 25% altered permissions within 12 months, and that AI extensions are 60% more likely to carry known CVEs. Another 47% of interactions ran through unmonitored personal accounts.

An identity checked at login cannot describe an agent whose behavior changes mid-task. Permissions granted at the door say nothing about the twentieth tool call. Watching behavior is the right instinct, and any serious agent program should do it.

AI Agent Guardrails Are Not LLM Guardrails

The word guardrails carries two meanings, and the difference matters here. LLM guardrails filter text: they screen prompts, block injections, and redact sensitive data from responses. AI agent guardrails govern something harder. They cover actions, tool calls, and the movement of data across external systems.

Agent guardrails usually stack in four layers: prompt-level limits on scope and behavior, filters that intercept execution paths, tool authorization through allowlists and least-privilege scopes, and human approval before high-impact actions. Every one of those layers lives inside the agent's loop or beside it. An agent that is compromised, or that reasons its way around an instruction, carries its guardrails with it. The network path sits outside the agent entirely, which is what makes it useful as a control.

Monitoring Is a Past-Tense Verb

Monitoring has a structural limit, and it is not a limit of effort. A monitor observes an action, which means the action has already happened by the time it is observed. At human speed, that gap is a workable window. At machine speed it is not.

Palo Alto Networks supplied the evidence this month, in a post arguing that defenders "do not have three years". It describes a Unit 42 case where AI compressed roughly two weeks of intrusion into under 10 hours. It also cites a Hugging Face case where an agent ran 17,600 actions to reach cluster admin. Both cases are about reach rather than entry.

17,600 actions is a great deal of behavior to log. A count doesn't tell you where any single action landed, and it does not stop the next one. Confidence in detection reflects this: in a Cloud Security Alliance study of 445 IT and security professionals, only 16% reported high confidence in detecting agent-specific threats.

Where AI Agent Access Control Runs Out

AI agent access control answers a real question: what is this agent allowed to read, modify, or execute? It is the right foundation, and organizations are struggling to lay it. Research from Cequence Security and Enterprise Management Associates published in August found that 94% of organizations were confident their agents did not hold excessive permissions, while only 33% provisioned agents with least-privilege access. In the same research, 14% allow agents unrestricted connections to external tools and data.

Scope violations follow. The CSA study found that 53% of organizations have had agents exceed their intended permissions, and only 8% said their agents never exceed scope. That puts the share with at least one violation at 92%. Nearly half, 47%, experienced a security incident involving AI agents in the preceding year.

Notice what access control cannot do here. It governs what an agent may reach, but it says nothing about where the agent's traffic terminates once it has reached something. An agent holding a legitimate permission can send data to an illegitimate destination, and no identity check or behavioral baseline sits in the way of the connection itself. Destination is a property of the network path, not of the identity store. The 14% with unrestricted external connections are the third question going unasked, in production.

What Enforcement in the Path Looks Like

Answering where means moving enforcement to the point where connections are made. Three properties matter:

• First, egress is default-deny by destination. Agents reach an approved list of endpoints and nothing else, as opposed to default-allow with a log entry for everything.

• Second, the decision happens before the connection completes. Observing an action and terminating it are different capabilities, and only the second answers the third question.

• Third, the control lives in the path, because many agents have no endpoint to install anything on. Cloud-hosted agents, agents running inside SaaS platforms, and agents calling other agents across cloud boundaries all still cross a network.

That last point is why the path between clouds matters. It is the one place where an agent's destination is visible and stoppable regardless of what the agent is, who it claims to be, or how it was built. This is the layer Aviatrix works at, and it is where the third question gets its answer.

The Three Questions

Set side by side, the three questions divide the work cleanly:

• Who is the agent? Identity answers it, once, at the start.

• What is it doing? Behavioral governance answers it, continuously, as the work happens.

• Where is it going? The network path answers it, before the action completes.

A program that answers only the first two can describe an incident in detail after the fact. A program that answers all three can prevent some of them.

Who Is it, What is it Doing, and Where Can its Traffic Go?

The guardrails conversation is moving fast, and it is moving in the right direction. Identity gave way to behavior in a matter of months. The next step is smaller than it looks. Behavior tells you what an agent is doing. Destination tells you where it is doing it, and that answer is available soonest, at the point of a decision instead of the end of a log.

Ask of every agent in production: who is it, what is it doing, and where can its traffic go? If the third answer is "anywhere," the first two are being asked too late.

Listen to Aviatrix CEO Doug Merritt and Ashish Rajan, host of the AI Security podcast, discuss AI security on the "In Progress" podcast.

Learn more about Aviatrix Validated Containment Architectures, which enforce defaulty-deny policies at the network layer for specific AI platforms.