DEV Community: Kalyan Ram Jaladi

AI Ops Agents Are a New Class of Attack Surface

Kalyan Ram Jaladi — Sun, 26 Apr 2026 17:36:34 +0000

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.

Your DevOps automation is invisible to AI. That's AI-Debt. And it's compounding.

Kalyan Ram Jaladi — Fri, 17 Apr 2026 15:56:01 +0000

A new concept for platform and DevOps engineers, and why the window to act is narrower than you think.

A few months ago I set out to build an internal DevOps agent. The goal was straightforward: diagnose pipeline failures and surface root causes faster than any engineer could manually. I was writing Python functions, connecting to the ADO REST API, the Kubernetes client, the Azure SDK. Building the integration layer from scratch.

A senior colleague asked one question that changed everything: "Have you looked at the Azure MCP Server?"

I hadn't. That question opened a window into an entire vendor ecosystem being assembled at speed, and into a far more important question about what it had not yet built. That gap has a name. This article is about it.

The future is agent-orchestration. MCP is its language.

We are moving from a world where automation meant writing explicit instructions for machines, to one where autonomous agents receive a goal and reason their way to achieving it. For every DevOps and platform team, the question is whether their existing automation will be visible to those agents, or invisible.

The interface that makes automation agent-visible is the tool: a callable function an agent can discover, invoke, and reason over. The open standard governing how tools are described, discovered, and called is Model Context Protocol (MCP).

MCP has three components. The MCP Host is the environment where the agent runs (an IDE like Cursor or Kiro, a platform like GitHub Copilot, or a custom agent you build). It contains the LLM doing the reasoning. The MCP Client lives inside the host and handles protocol communication. The MCP Server is where tools live, exposing callable functions and responding to invocations.

In Python, a tool on an MCP Server looks like this:

@mcp.tool()
async def get_build_logs(organization: str, build_id: int) -> str:
    """Retrieve the full log output for a specific ADO pipeline build."""
    ...

The @mcp.tool() decorator is the registration contract. The docstring (the text in triple quotes) is what the agent reads when deciding whether and how to call this function. Not optional documentation. It is the agent's primary reasoning interface into your tool. More on this shortly.

SDK downloads grew from 100,000 at launch to over 8 million by April 2025. In December 2025, Anthropic donated MCP to the Linux Foundation, co-governed by OpenAI, Google, Microsoft, AWS, and Salesforce. The same governance move Kubernetes made in 2016. When something enters Linux Foundation governance, it stops being one vendor's experiment and becomes shared infrastructure.

Every major cloud vendor has now built production-grade MCP servers for their own ecosystems. What matters for this article is what they have built, what they haven't, and what that gap means for every DevOps platform already running.

What vendors have built — and why AWS is leading this race

Azure MCP Server (GA) exposes 40+ Azure services as agent-callable tools. The ADO MCP Server covers pipelines, builds, pull requests, and repositories. AWS embedded MCP into Bedrock AgentCore with IAM permissions and CloudTrail audit logging per tool call. Google released fully managed MCP servers for GKE, BigQuery, AlloyDB, and Spanner. Microsoft shipped a dedicated SQL MCP Server covering SQL Server, PostgreSQL, and Cosmos DB. Zero code, open source, free.

Beyond their own services, the vendors have gone further, building tools to make your existing automation agent-ready without custom code. This is where the comparison gets interesting.

AWS is the clear pioneer. At AWS Summit New York in July 2025, they announced a $100 million investment in their Generative AI Innovation Center, with agentic AI as the centrepiece. At re:Invent 2025, they shipped three domain-specific autonomous agents: a DevOps Agent, a Security Agent, and Kiro, an agentic IDE. Their open-source Strands Agents SDK introduced a model-first design philosophy. Instead of developers hardcoding every workflow path, the LLM reasons over available tools and decides the path itself. AWS has made agent development a first-class engineering discipline, with tooling, documentation, and production infrastructure to match.

The centrepiece for existing automation is AgentCore Gateway: a fully managed service that converts your existing APIs and Lambda functions into MCP-compatible tools automatically. You provide an OpenAPI specification or a Lambda ARN, and the Gateway handles protocol translation, authentication, semantic tool discovery, and observability. No custom code required.

