You Don't Need a New Framework for Agentic AI. You Need Zero Trust.

Intro

I'm sure it's no surprise to readers, but lately, I've been having many discussions about how to properly secure Agentic AI within the enterprise. I'll give my thesis directly: you already have the correct framework needed to secure Agentic AI, and that's Zero Trust.

AI Agents are breaking all of our traditional security controls:

• Autonomy

• Dynamic tool use

• Non-deterministic behaviors

• The scale of API calls a single agent can generate

• The fact that agents act on behalf of users but aren't users

Zero Trust treats every agent action as an untrusted request, requiring fresh verification of identity, context, and authorization. By starting here and building up, we can regain our access control. As the first post in my series, we'll focus on how to begin thinking about these systems and the controls. Then we'll talk about how to get started.

Zero Trust Architecture

The term "Zero Trust" was coined in 2010 by John Kindervag, a Forrester analyst. Simply put, "Zero Trust" is a security approach that assumes no user, device, or system is trusted by default. Instead, we apply continuous verification for every access request.

The flow below shows what this looks like for a single agent action.

In the 16 years since the term was coined, we've seen Zero Trust evolve from a conceptual framework into a widely adopted architectural principle across enterprises. Early on, we focused on network segmentation and identity verification. It didn't take long to realize that achieving true Zero Trust required continuous validation across users, devices, workloads, and data.

Observability & Monitoring

Traditionally, we would see monitoring and observing come at the end of an initiative's implementation. As we strive to achieve Zero Trust and secure AI systems, we have to flip the order of operations around. By starting out with monitoring and observability, we can take true inventory of our environments and identify genuine risk areas.

I argue that this is the correct way to structure all security initiatives. Our risk surfaces are too broad and attacks happen too fast. We must have good data to know where to focus the limited resources and cycles we have to apply defenses.

The Game Plan

How do we actually accomplish this?

The diagram below shows how the seven components relate.

The Components:

1. Centralized identity & registration

   1. Every agent is given a first-class, non-human identity

   2. This identity is issued, rotated, and revocable through the same system that governs your service accounts and workloads

   3. No shared keys, no inheriting a human's session indefinitely

   4. Registration means the agent is known before it runs (who built it, what it's allowed to do, what it runs on behalf of)

   5. We must be able to answer "What is this agent and who owns it?" in a single query

2. Mandatory middleware layer (orchestration or gateway)

   1. Agents no longer talk directly to tools, APIs, or data sources

   2. Every call is routed through a gateway that authenticates the agent, checks authorization in context, and produces a log

   3. This is the chokepoint that makes it all possible

   4. Without middleware, controls and telemetry are a best-effort

   5. Think of this layer as the agentic equivalent of an API gateway or service mesh; not optional & not a per-team decision

3. Unify telemetry and logging

   1. Every prompt, tool call, response, and decision flows into a single place with unified schema

   2. Agent activity is noisy and high-volume by nature, fragmented logs across vendors will defeat you

   3. Unification is what turns "we have logs somewhere" into "we can answer questions about agents within minutes"

4. Asset inventory and discovery

   1. You need a live inventory of agents, the models they use, the tools they can invoke, the data they touch, and the identities they assume

   2. Static inventories will not survive the real world

   3. Agents are spun up fast, and often outside the centralized purview of IT

   4. Discovery must be continuous, ideally driven by signals from the gateway and identity layer rather than self-reporting

5. Network and execution controls

   1. Constrain where agents can run and what they can reach

   2. Egress controls, sandboxed execution environments, per-agent network policies. These are the same primitives we apply to workloads, but tuned for the fact that an agent's "intent" may change between calls

   3. Default-deny on outbound destinations is a reasonable starting posture

6. Policy enforcement

   1. The rules that govern agent behavior

   2. What actions require human approval, what's outright forbidden, etc. These things need to be explicitly defined as code and enforced at runtime, not buried in a wiki.

   3. The gateway is where most of this lives

   4. Policies should be authored centrally, versioned, and testable

7. Governance

   1. The human layer

   2. Who approves new agents, who reviews incidents, how risk is assessed before an agent goes to production, how decisions are documented

   3. Governance is what keeps the other 6 steps from drifting

   4. This is also what auditors and regulators will ask about first, it's cheaper to build in than retrofit