You're on the list! We'll reach out when early access becomes available.
Oops! Something went wrong while submitting the form.
×
Your security stack logs almost everything. The one thing it cannot reconstruct is the decision an agent made, and why it made it.
Every security team we talk to runs on the same quiet assumption: if something happens in the environment, the SIEM caught it. That assumption has held up for fifteen years. Endpoint, network, identity, cloud, and application logs all flow into one place, get correlated, and an analyst can pull the thread when they need to.
Then you put an AI agent in production, and the assumption quietly breaks. Not because the SIEM is misconfigured, and not because your team missed a parser. It breaks because the agent operates in a layer the SIEM was never wired to see.
A SIEM is an event engine. It ingests logs, normalizes them, and correlates by the fields they share: host, user, source IP, timestamp. A process spawned here. A login from a new country there. A file written to a sensitive path. The model underneath all of it is the same: discrete events, attributed to an identity, joined on common keys. For the world it was built for, that model is excellent and still load-bearing.
The trouble is that an agent does not produce that kind of event.
An agent run is not an event. It is a session. A prompt and some retrieved context go in, the model reasons over them, it calls tools, it invokes MCP servers, it takes actions against your systems, and sometimes it hands off to another agent. The security-relevant unit is the entire run, not any single line of it.
By the time that behavior reaches the layers your SIEM watches, it has been flattened into ordinary authenticated activity. A coding agent running git commands. A service account calling an internal API. A bot writing a file. Every one of those is a clean log line. The reasoning that produced it, and the instruction that shaped that reasoning, never touch a log your SIEM receives.
That gap shows up in three specific places.
Picture a triage bot wired into a repository. An attacker opens issue number seven, and the body of the issue contains instructions instead of a bug report. The agent reads the issue, follows the instructions, installs a git hook for persistence, and sends a token to an external host.
Here is what the SIEM sees: an authenticated bot used the GitHub API and ran a few git commands. Here is what happened: a stranger on the internet handed your agent a new set of orders and it complied. There is no log line for the second version, because the cause lived in the model's context window, and the context window is not a data source you forward. The instruction that drove the whole incident is the one artifact the SIEM never gets.
Real agent attacks are rarely one bad action. They are a sequence where each step is boring on its own. Read a document. Summarize it. Call a tool. Fetch a URL. Write a file. Five unremarkable actions, all performed by the same well-behaved service account.
Your SIEM correlates by host and identity, so that is exactly what it reports: five normal actions by a normal principal. It has no concept of the session that strings them together, and no way to see that step two poisoned step five. The attack is a path through your environment. The SIEM stores a pile of points. You cannot reconstruct the path from the points when the thing that connects them was never recorded.
Agents run on real credentials. A service account, a non-human identity, a user's delegated token. So when an agent does something harmful, the identity layer sees a legitimate principal doing legitimate-looking things.
A simple version: a developer, or a coding agent acting on their behalf, installs lagnchain instead of langchain. The typosquatted package runs a postinstall script that reads environment variables and beacons them out. To your identity and endpoint tooling, an authorized user ran a package manager and made an outbound connection. Nothing to alert on.
The MCP version is worse, because the SIEM does not even have a vocabulary for it. An agent calls an MCP tool, and the tool's response carries injected instructions that the model then follows. There is no field in your SIEM for "MCP tool call," let alone "MCP tool response that contained a hidden instruction." That entire exchange happens below its line of sight.
The pattern across all three is the same. An agent with the right credentials can still do the wrong thing.
Identity tells you who. It does not tell you what, or why.
This is structural, not a tuning problem
You cannot write a correlation rule for a model deciding, on its own, to follow an instruction that was never meant to reach it. The telemetry that rule would need is not being produced. Logs give you flat event streams. Agent attacks are paths through a living system of agents, tools, identities, and data. Different shape, different data structure, and you cannot query one as if it were the other.
It helps to say plainly where each tool sits. EDR watches the device. CASB watches the cloud applications. Your identity provider watches who the agent is. All three are necessary, and none of them is the problem. The point is that none of them watches what the agent does as it moves across those boundaries, or why it did it. That space in the middle is where agent risk actually lives, and it is unowned in most stacks today.
The attacks are not hypothetical. Anthropic's threat intelligence team has documented adversaries using AI agents to run end-to-end intrusion campaigns, and over a recent reporting window it banned more than 800 accounts tied to nearly 14,000 logged malicious actions that touched all fourteen tactics in the MITRE ATT&CK framework. One detail from that work is worth sitting with: there is still no ATT&CK category for agentic orchestration itself. When the standard map of attacker behavior has no box for the thing that is happening, that is a fair sign the defensive frameworks are running behind the offense. Gartner, separately, expects roughly a third of enterprise applications to include agentic AI by 2028, up from close to none in 2024. The surface is arriving faster than the visibility.
If the unit of the attack is the session, the unit of visibility has to be the session too.
In practice that means capturing the full run: the inputs and retrieved context that shaped the reasoning, the tool calls and MCP invocations that resulted, and the downstream actions that hit your systems. Then it means correlating all of that into one structure, so you can start from any harmful action and pivot back to the human, the intent, and the scope that authorized it. When the underlying data is a graph instead of a log stream, the multi-step attack that was invisible as five separate events shows up as a single anomalous path. The thing the SIEM could not assemble becomes the thing you read off directly.
This is detection and response at the agent layer. It sits next to your SIEM, not on top of it. The SIEM stays the system of record for the rest of the estate. The agent layer answers the one question the SIEM structurally cannot: what did this agent do, and can I trust it?
None of this is an argument to rip out your SIEM. It is an argument to notice that agents introduced a new layer of behavior into your environment, and that layer needs its own visibility before it becomes the layer attackers prefer. The teams getting this right are not waiting for an incident to reveal the blind spot. They are instrumenting the agent layer now, while the number of agents they run is still countable.
That is the problem we are building Metano to solve: runtime visibility, context, and control for the agents already running across your endpoints, cloud, and SaaS. Want to learn more about what we are building? Reach out to us at info@metano.ai