AI Agents as Attack Surface: Detect the Action, Not the Prompt

Most of what’s written about securing AI agents is not aimed at you. Guardrails, prompt filtering, model red-teaming, alignment evals — that’s application security, and it belongs to the team shipping the agent. It’s real work. It is also not the job of the person running detection, and pretending otherwise is how detection engineers end up staring at a problem they have no telemetry for and no lever on.

Here is the reframe that puts an AI agent back inside your job description: an AI agent is a non-human identity with tool access and a decision layer you cannot inspect. You will never see the prompt injection in your SIEM. The malicious instruction lives in a document the model read, gets resolved inside a black-box reasoning step, and never touches a log you own. So stop trying to catch it. The agent acts through a credential — it calls tools, hits APIs, reads data — and that is telemetry you already collect and already know how to reason about. To a detection engineer, an agent is not a new species of threat. It’s the non-human identity problem from the rest of this series, with the volume turned up and a sentence of English as the injection vector.

This post is about what actually changes for detection when agents show up, and what doesn’t.

The Fastest-Growing Identity You Don’t Monitor

Start with scale, because it’s worse than the headline number and it lands directly on the gap this series has been documenting. In 45 to 1 I made the case that non-human identities already outnumber humans by a wide margin and generate none of the signals your detection program was built for. Agents make that curve vertical. Of roughly 109 machine identities per human in the average enterprise, about 79 are now AI agents — the majority of all your non-human identities are things that plan and act on their own [1]. Ninety-nine percent of organizations have adopted agents and 91% are running them in production, and agent identities are projected to grow faster than any other kind of identity you have [1].

Now the governance vacuum underneath that curve. Only 37% of organizations can revoke an AI agent’s credentials. Only 30% keep immutable audit logs of what those agents do. And 40% of deployed agents already have access to organizational data [1][2]. Read those three together: the majority of your fastest-growing identity population can touch real data, most of you can’t reliably turn one off, and most of you aren’t recording what it did. That is not an AI problem. That is the identity blind spot with a deadline attached.

The instinct is to treat this as exotic. It isn’t. Five Eyes published guidance in May 2026 telling organizations to treat agentic systems as untrusted and to limit their access [3] — which is the same posture you already (should) apply to any service account with production reach. The novelty is the injection vector, not the trust model.

A Confused Deputy With Real Credentials

Here is the mechanism, and it is old. An AI agent is a confused deputy: a privileged actor that can be manipulated into misusing its own legitimate access on behalf of someone who has no access at all. The manipulation arrives as content the agent is designed to process — a line in a document, a code comment, a webpage, a tool description — and the agent, doing exactly what it was built to do, carries out the attacker’s instruction using its own valid credentials.

The proof is no longer theoretical. EchoLeak (CVE-2025-32711, CVSS 9.3) let an attacker exfiltrate data from Microsoft 365 Copilot with zero clicks: a hidden prompt embedded in a document, and Copilot read it and leaked, no user action required [4]. A GitHub Copilot flaw (CVE-2025-53773, CVSS 9.6) let injection payloads buried in source code drive arbitrary terminal command execution [5]. In the Model Context Protocol ecosystem, tool-poisoning attacks hide malicious instructions inside tool descriptions — metadata the model reads and trusts — turning a benign-looking tool registry into an exfiltration path [6]. OWASP put a name and a rank on this: Tool Misuse is ASI02 in the 2026 Top 10 for Agentic Applications, sitting alongside memory poisoning and identity-and-privilege abuse [7].

Notice what every one of these has in common. The credential is valid. The permission was granted. The action, viewed in isolation, is something the agent is allowed to do. This is the exact shape of the attack I walked through in OAuth Abuse in SaaS: nothing authenticates falsely, nothing exploits a bug in the traditional sense — a legitimate identity is driven to do a malicious thing through the authorization layer. An agent is that pattern made autonomous. You are not going to catch it by inspecting the instruction. You catch it the way you’d catch any trusted identity behaving wrongly: by knowing what “right” looks like for that identity and noticing when it deviates.

Take the everyday version, not the CVE. You stand up an agent to do root-cause analysis — triage incidents, read logs, correlate across services. To do that job it needs broad read access, so you give it broad read access. Then one day, prompted by an incident description that happened to contain a stray instruction, or simply reasoning its way somewhere it shouldn’t, that agent starts pulling production logs full of customer PII and secrets — because it can, because it has a CLI and an MCP tool to call, and because nothing in its scope said “not those.” No exploit fired. The RCA bot used its own access to read logs it was technically permitted to read. That’s the detection you have to build for, and it’s detectable — just not where people are looking.

