Latest News and Views on Zero Trust from Zentera

The Identity Gap at the Heart of Agentic AI Security

Written by Mike Zelle | Jun 24, 2026 3:55:32 PM

The Identity Gap at the Heart of Agentic AI Security

Zero Trust has a founding principle that most practitioners can recite from memory: never trust, always verify. Words that seem obvious until you ask the question that agentic AI forces into the open.

Verify who, exactly?

Zero Trust's entire architecture is built on identity. Every access decision flows from it. IAM, MFA, PKI, device posture - these are all answers to a single upstream question: can we establish who is making this request? When the answer is yes and verifiable, the rest of the framework follows. When the answer is no, everything downstream - the policy engine, the least-privilege model, the audit trail - is operating on a foundation that doesn't exist.

AI agents, as most organizations are deploying them today, are operating without an answer to that question. They do not have identities in any meaningful sense. They have inherited permissions and borrowed credentials. That is not the same thing. Zentera recently launched its EnsageTM AI agentic visibility and control capabilities, as that distinction is where a significant portion of enterprise AI risk currently lives.

How We Got Here

The identity problem in enterprise security has been largely solved for the entities that came before agents. For humans, we have directory services, SSO, MFA, role-based provisioning, and lifecycle management. For devices, we have certificate-based enrollment, endpoint detection, and posture assessment. For applications, we have service accounts and API keys with defined scopes. These are mature, well-understood systems. They are imperfect, but the mechanisms exist and most organizations have invested heavily in them.

When AI agents entered the enterprise, they slipped in under the radar of those existing systems - not because anyone deliberately designed it that way, but because there was no identity framework ready to receive them. The fastest path to deployment was to run the agent under an existing service account, or in a container that inherited the permissions of its host environment, or as an extension of a human user's authenticated session.

It worked. The agent could do what it needed to do. And nobody stopped to ask what it meant for security when that agent was the one taking action in a production system.

The Inherited Identity Problem

Here is what "inherited identity" looks like in practice.

A developer spins up an AI agent to automate a CI/CD workflow, running it under their own service account. Because proper scoping takes time, the agent inherits broad access to push code, view docs, and query production databases. The agent needs most of that access to do its job. It is granted all of it, not because anyone evaluated the agent's specific requirements, but because scoping it properly would take time nobody has.

Three months later, the developer moves to a new team, but the agent keeps running with unrotated keys and unreviewed access. The API keys in use quickly become long-lived with no further oversight and no key rotation and so on. The overall access scope will likely never be reviewed - and one can only hope that a key wasn't left in a compromising location.

When an audit asks what the agent accessed in the last 90 days, the logs show only generic activity under the developer's service account. Because the system can't distinguish between the human and the agent, the audit trail is useless.

Looking forward, an enterprise with dozens of teams running AI agents - each one inheriting permissions from its deployment context, none with a distinct cryptographic identity, all of them generating activity under service accounts or human credentials - This isn't theoretical; it is the default state of most AI agent deployments today. Scale this across dozens of enterprise teams - all running agents that inherit credentials without any distinct cryptographic identities - and the foundational question of Zero Trust ("Who did this?") becomes impossible to answer.

Why This Is a Structural Problem, Not a Configuration Problem

We instinctively treat this as a governance gap to be fixed with checklists or least-privilege reviews. But the deeper flaw is structural: human identity systems depend on a permanent, lifecycle-tracked "durable principal." The AI agent model shatters this design entirely:

  • Agents are ephemeral: Multi-step workflows spawn dozens of short-lived agents that perform a single task and terminate, leaving no persistent entity to attach a traditional identity.
  • Agents spawn other agents: Orchestrators delegate sub-tasks to specialized sub-agents. Each hop down the chain inherits the master identity, compounding the attribution problem.
  • Agents don't authenticate: Unlike humans who log in per session, an agent may receive credentials through config files or environment variables at deployment and run indefinitely without session expiries or step-up challenges.
  • Agents behave erratically without knowing it: A compromised or hallucinating agent continues using its valid identity. Without per-agent tracking, distinguishing  critical anomalies mixed in with normal baseline behavior is impossible.

The Audit Trail Legal Rulings Are Starting to Require

In early 2024, a Canadian tribunal rejected Air Canada’s defense that its customer-facing chatbot was a "separate legal entity" responsible for its own misinformation. The ruling was clear: an agent’s actions are the company’s actions, full stop.

