AI agent attack detection needs a surface-based framework

At a glance

What this is: ARMO’s framework says AI agent attack detection must track four attack surfaces and the telemetry layers that expose them.

Why it matters: IAM, SOC, CNAPP, and platform teams need detection designs that follow agent behaviour across prompts, tools, identity, and orchestration instead of relying on one control plane.

Context

AI agent attack detection is a surface problem, not a single-tool problem. The article argues that attacks land across prompts, tool invocations, identity actions, and multi-agent coordination, while conventional container and runtime telemetry only sees fragments of that path. In practice, this means existing IAM, EDR, CNAPP, and SIEM stacks often observe the wrong plane for the attack they are expected to detect.

For identity and security programmes, the issue is not whether telemetry exists somewhere in the stack. It is whether the signals are captured at the point where the agent makes decisions and uses authority. Once those signals are missing, correlation becomes an after-the-fact reconstruction exercise rather than a live detection capability.

Key questions

Q: What breaks when AI agent detection starts with existing container and SIEM tools?

A: You miss the signals that live in prompts, tool calls, identity use, and delegation, so the attack path is fragmented before you ever reach correlation. The result is alert volume without causal reconstruction, which is not enough to distinguish normal agent work from abuse.

Q: Why do AI agent attacks require identity and orchestration telemetry, not just runtime logs?

A: Because the malicious behaviour often looks like legitimate execution until you compare the agent’s intended scope with what it actually exercised. Identity and orchestration telemetry expose the permission gap and the delegation path that runtime logs alone cannot explain.

Q: What are the signs that AI agent testing is too shallow?

A: If evaluation only checks refusal behaviour, overall benchmark scores, or end-to-end task success, it is probably missing the real attack surface. Shallow testing ignores whether the model can be pushed into tool misuse, data leakage, or indirect prompt injection at the exact decision point where failures occur.

Q: How should security teams design AI agent attack detection across multiple control planes?

A: They should assign each surface to the control plane that can actually observe it, then add a correlation layer that joins the evidence into one chain. Detection works when telemetry, baselines, and triage are designed together instead of bolted on separately.

Technical breakdown

The four surfaces an AI agent attack crosses

The article separates AI agent attacks into four surfaces: input and reasoning, tool invocation, identity and action, and cross-agent coordination. Each surface has a different signal type, from content provenance in prompts to behavioural envelopes in tool usage, declared-versus-observed scope in permissions, and graph behaviour in delegation. That distinction matters because the attack is not defined by a single malformed event. It is defined by how the agent’s own decision path is manipulated across stages that may each look legitimate in isolation.

Practical implication: Security teams should map each agent control to the surface it can actually observe, then close the blind spots with dedicated telemetry.

Why runtime telemetry has to be agent-aware

The framework argues that kernel-only visibility is insufficient because it strips away the prompts, tool calls, and orchestration decisions that explain why the runtime behaved as it did. eBPF can show process, syscall, network, and file activity, but it cannot explain the semantic trigger behind the action. Framework SDK callbacks and application-layer hooks supply that missing context by tying runtime effects back to the agent’s reasoning chain. Without that linkage, alerts may be accurate at the system level but useless for agent-specific detection.

Practical implication: Combine runtime signals with application-layer agent telemetry before you try to build detections or baselines.

Correlation is an architectural plane, not a SIEM feature

ARMO’s article treats correlation as a separate detection layer that assembles signals from multiple surfaces into one causal narrative. That is different from simply ingesting more logs into a SIEM. The core problem is that each source tool class was built for a different threat model, so the join logic must understand sequence, scope, and entity identity across the agent’s full action chain. If correlation starts at the wrong layer, the result is fragmented alerts instead of a coherent attack story.

Practical implication: Build a correlation plane that reconstructs agent actions across telemetry sources, rather than assuming your SIEM will infer the chain.

NHI Mgmt Group analysis

Agent attack detection fails when security teams confuse workload telemetry with decision telemetry. The article shows that the decisive signal is not where the container ran, but how the agent arrived at the action. That is a material shift for identity security because the attack path includes the agent’s prompt context, tools, permissions, and delegation behaviour. Practitioners should treat the agent’s decision surface as the security boundary, not the hosting environment.