Why Your Baselines Break on Agents

Your behavioral detections assume a human. UEBA baselines a person: works roughly these hours, from roughly these places, at human speed, touching a bounded set of systems tied to a job. Impossible travel, off-hours access, a spike in files touched — all of it encodes the physics of a person with a laptop.

An agent violates every one of those assumptions in both directions at once. It runs 10,000 actions in a flawless sequence at machine speed, which either looks perfectly normal to a system tuned for human anomalies, or it trips your volume thresholds so constantly that you tune them off to stop the noise — and now you’ve disabled the one signal that mattered. It has no home timezone, no impossible travel, no “unusual for a Tuesday.” The behavioral envelope you’d draw around a person does not fit the thing at all.

This is the same failure mode I described for workload identities: the human-shaped baseline is the wrong ruler. And the fix is the same in spirit — you don’t baseline the agent against a human, you baseline it against itself. What tools does this agent normally invoke? What data domains does it normally read? At what rate, and reaching which systems? That envelope is stable enough to alert on, even when the exact sequence of actions never repeats. The RCA bot that has touched incident logs and service metrics for three months and suddenly reads the payments log group has left its envelope, and the envelope is the detection.

”You Can’t Baseline a Non-Deterministic Agent” — Yes You Can, Just Not the Way You Think

The strongest objection to everything above, and it deserves a straight answer: agents are non-deterministic. The entire point of an agent is that it decides, in the moment, to do things you didn’t script — including legitimately novel things every run. Behavioral detection needs a stable normal. Agents, by design, don’t have one. So isn’t per-agent baselining just chasing a distribution that never settles?

No — because you’re conflating two different things the agent has. The reasoning is non-deterministic. The authorized action space is not. A well-scoped agent has a bounded set of tools it can call, a bounded set of data domains it can reach, and a rate and volume envelope its job implies. The RCA agent’s reasoning path through an incident is different every time; the fact that it reads logs and metrics and never writes to production and never touches the payments datastore is not. You are not baselining the sequence of thoughts. You are baselining the envelope of authorized actions — which tools, which data, how fast, reaching where — and that envelope is far more stable than the reasoning that moves around inside it.

And here’s the part that matters most: where the envelope genuinely is unbounded — where the agent can legitimately call anything, read anything, at any rate — that is not a detection failure. That is an over-permissioned agent. If you can’t draw a boundary around what an agent is supposed to do, the problem isn’t your baseline, it’s that nobody scoped the agent, and you’ve built a machine that turns a single injected sentence into arbitrary access. The un-baselineable agent and the dangerous agent are the same agent. Which is the shift-left point I’ll close on.

Build Detection in Layers, Because You Won’t Get the Gateway Logs

Now the honest part, because the observability vendors will tell you a story that isn’t true for most teams. Yes, there is a mature-sounding stack for agent observability — OpenTelemetry now defines GenAI spans, and AI gateways can capture prompts, tool calls, responses, and retries in one place [8]. If you have that, instrument it; the tool-call layer is the richest signal there is, because it shows intent before impact.

But most teams don’t have it, and won’t for a while. So don’t anchor your detection strategy on a log source you don’t collect. Build in layers, and write detections at whichever layers you actually have — because a signal captured at three weak layers beats a perfect signal at a layer that doesn’t exist:

• The tool-call / gateway layer — what the agent decided to do (tool invoked, arguments, the retrieved content that shaped it). Richest, and the one most teams are missing today. Aspirational for now; wire it up as you get gateways in place.
• The identity / credential layer — the agent authenticating and assuming access: which service principal, which role, which token, from where. You almost certainly have this already, and it’s where a compromised or hijacked agent’s escalation shows up.
• The downstream resource layer — what the agent’s credential actually touched: CloudTrail, Entra and Graph audit, SaaS audit APIs, database and object-store access logs. This is the layer everyone already collects, and for most teams it is where agent abuse becomes visible today. The RCA bot reading the payments log group shows up here, in the audit trail of who-read-what, whether or not you ever saw the prompt.

The detection opportunities live at the intersection: an agent invoking a tool it has never used, reaching a data domain outside its task, spiking in call volume or velocity, touching a new system, or emitting sensitive data in a tool response. You can express the downstream-layer version of that today. Here’s the RCA case as a concrete tripwire against cloud audit logs:

