AI Ops Agents Are a New Class of Attack Surface

Decades of operational tribal knowledge are now concentrated in one system. That concentration is the feature, and the vulnerability.

My first thought after reading about the Azure SRE Agent CVE was not about Microsoft's bug. It was about a new attack surface. The agent's security model has not caught up to what the agent can reach.

Earlier this month, security researcher Yanir Tsarimi at Enclave AI disclosed CVE-2026-32173 against Azure SRE Agent, rated CVSS 8.6. Azure SRE Agent and its AWS counterpart, AWS DevOps Agent, are a new generation of cloud-native agents built to do what senior site reliability engineers do: triage incidents, query logs across services, correlate metrics with traces, and propose or execute fixes. Both vendors position these agents as the future of operations, available 24x7, queryable in natural language, and capable of acting on the cloud accounts they are wired into. They run as managed multi-tenant SaaS in the vendor's infrastructure.

The flaw allowed an attacker with any valid Entra ID token, from any Microsoft tenant, to silently eavesdrop on another customer's agent activity. The agent's transport layer accepted the token without checking whether it had any business looking at the victim tenant's data. Live agent conversations, log queries, command outputs, the agent's reasoning as it worked through an incident, all of it readable by an attacker who only needed to spin up a free Microsoft tenant of their own.

Microsoft has acknowledged it and patched the issue server-side. No customer action was required, and there is no public proof-of-concept exploit. But the architectural premise that made this attack possible is still standing in every enterprise that adopts an SRE or DevOps agent over the next year.

What follows is the Pandora's box. Some context first, with the recent CVEs that opened it up for me.

Inside the Pandora's box

Different attack classes. Different root causes. What they share is the architectural premise: an agent with broad operational reach, autonomy to act, and trust from humans to do useful work. When any one of those is exploited, the consequence scales with what the agent can reach, not with the depth of the bug.

LangChain and the open source frameworks (LangGraph, CrewAI, and others) take their share of vulnerabilities, partly because they are the most popular targets, partly because their code is open to scrutiny. The good news is that fixes ship in days. Cloud-native agents are a different beast. Azure SRE Agent, AWS DevOps Agent, and the equivalent offerings from other vendors operate with elevated privileges inside proprietary ecosystems. The complexity is massive, the attack surface is opaque to customers, and the patching depends entirely on the vendor.

New gates for agents (and why enterprises are right to wait)

Traditional enterprise security has well-understood gates. We use SonarQube, Nexus IQ, Aqua Security, and similar tools to cover code quality, dependency vulnerabilities, container image scanning, and base image hygiene. None of them are trained on what an agent can actually do once it is deployed. The category does not exist in their product mental model yet.

From my own experience working in regulated environments, this is exactly why agent adoption has been slower than vendors expected. And the delay is rightful, not stubborn. Every new architecture pattern in a regulated enterprise has to pass through the architecture review group. Getting a new API pattern from on-premises to cloud approved involves serious questions: does the traffic sit behind the approved gateway, is it routed through the existing F5 and Akamai layers, are the backend images fully scanned, does it follow the approved load balancer pattern. RBAC is enforced at every layer, every action is consent-gated, and no new design pattern goes into production without sign-off.

These gates exist for good reasons, and they work for traditional services. They do not yet have categories for agents. The new gates that have to come, based on what the recent CVEs have exposed:

• Tenant isolation enforced at the application layer, not just the auth layer. The Azure CVE is what happens when you assume the auth layer covers it.
• MCP server provenance. How do you verify that the MCP server you are loading is the one the vendor signed, and not a typosquatted version that an attacker registered last week. Custom MCP tools will need their own security review process.
• Human-in-the-loop on destructive operations. The old four-eyes check, where two engineers approve a destructive operation, will become standard for agent-initiated changes.
• Cross-agent zero-trust in multi-agent systems. An agent should not trust another agent's request just because they are inside the same orchestration. Signed intent on tokens, re-authorization at each privilege boundary, audit trails that survive even if one agent is compromised.

Imagine a banking client deploying an SRE agent and getting hit with the Azure CVE before the patch. The blast radius would not be one service. It would be operational intelligence across the bank's entire incident history.

The Tribal-Knowledge is now Agent's

