Latest News and Views on Zero Trust from Zentera

AI Agent Security: Why Closing Exposures Isn't Enough

Written by Tom Horyn | Jun 23, 2026 11:50:15 PM

An AI agent that reads from a cloud storage bucket, executes tasks through serverless functions, and authenticates through existing IAM roles inherits every security exposure those systems carried before the agent existed. The agent did not introduce those exposures. It makes them newly valuable to an attacker.

The attack path that leads to an AI agent does not start at the agent. It starts at whatever entry point an attacker can reach first: an unpatched server on the perimeter, a misconfigured delegation in Active Directory, a developer's stored cloud credentials. None of these exposures is exotic. In combination, they can give an attacker control over what an AI agent reads, what it trusts, and what it returns to users, without directly touching the AI stack.

The security industry is responding to this threat model with exposure management: map the full attack path, find the choke points, remediate before an attacker chains the exposures. That response has genuine merit. But it rests on an assumption worth examining.

Why Attack Paths Persist Despite Genuine Remediation Effort

The teams managing these environments are not ignoring known exposures. They are working through backlogs that grow faster than they can be resolved, against operational constraints that make even straightforward remediation genuinely difficult.

A critical CVE appears in the vulnerability scanner. The server is flagged, a ticket opens, and the fix is scheduled. The server also runs a production application with a maintenance window that opens once a quarter. The patch is scheduled for the next window. That window slips twice. Six weeks later, the vulnerability remains open and an attacker uses it. This is not a dysfunction; it is a realistic picture of how production environments work.

Active Directory carries the same problem at a deeper layer. Any AD deployment running for five or more years accumulates delegation settings, service account permissions, and group configurations that no single person fully understands. This is not a failure of hygiene; it is the natural result of configuration decisions made over time, by people who may no longer be at the organization. An AD hardening program can identify Resource-Based Constrained Delegation misconfigurations. Resolving them requires tracing the operational dependencies those delegations were created to serve, and those dependencies are rarely documented.

Developer credentials follow a different pattern. Engineers store API keys and service account credentials in ways that make their local toolchains work. A credential audit surfaces them. Removing them means rearchitecting the development workflows that depend on them, and that work competes with every other item in the engineering backlog.

The assume-breach principle exists for this reason. Security programs that depend on perfect exposure closure before they can protect something downstream are fragile by design. The relevant question is not whether the attack path will be found and fixed in time. The relevant question is what the architecture does when it is not.

Why AI Agents Change the Economics of Infrastructure Attacks

Before AI agents, the attacker's reward was bounded by the developer's access surface. A compromised developer's credentials gave access to what that developer could directly reach: a set of cloud resources, the tools on their machine, the storage buckets assigned to their role.

After AI agents, the calculation changes.

AI agents are provisioned to do work that previously required multiple people and tools working in sequence. To complete those tasks, they aggregate access across systems that were previously separate: internal databases, external APIs, cloud storage, business process tools, and LLM providers, all connected through a single agent's session. Where a developer might hold read access to a specific storage bucket, an agent assisting that developer may hold access to every resource it needs to execute an automated workflow, including assets the developer would never touch directly.

Agents also automate actions that humans previously performed one step at a time. An attacker who previously needed to query systems interactively can direct a compromised agent to execute multi-step operations at machine speed, across multiple resources, without a human reviewer at each step.

The consequence is direct: the reward at the end of a legacy infrastructure attack path is higher when AI agents sit at the destination. The attacker who pivots from a perimeter server to a developer's workstation and finds only stored CLI credentials reaches one set of resources. The attacker who reaches an agent operating across an enterprise's knowledge bases, business APIs, and data stores reaches many things simultaneously, and can act on all of them.

Exposure management identifies that the attack path exists. It does not change what sits at the end of it.

Two Containment Layers

Securing AI agent environments against infrastructure-based attack paths requires two distinct containment layers: one that limits what legacy infrastructure can reach, and one that defines precisely what AI agents can reach regardless of how their environment was entered.

Containing legacy infrastructure. The CoIP Platform applies network segmentation to legacy systems without requiring those systems to be modified or rearchitected. A server isolated by the CoIP overlay cannot reach internal directory services or developer workstations regardless of whether its vulnerabilities have been patched. This removes the pivot point without requiring the underlying exposure to be closed first.

Project-aware enclave isolation for AI agents. This is the load-bearing layer.

Most enterprises already organize sensitive work around projects, and they do it for good reasons. Semiconductor companies structure their environments around tapeouts: the design IP for one customer's chip cannot be reachable by agents working on a different customer's design. Pharmaceutical companies separate research programs: an agent operating on data from one clinical program should have no network path to another program's assets, regardless of whatever infrastructure they share. Financial institutions enforce workflow segregation: an agent processing retail customer data and an agent handling institutional trade flows need to operate as though they are in separate buildings, because the segregation-of-duties expectations that apply to the humans in those roles apply equally to the agents acting on their behalf.

Ensage maps AI agent isolation directly to those project boundaries. Each agent project operates within an enclave: a Zero Trust perimeter that defines exactly which tools, APIs, databases, and cloud resources that agent is authorized to reach. Reachability is the enforcement mechanism. An agent inside one enclave cannot reach assets assigned to another because those assets are not on any network path the agent can access. This is a different class of control from a policy that prohibits access: the asset is not reachable, not merely forbidden. Within an enclave, critical assets can be wrapped in an additional isolation layer that adds containment depth even against a compromised agent operating inside the same boundary.

The credential boundary. Enterprise credentials for AI providers and backend services terminate at the AI Session Controller rather than at the agent itself. A compromised agent cannot exfiltrate keys it never held, and cannot use its own credential store as a path to additional cloud resources.

Governance Across the Lifecycle

Defense in depth is only durable when it operates across the full lifecycle of an agent deployment. An enclave that contains an agent at launch needs to be maintained as the agent updates, as team membership changes, and as the project ends. An agent enclave left open after a project completes is an orphaned attack surface, and in environments with aggressive AI adoption, those surfaces accumulate quickly.

Ensage's Discover, Authorize, Contain, Observe, Maintain lifecycle addresses this operationally. Decommissioning is a network-layer action: the agent loses reachability before it is removed from inventory. Authorization and decommissioning are not policy changes in a dashboard; they are changes to what the network forwards.

The Security Posture That Follows

AI agents do not create most of the attack paths that lead to enterprise data. They increase the value of what those attack paths can reach.

Exposure management helps identify those paths. Containment determines what happens when one remains open.

The organizations that succeed with AI security will do both.

To understand how Ensage AI and the CoIP Platform implement this architecture in your environment, read Governing AI Agents at the Network Layer or talk to an architect.