Azure has equivalent capability but spread across three services. Azure APIM can expose any REST API as an MCP server: import your OpenAPI spec, click "Create MCP server," done. Azure Functions has a native mcpToolTrigger binding. Microsoft Foundry provides governance across 1,400+ connectors alongside custom tools, authenticated through Entra. The capability is there, but it requires more coordination across services compared to AWS's single-surface approach.

Google's Apigee converts any managed API to an MCP server without changing the underlying service. Powerful for GCP-native APIs, but Apigee has historically been a complex enterprise product and lacks the seamless function-wrapping simplicity of AgentCore Gateway.

The green rows are real, meaningful progress. AWS leads on developer experience and unification. The red rows tell the more important story. And they have a name.

AI-Debt

AI-Debt is the human automation your team built that AI agents cannot reach.

Human is the key word. This is automation written by engineers, for engineers: scripts run manually, pipelines triggered by people, YAML files committed to repos and executed on build agents with specific tooling installed. It works perfectly for the people who use it today. The debt only becomes visible the day an agent arrives and has nothing to call.

AI-Debt has two distinct components: Interface-Debt and Context-Debt. Both matter, and neither is solved by any vendor.

What's locked: Interface-Debt

Interface-Debt is automation that exists but cannot be called by agents. It has no discoverable interface, no function signature, no API endpoint, no callable handle that an agent can find and invoke.

Your ADO pipeline YAML that runs a Helmfile deployment: not callable by agents. Your PowerShell script that creates Azure resources: not callable by agents. Your Bash script that validates secrets before a deployment: not callable by agents. Your kubectl wrapper that diagnoses stuck pods: not callable by agents. Bicep templates, ARM parameters, Makefile targets, cron scripts: none of them are discoverable or invocable.

Vendors are reducing Interface-Debt for API-surface automation (code that already has a callable interface: Lambda functions, REST APIs, Azure Functions, managed cloud endpoints). Valuable progress. But it only covers automation that already exposes a typed, invocable surface. A Bash script running on an ADO pipeline agent has no Lambda ARN. A Helmfile task has no OpenAPI spec. The auto-wrap tools have nothing to target.

For Azure/ADO environments specifically, the gap is significant. Years of YAML. Hundreds of pipeline tasks. Thousands of shell functions. All invisible to agents.

What's dark: Context-Debt

Context-Debt is callable automation that agents cannot use intelligently, because the tools carry no description of when to use them, what they do, or how they behave on your specific platform.

When an AI agent is given a set of tools, it decides which tool to call, and how, entirely based on the Python docstring attached to each tool. Not the code. The description.

Research published in 2026 quantified this directly: editing tool docstrings can yield up to 10 times more usage of the same underlying function in production agents. A 2026 benchmark called OpaqueToolsBench studied what happens when tools have incomplete documentation and found that LLMs consistently struggle with tools that lack clear best practices or documented failure modes.

Anthropic's own engineering team documented this from building Claude Code: when they launched the web search tool, they discovered Claude was needlessly appending "2025" to every query, biasing results. The fix was not a model change. It was improving the tool's docstring.

AgentCore Gateway can wrap your Lambda, but it cannot write the docstring that tells the agent when this tool is relevant, what your platform's naming conventions are, or why a particular failure pattern should trigger it first. That knowledge exists only in your engineers' heads, your incident history, and the habits your team has built over years.

A Lambda with an empty docstring is callable. It is not agent-ready. That gap is Context-Debt.

The AI-Debt audit: two questions

Before paying down AI-Debt, you need to know how much you have. Most teams have never measured it.

Two questions. Count the numbers and you have your baseline.

Most enterprise DevOps platforms, when audited this way, find 70-90% of their automation sitting in Interface-Debt, with significant Context-Debt on whatever is callable. That number is your starting point.

How custom MCP tools pay down both debts: three examples

Custom MCP tools are new Python functions decorated with @mcp.tool(). They do two things at once: give your existing automation a callable interface (addressing Interface-Debt), and encode your platform knowledge in their docstrings (addressing Context-Debt). One new function, two debts addressed.

Example 1: Context-Debt (same function, different quality)

This tool retrieves Kubernetes pod logs, a core diagnostic step in any deployment failure. The engineer already has a working kubectl logs call. The question is whether an agent can use it intelligently.

