The Best Way to Secure AI Agents

Summarize with:

ChatGPTClaudePerplexityGoogle AIGrok

An AI agent is a workload that makes decisions: everyone has internalized that part. 

But we talk less about what those decisions actually do, maybe because it feels mundane next to the model. They open connections: to a model provider for the next inference, to an MCP server for the next tool call, to a package registry for a dependency the runtime decided it needed, to an internal API, a database, an object store, or another agent because the workflow required it. 

An agent reasons in a loop, and every turn of that loop is one or more outbound connections. That reach is how an agent does its work. Most enterprise AI security programs are looking one layer too high. 

What We’re Securing Today 

The modern AI security stack is getting serious. Organizations assess the artifacts going into the agent: models, extensions, MCP servers, packages, and skills. They secure the application around it with lifecycle controls and runtime monitoring. They give the agent an identity, increasingly a workload identity with machine-identity standards underneath. They scope permissions, add approval flows for sensitive operations, and monitor what the agent does. If you're doing all of that, you're ahead of most organizations.  

Every one of those controls has one thing in common: it acts on the agent.  

• Identity answers who is this agent? 

• Authorization answers what is this identity permitted to do? 

• Data controls answer what information can it access or move? 

• Network policy answers a different question: which systems is this workload allowed to communicate with at all? 

That last question is the one agentic AI makes urgent, because the agent itself, not just the application around it, now influences what it reaches next. At most enterprises, nothing answers it. The default is that an agent can reach anything its cloud account can reach: the open internet, and most of the enterprise alongside it. 

Three Ways This Breaks 

Prompt injection becomes a reachability problem. Prompt injection gets discussed as a model or application-security issue, which it is. But from a defender's seat, the question is what happens after the model follows the injected instruction. An attacker plants instructions in a document, a web page, or a tool response. The agent follows them and opens a connection. The identity is valid and the action may even be authorized. The destination is where the data was never supposed to go. The network does not understand the model's reasoning, and it does not need to. It enforces a boundary independent of that reasoning. It cannot stop the injection, but it can turn a successful injection into a contained failure instead of a successful exfiltration path. 

Supply-chain compromise turns trusted software into an outbound capability. In March 2026, the TeamPCP campaign (documented independently by SANS, Unit 42, and others) compromised a chain of widely used open-source tools in rapid succession. It started with the Trivy scanner and cascaded through npm, Docker Hub, and Checkmarx into PyPI, where both the LiteLLM gateway and the Telnyx SDK were backdoored. LiteLLM, which Wiz found present in 36% of the cloud environments it monitors, put an estimated 2,100-plus organizations at potential exposure. The compromised packages were trusted code making real outbound calls in legitimate pipelines.  

In one environment, an engineer added four command-and-control addresses to a network blocklist, and the update propagated to every gateway before the compromised packages could communicate. No credentials were exfiltrated. Everywhere without that enforcement point, the same compromise ran to completion, and the first signal was a detection event after the fact.  

The lesson is not only to scan dependencies. Software running with legitimate credentials and unrestricted egress does not need to beat your IAM, because it already has what it needs.

The same gateway stayed in the news. In October 2026, a LiteLLM authentication-bypass flaw, CVE-2026-59822, became the first MCP vulnerability added to CISA's Known Exploited Vulnerabilities catalog, with exploit chains that reach cloud metadata endpoints and end in cloud compromise. 

A September 2026 campaign called Deadbugz showed how little a one-time review protects. Attackers pushed a malicious MCP server into open-source projects through public GitHub pull requests, tracked to a single account that filed 23 pull requests across unrelated projects in 74 minutes. The server shipped two harmless tools and held its payload until the client had made exactly three tool calls, then rewrote the metadata it returned into instructions to collect SSH keys, AWS credentials, shell history, and Kubernetes configuration. It passed review because the hostile behavior did not exist at review time. The approval it already held did nothing to stop what came next. What limits the damage from a server like that is whether anything constrains where its traffic can go once it starts collecting credentials. 

The blast radius is not only outward. Lateral movement is the part of this conversation we skip, because it feels like a traditional network concern. It is not anymore. An agent workload sits in a VPC beside internal APIs, data platforms, CI/CD, finance and HR systems. A compromised agent that can reach the internet can usually also reach those neighbors, because the default posture between workloads in a shared environment is permissive. A policy that blocks external command-and-control traffic but leaves east-west open has solved half the problem. 

The three failure modes share one property: the agent is operating within everything the application-layer controls allow, and the damage happens at the layer beneath them. 

Why We Need More than Identity Alone to Close It 

The natural objection is to give every agent a strong workload identity and enforce least privilege through IAM. You should do that. But identity and reachability solve different problems. A workload identity establishes who an agent is to the system receiving the request. It does not define which systems the agent should be able to contact in the first place. A passport proves who you are, but it does not decide which borders exist. An agent can carry a valid identity and still be permitted to reach far too much. 

Identity and network are not alternatives. They form a chain: identity, authorization, reachability, data access, action. Reachability is the link most programs do not own. 

Implementing Network Governance for Agents 

This does not mean bolting another firewall in front of every workload. It does mean making communication policy part of the agent's security architecture, with the same discipline already applied to identity and actions: 

• Start from default-deny: nothing leaves unless a policy allows it. A route existing is not a reason to use it. 

• Declare permitted destinations at design time (the sanctioned model providers, approved MCP servers, and required APIs and registries) rather than inferring them from behavior after something has gone wrong. 