The heavy implication for enterprises is that they must now answer two legally binding questions: What was the agent authorized to do? and What did it actually do?

Traditional enterprise logging can answer neither. It was never designed for autonomous systems operating on behalf of an organization under shared service accounts. Meanwhile, global regulators are demanding the exact same accountability; the EU AI Act’s focus on transparency, auditability, and human oversight assumes you can trace every automated decision back to an authorized system boundary. Right now, because verifiable agent identity doesn't exist in the enterprise, that required audit trail is completely missing.

What Real Agent Identity Requires

Solving this gap requires moving past traditional IAM and designing for four mandatory characteristics:

  • Per-agent, not per-deployment context: Every agent and sub-agent must carry a distinct identity issued at instantiation that is unique to the host yet can still be traced back to a human owner.
  • Session-aware: Because agents are ephemeral, each individual execution session requires a unique, auditable identifier to keep logs clearly distinguished.
  • Behavior-bound: Identity alone is insufficient. Because agents use dynamic LLM planners to meet goals, they can find unintended execution paths to abuse valid permissions. Identity must be tied directly to a restricted behavioral fingerprint.
  • Enforceable at the network layer: Controls relying on the agent's internal cooperation fail if the agent is compromised. This is the lesson the OpenClaw made concrete earlier in 2026: any identity control that depends on the agent's cooperation fails the moment the agent is compromised. To prevent circumvention, the identity verification layer must sit entirely out-of-band, outside the agent’s own process infrastructure.

From the Perimeter to the Agent

This article outlines a familiar theme: the perimeter model created policy drift because it abstracted identity away from the access control decision - IP addresses and VLANs are not identities. Zero Trust restored identity to the center of the security model, but it was designed for humans and devices. Agentic AI is arriving into an identity gap that  both traditional IAM and Zero Trust frameworks of the last decade simply were not built to address.

Closing that gap doesn't mean abandoning Zero Trust - in fact, it requires Zero Trust. And this requires extending Zero Trust’s first principle - verify explicitly - to cover every entity that takes action in the enterprise, including the ones that aren't human. That means every agent needs a cryptographic identity, every action needs to be attributable to a specific agent, and every policy needs to attach to that identity rather than to the inherited permissions of a deployment context.

This is building Declared Intent - An intent boundary is an explicitly declared, locked-down operating envelope for a specific task or session. Enforced completely out-of-band, this envelope is strictly narrower than the principal's standing permissions. Crucially, this isn't something the system guesses or derives at runtime based on inferred behavior; the envelope is explicitly stated by a human or a static configuration at the moment the agent is registered.

In contrast, the unfortunate alternative - agents acting without distinct identities, their actions indistinguishable in logs, their blast radius bounded only by the scope of a service account nobody manages closely - is already the default state of most enterprise AI deployments. It won't stay invisible forever. The question is whether the identity framework is in place before the incident that forces the issue, or after.

Where Zentera Fits

Zentera's Ensage AI was built from the ground up on the premise that every agent needs a verifiable identity before any other governance question can be answered. The CoIP Platform's cryptographic identity model - the same architecture that has enforced process-level identity for conventional workloads - extends natively to AI agents, assigning each agent a distinct identity at instantiation, binding that identity to a defined access scope, and making every agent-generated action auditable against a specific principal rather than a shared credential. This focus on the agent identity is only the start of the Agentic AI visibility and control solution or an environment-wide solution needs to cover.

For organizations heading into a product evaluation or early deployment of agentic AI infrastructure, the identity question is the right starting point - not because it is the most complex problem, but because every other control depends on the answer.

The Question You Have to Ask First

Zero Trust begins with identity. It has always begun with identity. The reason perimeter security failed is precisely that it deferred the identity question and tried to compensate with network-layer controls that could not hold.

The agentic AI era presents a clear choice. We can deploy agents under inherited credentials, blur the audit logs, and wait for something to go wrong. Or, we can demand what Zero Trust has always required: that every entity is cryptographically verified, audit-logged, and enforced by infrastructure it doesn't control.

For humans and devices, we spent a decade building the systems to answer that question well. For AI agents, the work starts now. And unlike the perimeter era, we don't have to wait for the breach to know what the right answer looks like.