In this post I look at the main threats from agentic platforms, and how we can use the execution-layer telemetry we're getting from Claude to write detections for them. If you followed along with the last post , you will have closed the telemetry gap left by the Compliance API. Cowork, Claude Code, and the Office agents will now be streaming their execution-layer events (tool calls, MCP invocations, file paths and approval decisions), into your SIEM via OpenTelemetry. The Compliance API feed tells you what was said; the execution layer tells you what was done. In this post we look at detections that need both. Part 2 's detections read content and judged intent: W as this prompt a jailbreak? Was this upload a poisoned document? The detections for agentic attacks work the other way round. They read actions, and they ask a different question: Should this action have happened? In this order? Approved by whom? Why these detections are different The pattern to many agentic attacks of the last year is that they enter on the prompt surface but execute on the action surface. A poisoned document, a malicious GitHub issue, a rug-pulled MCP tool (approved once, then swapped for something malicious): the injection comes via conversation, but the damage happens in a tool call, a file write, or an outbound connection. As well as monitoring the conversation, you need to watch the execution layer to spot the malicious action happening. As with the detections I introduced in Part 2, none of this is groundbreaking. AI/LLM security has matured to the point where there are established frameworks that can guide us: The OWASP Top 10 for LLM Applications and the newer Top 10 for Agentic Applications define the risk classes. The OWASP MCP Top 10 covers the MCP protocol. MITRE ATLAS catalogues the techniques. We've also got plenty of real-world incidents to learn from now. The GitHub MCP exploit and the zero-click Copilot data leak ( EchoLeak ) prove the injection path works; the Amazon Q wiper and the Replit production-database deletion show how much damage a tool can do when nobody is watching it. Simon Willison's "lethal trifecta" explains why these keep happening: when an agent has all three of private data, untrusted content, and a way to send data out, an attacker who controls the content can use the other two to leak it. We can use this knowledge, and our full Claude telemetry, to write detections that catch these agentic attacks in practice. Expanding our pipeline Note : We're going to be expanding on the pipeline I introduced in Part 2 of this series. If you haven't already, go and read the post, and look at the repository . You will need to have an understanding of this pipeline and the LLM judge concept to implement these changes. From Part 2, we have our prefilter-and-judge pipeline. The judge sits as a gateway to the SIEM on purpose: chat content is large and sensitive, so we do minimal processing outside the SIEM and let only verdicts through. The execution-layer events coming via OpenTelemetry are small, structured and low-sensitivity, and the attacks that matter are sequences of events, not single messages. We can send these straight into the SIEM and do the work there, many of them possible with SIEM correlation alone. This lets us keep the same framework as the ingestion pipeline we've already established, just with a few additions: The full Claude telemetry picture. The Compliance API and OpenTelemetry both feed the SIEM: chat content is prefiltered and judged on the way in, while execution-layer events stream straight in to be detected on there. Execution events stream into the SIEM. They don't pass through the prefilter and judge pipeline, they land as raw events. Most detections run inside the SIEM. Single-event rules (a permission bypass, a connection to an unsanctioned server, a destructive command) are simple, and can be expressed in any SIEM, our examples use Sigma to stay vendor-agnostic. The agentic attacks require stateful correlation: a series of individually-authorised events that only looks malicious in order, correlated on prompt.id and session.id . The biggest difference comes when an execution-layer detection flags something that needs an intent judgement a rule can't make: it has to use the judge, the same one the content detections use. We can reuse that judge, but we have to call it from the SIEM: Execution events land in the SIEM; a correlation match calls the judge, which reaches back to the content to read intent. Execution events do not contain the content the judge needs, so a resolver fetches it from the Compliance API via the shared IDs and hands it to the judge, which returns a verdict. There is still only one judge. Previously, the content pipeline pushed work to it; here the SIEM pulls. You'll need an automation layer or SOAR to call the judge from your SIEM. The agentic threats to detect Now we get to the fun bit. I have grouped the detections into five threat families. For each I wi...