The key is the Python docstring. This is what the agent reads when deciding whether and how to call this function. Not documentation for your colleagues, but the agent's only reasoning interface into your tool.

# Context-Debt: callable, but the agent has nothing to reason with
@mcp.tool()
async def get_pod_logs(namespace: str, pod_name: str) -> str:
    """Get logs for a pod."""
    result = subprocess.run(
        ["kubectl", "logs", pod_name, "-n", namespace],
        capture_output=True, text=True
    )
    return result.stdout

# Context-Debt resolved: the docstring tells the agent
# when to call this, how to call it, and what to do next
@mcp.tool()
async def get_pod_logs(
    namespace: str,
    pod_name: str,
    tail_lines: int = 100,
    previous: bool = False
) -> str:
    """
    Retrieve recent logs from a Kubernetes pod in the AKS cluster.

    Use when diagnosing:
    - CrashLoopBackOff pods — set previous=True to see the crash reason
    - Init container failures — include init container name in pod_name
    - Startup failures during helmfile atomic deployments

    Namespace naming on this platform: {service}-{env}
    e.g. payments-dev, payments-staging, auth-prod

    If pod_name is unknown, call get_pods_in_namespace() first.
    Returns last {tail_lines} log lines. Increase for deeper history.
    Returns empty string if pod has not started emitting logs yet.
    In that case, call describe_pod() to check events instead.
    """
    cmd = ["kubectl", "logs", pod_name, "-n", namespace,
           f"--tail={tail_lines}"]
    if previous:
        cmd.append("--previous")
    result = subprocess.run(cmd, capture_output=True, text=True)
    return result.stdout or result.stderr

The code is nearly identical. The agent's ability to use it correctly is not. The second version tells the agent when to call it, what namespace naming convention to use, which companion tool to call when it doesn't have a pod name, and what an empty response means. Without that docstring, the agent either skips the tool, calls it with wrong parameters, or hallucinates a response.

Example 2: Interface-Debt (wrapping an existing script)

Your team has a Bash script, /scripts/get-failed-builds.sh, that queries the ADO REST API for recent pipeline failures. It has been running for two years. Developers trigger it manually or reference it in ADO pipeline tasks running on a private agent pool. No AI agent can call it. It lives on a file system, not behind an API, with no discoverable interface.

Here is how you pay down Interface-Debt: write a new MCP tool that calls the script, giving it a callable interface, while encoding platform knowledge in the docstring.

# /scripts/get-failed-builds.sh
# Runs on ADO private agent pool, triggered manually or via pipeline task
# Usage: ./get-failed-builds.sh <project> <pipeline-name> <days>
# Returns: JSON array of failed runs with build_id, stage, duration
# No agent can reach this — it has no callable interface

# New MCP tool: Interface-Debt + Context-Debt resolved together
@mcp.tool()
async def get_recent_pipeline_failures(
    project: str,
    pipeline_name: str,
    days_back: int = 7
) -> list[dict]:
    """
    Get recent failed pipeline runs for a given ADO project and pipeline.

    Wraps the internal ADO query script and returns structured failure data.
    Call this as the first step in any pipeline diagnosis workflow.
    It gives you the build IDs needed for deeper analysis.

    Pipeline naming on this platform: {service}-{env}-deploy
    e.g. payments-dev-deploy, auth-staging-deploy, gateway-prod-deploy

    Returns list of failures with fields:
    build_id, start_time, failed_stage, duration_seconds,
    triggered_by, branch, retry_count.

    Most common failed stages on this platform:
    - helmfile-apply     -> missing secrets (79%) or image pull (15%)
    - integration-tests  -> environment config or dependency issues
    - security-scan      -> new CVE in base image (check monthly patch cycle)

    After calling this, pass build_id to diagnose_build_failure()
    for root cause analysis.
    """
    result = subprocess.run(
        ["/scripts/get-failed-builds.sh", project,
         pipeline_name, str(days_back)],
        capture_output=True, text=True
    )
    return json.loads(result.stdout)

The Bash script has not changed. It still runs where it always ran. The new MCP tool is a thin wrapper that converts it from invisible to callable, and the docstring converts it from callable to agent-ready. That is what paying down Interface-Debt looks like in practice.