The analogy I am thinking of is this. A senior support or ops engineer at a large company carries a body of context in their head that lets them solve complex problems fast. The technical term for this is tribal knowledge: the unwritten, accumulated understanding of how the system actually behaves, which alerts matter, which workarounds work, what was tried last time, why this particular service has that strange retry logic. It is the knowledge that does not exist in any document because it was learned through years of incidents.

A typical platform team has maybe ten such engineers. Their cumulative tribal knowledge is the actual reason incidents get resolved in minutes instead of hours.

An AI Ops agent compresses that knowledge into a single system, and it does so by design. Several mechanisms compound to make this happen:

• MCP tool proliferation. The agent connects to dozens of MCP servers including observability platforms, code repositories, CI systems, ticketing systems, and runbooks. Each one adds reach.
• Skills. Skills are the instruction manuals that tell the agent how to use the tools. AWS DevOps Agent and Azure SRE Agent both ship with pre-loaded Skills that encode the topology, the conventions, the patterns of the environment they operate in.
• RAG databases. Past incidents, postmortems, runbooks, and architectural documents are indexed into retrieval-augmented generation stores. This is how the agent learns the equivalent of "what happened last time."
• Conversation memory. Across sessions, the agent retains operator intent, recent decisions, and reasoning traces.

The result is one system with the cumulative tribal knowledge of ten ops engineers, available 24x7, queryable in natural language, reachable over the network. That compression is the value proposition. It is also a new class of attack surface, because compromising one agent yields more than compromising any single underlying service ever could.

This is what I mean by the concentration is the feature, and the vulnerability.

A note on Skills, because they do not get enough attention. Skills are simple in form, often short markdown files, but they are what gives an agent the appearance of expertise. They are how you give an agent the tribal knowledge that it does not have by default. A short instruction document that captures the conventions of the team, the names of services, the meanings of error codes, the workarounds that have accumulated over years, that is what makes the difference between an agent that gets stuck in a reasoning loop and an agent that finds the answer in seconds. Which is also why Skills are a security concern. If the agent loads instructions from an untrusted source, those instructions are now part of the agent's behavior. EchoLeak from June 2025 is the classic example of how Skills and instructions become an attack vector. Skills make the agent more powerful, and they expand the surface area of what an attacker can manipulate.

A deserving new threat model

Once you start looking at agents through this lens, several attack categories become more interesting. The OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications 2026 in December 2025, peer-reviewed by over 100 industry contributors.

A few of the categories are worth calling out because they map directly to what the recent CVEs have shown.

Tool poisoning (ASI02). An attacker compromises the descriptor or metadata of an MCP tool, so that when the agent loads the tool at runtime, it loads malicious capability descriptions. The agent then invokes the tool based on falsified metadata. This is not theoretical. The malicious MCP server impersonating Postmark on npm, reported in September 2025, was the first documented in-the-wild case.

Adversary-in-the-middle (covered under ASI07 Insecure Inter-Agent Communication). Multi-agent systems pass messages between agents, often over weakly authenticated channels. An attacker positioned in the middle can intercept and manipulate those messages, hijacking the goals or actions of downstream agents.

Goal hijacking and prompt injection (ASI01). The most discussed category, and rightly so. EchoLeak demonstrated that a single crafted email could redirect an agent's goals without any user interaction. The pattern works whenever the agent ingests untrusted natural language as part of its input.

Identity and privilege abuse (ASI03). What the Azure SRE Agent CVE was. An agent operates without a strong identity of its own, inherits permissions from the user it acts on behalf of, and the boundary between agent identity and user identity blurs in dangerous ways.

This is not the full list. Memory poisoning, supply chain compromise, cascading failures across multi-agent systems, rogue agents, and human-agent trust exploitation are all in the OWASP doc.

Closing thoughts

This is a new game and an exciting one. AI is being called one of the great inventions of the last century, and I broadly agree. But that versatility deserves a dedicated threat-modeling discipline, which does not yet exist in most enterprises. The new architectural category disrupts how we think about review, governance, and security ownership. It will create new jobs and new roles.

I am still working through what this means for my own practice. The post is more of a thinking-out-loud than a recommendation. If you are seeing this differently from where you sit, I would be interested to hear about it.