What Your SIEM Cannot Tell You About an Agent's Week
We could not find a published number for how many teams can reconstruct what their agents did last week. Here is what a proxy log holds that a SIEM does not.
- Measured: 40 of 47 payloads, our own corpus
- Not measured: latency
- Observed, not governed: hosted MCP tool calls
A security team can usually say which agents are deployed. Reconstructing what one of them did last week is a different question, and it is the one this post is about.
The visibility gap
We could not find a published number for how many teams have centralized visibility into agent actions, policy enforcement or an audit trail. What follows is the pattern we keep meeting, not a survey. The security team knows that agents exist in production. It does not know what tools those agents can reach, what decisions they are making, or why. When someone asks who ran that database query, the answer is usually that nobody is sure.
None of the teams we have shown this to could list the tool calls their agents made last week. That is an anecdote from the rooms we have been in, not a survey.
Why the gap is widening
Three things changed. Teams deploy agents independently, because any developer can start one with the SDK. There is no standard way to track agent identity or log agent actions. And the SIEMs we have looked at track human users and service accounts, not tool calls.
The result is action-layer invisibility. You can watch network traffic and API calls at the transport layer. You cannot see which tool the agent asked for, what it carried, or what was decided about it.
What visibility means for agents
It is one row per tool call the proxy sees, written before the agent runtime can act on that call. It is not a live feed: a streamed response is buffered in full before it is judged, and there is no escalation step to record. The row answers these questions:
- What tool did this agent try to call?
- What did it carry (file path, database name, resource id)?
- Was the call allowed, denied or observed?
- Which rule matched?
Monitoring tells you what happened. Governance decides what runs. You need both.
Closing the gap
Start with an inventory: which agents are in production, what models they run, what tools they can reach, who owns each one. Every team we have watched do it found more agents than it expected. That is what we have seen, not a study.
Then route agent traffic through a control point. The agent talks to a proxy instead of talking to the LLM API directly. The proxy reads the model's response, inspects the tool calls in it, applies policy, and once enforcement is on, takes a denied call out of the response before the agent runtime can execute it.
Then keep the record. The row holds the agent identity, the tool, a short excerpt of what it carried, the policy that matched and the verdict, and the agent process cannot write to it. It is timestamped and hash-chained per tenant: tamper-evident, not tamper-proof.
Do those three and you can answer what the agent did. That is the floor, not the product.
Why it matters now
An agent is not confined to one process or one service account. It interprets a goal, generates a command and calls a tool, and it does that at machine speed. The gap that matters is the one between having governance and believing you have it, and it closes when you can answer what the agent did.
What Intercis does not govern
Intercis judges the tool calls that cross the Anthropic and OpenAI API wire. When a hosted MCP server runs a tool for the model, that call has already run by the time the response reaches the proxy, so it is observed, not governed: it writes one observe row and is never judged or blocked. Being in path is also a configuration setting: a process that can change its own base URL can route around the proxy unless network egress control forces the traffic through it.