Why sending agent logs to your SIEM is not AI governance
A SIEM is excellent at what it was built for: aggregating security telemetry at volume, correlating across sources, and alerting on patterns. What it receives from an AI agent, though, is events — this call happened, this record was read. Governance evidence has to answer a different question: why was this permitted, under which policy, on whose authority, and with what human involvement. That context has to be produced at the decision point, because it does not exist in the event stream.
Short answer
Keep the SIEM. It remains your detection and correlation layer. Add a governance record for the decision context it never receives, and stream that into the SIEM too.
Telemetry versus evidence
The distinction is between what happened and why it was allowed. A SIEM event says agent-14 read 4,000 customer records at 02:14. That is genuinely useful for detection: it is anomalous, it should alert, and correlation with other sources may reveal a wider incident.
It does not say which human the agent was acting for, which policy version was in force, whether the action fell inside the agent's declared scope, whether a human approved it, or what reason they recorded. Those facts existed at the moment the decision was made and were not carried into the log line, so no amount of downstream analysis recovers them.
The three gaps
Concretely, what a SIEM will not have for an AI decision:
- Authority. Which policy permitted this, and which version of it was live at the time.
- Principal. The human the agent acted for, as distinct from the agent itself.
- Oversight. Whether review was required, who performed it, and the recorded rationale.
Integrity is a different requirement too
SIEM data is generally treated as trusted because you operate the pipeline, which is appropriate for detection. Evidence has a stricter bar: the reader is a regulator or auditor who does not have to take your word for it, and the operator is the party with an incentive in how history reads.
That is what hash chaining addresses, and it is a property of how the record is written rather than where it is stored. Forwarding mutable events into a SIEM does not create it.
What we actually recommend
This is not an argument for replacing anything. Your SIEM stays where it is and continues to do detection and correlation, which a governance product should not attempt.
The addition is a decision record produced at the gate — identity, policy, authority, outcome — written to a tamper-evident trail and then streamed into the same SIEM alongside everything else. Your analysts keep one pane of glass; your auditors get evidence that a mutable event store cannot provide.
Side by side
| SIEM | Bulwark | |
|---|---|---|
| Purpose | Detection, correlation and alerting across sources | Proving an action was authorised |
| Record type | Events: what happened, when, from where | Decisions: what was permitted, by which policy, on whose authority |
| Captured at | After the fact, from emitted logs | At the decision point, before the action proceeds |
| Policy context | Not present in the event stream | Policy and version recorded with each decision |
| Human oversight | Not represented | Reviewer identity, verdict and recorded rationale |
| Integrity | Trusted because you operate it | Hash-chained; verifiable by a third party |
| Can block an action | No | Yes, at the gate |
Frequently asked
We already forward all agent logs to Splunk. What is missing?
The decision context. Your events record that actions occurred; they do not record which policy permitted them, which human the agent acted for, or who reviewed anything. That context has to be captured where the decision is made, because it is not recoverable from the event stream afterwards.
Can we not just log the extra fields ourselves?
You can, and some teams do. What you are then building is a policy engine, an approval workflow and a tamper-evident store — which is a real project with ongoing ownership, not a logging change. That is a legitimate build-versus-buy decision, but it should be made with the actual scope visible.
Does Bulwark integrate with our SIEM?
Yes, and that is the intended deployment. Decision records are exportable and stream into your existing pipeline, so detection stays where your analysts already work.
Is a SIEM enough for EU AI Act compliance?
For the oversight and evidence obligations, generally not on its own, because those require showing that a person could intervene and did, with a rationale, on a record whose integrity you can demonstrate. A SIEM holds none of those three by default.
Try the governance half
Agent registry, scope enforcement, human approvals and a hash-chained evidence trail you can verify without trusting us. Free Developer tier, 100,000 governed decisions a month, no card required.
Related
- AI governance vs AI observability: what the difference actually isObservability tells you what your AI did and how well. Governance tells you what it was permitted to do and proves it. Why teams need both.
- Bulwark vs LangSmith: different jobs, commonly confusedLangSmith is an LLM observability and evaluation platform. Bulwark is an agent governance layer. What each is built for and when you need both.