# Fires when an automation/agent identity reads a sensitive data source it has
# no established history of touching — the "confused deputy leaves its envelope"
# case. This rule is the tripwire; pair it with a per-agent access baseline
# (the set of log groups / buckets / data domains this principal has read over
# a rolling window) and suppress anything already inside that envelope.
# Maps to OWASP ASI02 (Tool Misuse) and the confused-deputy pattern.
title: AI Agent Reading a Sensitive Data Source Outside Its Task Envelope
status: experimental
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_agent:
    # agent / automation roles — tag these deliberately at provisioning time
    userIdentity.arn|contains: ':assumed-role/agent-'
  selection_sensitive_read:
    eventName:
      - GetLogEvents
      - FilterLogEvents
      - GetSecretValue
      - GetObject
    requestParameters.logGroupName|contains:
      - '/prod/payments'
      - '/prod/pii'
      - '/prod/secrets'
  condition: selection_agent and selection_sensitive_read
falsepositives:
  - A real incident where this agent was explicitly scoped to the affected
    sensitive service — confirm the triage ticket authorized that data domain
  - New agent onboarding before a per-identity access baseline has formed
  - Broad-scope RCA agents with no envelope defined — that is a scoping finding,
    not a false positive (see below)
level: high

That last false-positive line is not a throwaway. If this rule is noisy because your RCA agent legitimately reads everything, the rule didn’t fail — it just found an over-scoped agent. Which is the whole point.

The Un-Baselineable Agent Is an Over-Scoped Agent

The gap this all turns on is the one between what an agent is scoped to touch for a task and what it can touch in general. The RCA bot needs broad standing read access to be useful, so its permission envelope is always wider than any single task’s envelope — and that gap is precisely what an injected instruction weaponizes. The attack doesn’t grant the agent new access. It spends access the agent already had and never should have carried at rest.

So the durable fix is the one that keeps showing up at the end of every post in this series: shift left of the action. Scope the agent’s access to the task, not the mission. Grant read to the payments logs at the moment an incident actually involves payments, through a just-in-time broker, and revoke it when the task closes — the same workload-IAM and least-standing-access argument that closed the NHI landscape post, and the same lesson as the identity-first kill chain: the cheapest place to break the chain is to make sure the access the attacker needs isn’t sitting there to be spent. An agent that can only ever touch its task’s data domain is an agent whose confused-deputy blast radius is bounded by design — and, not coincidentally, an agent whose behavior is finally baselineable.

Detection and prevention converge here, and that’s the takeaway. Building the envelope detection forces you to write down what each agent is supposed to do — which is the scoping exercise that should have happened before the agent shipped. If you can draw the boundary, you can both alert on it and enforce it. If you can’t, you’ve learned the most important thing about that agent: nobody knows what it’s for, and it can be talked into anything.

You will not detect the prompt. You were never going to. Watch the credential, baseline the envelope, and treat the agent you can’t baseline as the finding — because it is.

Resources

1. AI Agents at Work 2026: Securing the Agentic Enterprise — Okta (agent share of machine identities, adoption and production rates, credential-revocation and audit-logging gaps).
2. The Non-Human Identity and Agentic AI Governance Vacuum — Cloud Security Alliance (agent data access, governance shortfall).
3. CISA and International Partners Release Guide to Secure Adoption of Agentic AI — CISA/NSA and Five Eyes partners, “Careful Adoption of Agentic AI Services,” May 2026 (treat agentic systems as untrusted; least-privilege access).
4. CVE-2025-32711 (“EchoLeak”) — Microsoft MSRC, CVSS 9.3, zero-click LLM scope-violation exfiltration in Microsoft 365 Copilot.
5. CVE-2025-53773 — NVD, CVSS 9.6, remote code execution in GitHub Copilot via prompt injection embedded in source code.
6. Model Context Protocol Threat Modeling: Tool Poisoning and Prompt Injection — malicious tool descriptions in MCP metadata as an exfiltration and command-execution path.
7. OWASP Top 10 for Agentic Applications 2026 — OWASP GenAI Security Project (ASI01–ASI10; ASI02 Tool Misuse, memory poisoning, identity and privilege abuse).
8. AI Agent Observability — Evolving Standards and Best Practices — OpenTelemetry (GenAI spans, tool-call telemetry, gateway-captured execution traces).