The identity plane is now part of the attack surface for agentic systems. ARMO’s framing makes it clear that tool misuse and scope expansion are not just workload anomalies. They are identity-linked behaviours that only become visible when permissions are compared with actual exercised scope. That makes AI agent detection an IAM and observability problem at the same time, especially where per-agent identity tags are the only way to separate one agent’s behaviour from another’s. Practitioners should align identity telemetry with agent-specific baselines.

Surface-based detection is a better mental model than tool-based hardening. The article’s strongest insight is that no single control plane sees the full chain. WAFs, CNAPP, EDR, and SIEM each cover different fragments, but none can be assumed to understand the agent’s runtime intent. The named concept here is agent decision surface coverage: the degree to which a program observes the points where an agent ingests context, invokes tools, exercises identity, and coordinates with peers. Practitioners should measure coverage across surfaces before they measure control maturity.

Correlation should be judged by whether it reconstructs causality, not by how many alerts it collects. The article’s architecture places correlation after telemetry and baselining because sequence and context are what make an agent attack intelligible. That has governance implications: if the programme cannot explain the chain, it cannot reliably triage the incident or enforce the right containment boundary. Practitioners should make causal reconstruction the acceptance test for agent detection.

Multi-agent systems expose a governance gap that single-agent controls cannot close. The cross-agent coordination surface creates a path where one compromised agent can influence another through normal delegation patterns. That means the control problem extends beyond per-agent policy into graph-level trust and orchestration oversight. Practitioners should assume that delegation edges can carry malicious intent unless the coordination layer is explicitly instrumented.

What this signals

Agent decision surface coverage: AI agent security programmes should be measured by how much of the decision surface they can actually observe, not by how many tools they ingest. If prompts, tool calls, identity events, and delegation edges are not all represented, the programme is seeing workload noise rather than agent behaviour.

The immediate programme question is whether your current telemetry can reconstruct a causal chain without analyst reconstruction. If it cannot, then your SIEM is still acting as a log warehouse, not a detection plane. That gap matters because the agent may be doing exactly what it was instructed to do while still crossing an attack surface.

For practitioners

• Instrument the agent decision surface Capture prompts, retrieved context, tool calls, identity use, and orchestration events as first-class telemetry rather than relying on container logs alone.
• Build per-agent behavioural baselines Profile each deployment’s normal tool sequence, permission usage, and request patterns so unusual combinations stand out against that agent’s own envelope.
• Separate correlation from collection Create a dedicated join layer that reconstructs the attack chain across WAF, SDK, IAM, Kubernetes audit, and orchestrator telemetry.
• Treat delegation as a control point Track agent-to-agent handoffs and shared-context writes so malicious instructions do not disappear inside normal coordination traffic.

Key takeaways

• AI agent attacks cross multiple decision and execution surfaces, so a detection design that stops at containers or runtime logs will miss the actual abuse path.
• The article’s core evidence is architectural rather than incident-based: prompts, tools, identity, and delegation all need different telemetry to become visible.
• Practitioners should treat correlation as a dedicated detection plane and measure whether their stack can reconstruct the chain without manual stitching.

Key terms

• Agent Decision Plane: The layer where an AI agent chooses which tool to call, in what order, and for what purpose. It sits above cloud APIs, processes, and audit logs, which means conventional security tools may see the resulting action without seeing the decision that caused it.
• Surface-Based Detection: A detection approach that organizes telemetry around the attack surfaces an adversary must cross, rather than around the tool collecting the logs. For AI agents, this means aligning prompts, tool calls, identity events, and orchestration data so each surface contributes evidence to one attack story.
• Per-Agent Behavioral Baseline: A per-agent behavioral baseline is a reference profile of how one AI agent normally acts. It captures typical tool use, request patterns, timing, data access, and decision paths, then flags meaningful deviation. In identity security, it helps detect compromise, prompt injection, privilege abuse, or unintended autonomy in a specific agent runtime.
• Cross-Agent Coordination: Cross-agent coordination is the exchange of instructions, context, or work between multiple AI agents through an orchestrator or shared state. It becomes a security concern when a malicious instruction moves from one agent to another through a path that appears legitimate on both sides.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.