• Write policy against workload identity rather than IP address, because cloud addresses rotate by the hour and identity does not. 

• Govern egress and east-west traffic together. An agent that cannot reach the internet but can freely reach the finance platform is not contained. 

• Put enforcement in the network path rather than inside the agent, because sidecars and per-runtime code changes leave coverage partial. 

• Inventory how agents actually communicate before switching to default-deny, or the policy becomes an exception-request queue. Default-deny is an operational change that needs policy automation and clear ownership. 

Zero Trust has argued for all this for a decade, but agentic AI makes it critical for enterprises.

The Ownership Problem 

This gap persists for an organizational reason as well as a technical one. Agent connectivity sits between org charts. The AI team owns the agent, IAM owns identity, AppSec owns the application, Data security owns the data, Platform teams own infrastructure, and Network owns connectivity. 

No team owns the policy that joins them: which agent, under which identity, may talk to which destination, for what purpose, and with access to which data. That is the policy an agentic architecture needs, and at most enterprises no single team is accountable for it. Without an owner, the default is reachability, which is rarely the same thing as authorization. 

The Network is Necessary, But Not Sufficient 

Overclaiming is how this argument gets dismissed. Network governance bounds blast radius, but it does not eliminate every form of data loss. 

If an agent is legitimately allowed to reach a code host or model provider, a compromised agent can still abuse that permitted path. The network can say that a destination is allowed. It cannot always say that a particular payload should never have been sent. That requires controls at the API, identity, and data layers. The same holds inside the enterprise: an agent permitted to reach an HR service should not therefore be able to pull every record that service exposes. Connectivity is not data authorization. 

Lateral movement is the exception. If the policy between an agent workload and the one next to it is default-deny, the pivot does not happen. 

That is a smaller claim than network solving AI security, and a larger one than most enterprises are making, because most are making none. In a 2026 Omdia survey of security leaders, 99% said they want microsegmentation, the control that governs which systems a workload can reach, yet only 9% had protected more than 80% of their critical systems with it. Gartner puts current adoption at 5 to 20 percent. For nearly everyone else, the identity controls can be perfect, the action governance can be perfect, and the network beneath them is still fully open. 

What This Means for the CISO 

The starting point is not another AI security product. It is answering five questions: 

1. Where do our agents live? 

2. What can each agent currently communicate with? 

3. Which of those destinations are actually required? 

4. What happens if an agent is manipulated or compromised? 

5. What control stops it from reaching somewhere it should not? 

For many enterprises, the answers will be uncomfortable: agents with unrestricted egress, shared segments holding both autonomous workloads and sensitive services, no inventory of agent destinations, no policy expressed in terms of agent identity, and no team accountable for any of it. That is the gap worth closing. It is the same gap the microsegmentation numbers describe, now inherited by a workload class that decides its own destinations at runtime. The hyperscalers are starting to close their corner of it, with destination-based perimeter controls now appearing natively in the major clouds. 

Final Thoughts

Agentic AI is the first workload class most enterprises will run where the workload itself decides what to reach, in real time, on inputs an attacker can shape. That deserves different attention to the layer underneath it. 

The agent will get its identity, permissions, artifact assessments, its application monitoring, and its action governance. All of that is necessary, but none of it should imply that every network path beneath the workload is acceptable. 

When an agent's decisions are wrong or manipulated, or dependencies fail, the goal is to make sure a compromised agent has somewhere to go, but not everywhere. That is the role the network plays in an agentic AI security architecture. It does not replace AI security: it is one of the containment layers that AI security depends on. 

Explore Aviatrix Clearance, which offers default-deny enforcement for all cloud workloads without breaking production.

References

CISA, “Known Exploited Vulnerabilities Catalog,” accessed Oct. 21, 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Cloud Security Alliance, “TeamPCP’s LiteLLM Backdoor: New Data Shows 2,100+ Orgs Exposed,” Aug. 12, 2026, https://labs.cloudsecurityalliance.org/research/csa-research-note-litellm-trivy-supply-chain-compromise-2026/

Elisity, “Elisity Commissioned Omdia Survey Reveals 90% of Organizations Falling Behind on Microsegmentation Despite Near-Universal Demand,” April 28, 2026, https://www.elisity.com/news/elisity-commissioned-omdia-survey-reveals-90-of-organizations-falling-behind-on-microsegmentation-despite-near-universal-demand

Google Cloud, “Securing Agentic AI With Perimeter Guardrails: What’s New in VPC Service Controls,” June 27, 2026, https://cloud.google.com/blog/products/identity-security/securing-agentic-ai-whats-new-in-vpc-service-controls

Pillar Security, “Deadbugz: Currently Active MCP Supply-Chain Campaign,” Aug. 12, 2026, https://www.pillar.security/blog/deadbugz-currently-active-mcp-supply-chain-campaign

SANS Institute, “When the Security Scanner Became the Weapon: Inside the TeamPCP Supply Chain Campaign,” March 25, 2026, https://www.sans.org/blog/when-security-scanner-became-weapon-inside-teampcp-supply-chain-campaign

Unit 42, “Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure,” March 31, 2026, https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/

Wiz, “Off Guard: Breaking LiteLLM From Authentication Bypass to Cloud Compromise,” Sept. 9, 2026, https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise

Zero Networks, “Microsegmentation Ascends: 2025 Gartner Hype Cycle Takeaways,” Sept. 24, 2025, https://zeronetworks.com/blog/microsegmentation-ascends-2025-gartner-hype-cycle-takeaways