Example 3: The purely contextual tool (no vendor equivalent)

This tool has no script to wrap and no API to call. It queries an internal incident database built from 18 months of real platform failures. But the real value is not the database call. It is the docstring that encodes the diagnostic patterns a senior engineer applies instinctively. Think of it as team knowledge, made callable and permanent.

No vendor MCP server can build this. AgentCore Gateway has no OpenAPI spec to import. This tool exists only because someone encoded real incident history into a docstring.

@mcp.tool()
async def get_platform_failure_pattern(
    error_signature: str,
    pipeline_stage: str,
    service_name: str = None
) -> dict:
    """
    Look up known failure patterns on this platform from real incident history.

    CALL THIS FIRST in any diagnosis before running other tools.
    It encodes 18 months of incident data and directs you to the
    highest-probability root cause, skipping diagnostic dead ends.

    Known patterns (error_signature -> likely cause):
    - "timed out waiting for condition" + helmfile-apply
      -> missing secret in namespace (79% of cases)
      -> next: call check_keyvault_secret_exists()

    - "ImagePullBackOff"
      -> ACR authentication failure or incorrect image tag (92%)
      -> next: call check_acr_image_exists()

    - "CrashLoopBackOff" shortly after deployment
      -> application ConfigMap missing or malformed (71%)
      -> next: call get_pod_logs(previous=True) then check_configmap()

    - "503 Service Unavailable" post-deployment with healthy pods
      -> stale Istio VirtualService conflict in namespace (58%)
      -> next: call get_all_virtualservices_for_host()

    Returns: likely_cause, confidence_percent, recommended_tools,
    similar_past_incidents, avg_resolution_minutes.

    If confidence < 50%, this is a new pattern not yet seen.
    Document it via create_incident_record() and use the generic path.
    """
    return await query_incident_database(
        error_signature, pipeline_stage, service_name
    )

This is Context-Debt resolved, and the only category of tool that truly differentiates your platform's agent capability from every other organisation using the same vendor tooling.

A note on diminishing AI-Debt: why vendors won't close this gap

Could vendors extend their auto-wrap to cover scripts and pipeline tasks? Theoretically yes. AWS could build mechanisms to execute arbitrary scripts via Lambda wrappers, Azure could auto-instrument ADO pipeline tasks. But there is a structural reason why they are unlikely to prioritise this.

Vendors have no incentive to solve your platform's knowledge problem. Their investment goes into making their own services and managed resources accessible to agents: Lambda, REST APIs, their cloud-native tooling. The script-and-pipeline estate your team has accumulated over five years is yours, not theirs. Even if a vendor shipped a zero-code script wrapper tomorrow, it would only address Interface-Debt. Context-Debt (the knowledge of when to use each tool, how your platform behaves, what your failure patterns are) remains yours to encode. No vendor will ship that for you.

That is what makes the custom MCP layer valuable and defensible. It is automation that only you can build.

The window is closing

Gartner predicts 40% of enterprise applications will integrate task-specific AI agents by end of 2026, up from less than 5% in 2025. At the same time, they predict over 40% of those agentic AI projects will be cancelled by end of 2027 due to inadequate technical foundations.

Read those two together. Agents are arriving. Nearly half the projects will fail — not because the models are poor, but because the platforms were not ready.

The ones that succeed will have paid down AI-Debt before the agents arrived.

Where to start

Run the audit. Count your automation across two dimensions: what's locked and what's dark. That number is your baseline.

Start with the highest-value workflows. Incident diagnosis, deployment validation, environment setup. Build custom MCP tools for those five or ten scenarios first.

Treat docstrings as engineering work. The quality of your agent's decisions is directly proportional to the quality of your docstrings. Not documentation overhead — the core of what makes a platform agent-ready.

AI-Debt is silent. Your scripts still run. Your pipelines still deploy. Everything works perfectly for humans. The debt only becomes visible the day an agent arrives and has nothing to call.

That day is closer than most platform teams realise.

Platform and DevOps engineering at a large UK financial institution. Views are my own.
I write about AI agents, cloud architecture, and occasionally things that have nothing to do with technology.
Building in this space or thinking about AI-Debt on your platform? I would be glad to hear from you.