How should organisations decide whether AI agent telemetry belongs in the SIEM or security lake?

How to choose the right telemetry destination for agent logs

AI agent telemetry should be routed to the system where it will actually be used, not to the platform that sounds more “security mature.” If investigators rely on the SIEM for alerting and the security lake for deep correlation, the decision should follow that workflow. The important part is preserving the fields that make the data actionable: session linkage, command detail, timing, identity context, and outcome state.

That means the telemetry model matters as much as the storage target. A destination is only useful if the events are normalized, privacy-reviewed, and mapped so analysts can ask investigation questions without reconstructing the session from scattered logs. If the platform cannot support that level of retrieval, the organisation has moved data, not visibility.

When teams decide by default, they often confuse collection with utility. The better test is whether the telemetry can support detection rules, case triage, and post-incident reconstruction with enough fidelity to explain what the agent did, on whose behalf, and with what result. If the answer is no, the first problem is usually field design and retention logic, not SIEM versus lake.

Where SIEM fits, and where a security lake fits better

A SIEM is usually the right place for the subset of agent telemetry that drives active monitoring, correlation, and alerting. That includes high-value signals such as policy failures, unusual tool calls, privilege changes, rejected actions, and session anomalies that security operations will investigate quickly. Security lake storage is often better for broader or higher-volume telemetry that needs cheaper retention, flexible hunting, or cross-domain correlation outside the SIEM’s cost and schema constraints.

Think of the SIEM as the operational layer and the security lake as the analytical reservoir. The SIEM needs curated, normalized, low-noise records that support alert logic. The lake can hold richer context, longer histories, and additional raw detail, provided the organisation can still query it efficiently and tie records back to a specific agent session or workflow.

The choice also depends on how the agent is used. For agentic systems that can take actions, invoke tools, or chain steps over time, the security value is in the sequence, not just the event. That is why telemetry that captures session state, tool invocation, and final outcome often belongs in both places in different forms, with the SIEM receiving the investigation-ready subset and the lake retaining the deeper context.

What good telemetry design looks like in practice

Good routing starts with a field map, not a storage debate. Organisations should define a normalized event schema that preserves who initiated the action, which agent or session performed it, what tool or target was touched, what decision was made, and whether the action succeeded, failed, or was blocked. Without that minimum structure, neither the SIEM nor the security lake will produce reliable investigations.

Privacy controls should be applied before broad distribution. That usually means deciding which fields are sensitive, which need masking or tokenization, and which must be excluded from the SIEM entirely even if they remain available in a tightly governed lake. The practical goal is to keep enough context for defenders without turning every investigation query into a data exposure problem.

Retention should follow use case, not habit. If the telemetry is used for short-horizon detection, the SIEM may need only the most recent operational slice. If the same data supports forensic review, model abuse analysis, or trend hunting, the lake should preserve longer histories and richer raw detail. In both cases, the key question is whether the data remains interpretable after normalization and whether the joins needed for investigation are still possible.

Risk and Threat Considerations

Routing agent telemetry to the wrong platform can create blind spots or unnecessary noise. If the SIEM receives incomplete events, defenders may see an alert without the context needed to judge severity. If the lake is treated as a dumping ground, the organisation may retain massive volumes of low-value telemetry that is expensive to query and difficult to operationalize during an incident.

Failure mechanism: The most common failure is a split between raw collection and security usefulness, where privacy filtering, schema drift, or missing correlation IDs break the chain from agent action to analyst decision. That weakens both detection quality and forensic reconstruction, especially when agent sessions span multiple tools or systems.

Impact: Teams lose confidence in the data, investigations take longer, and suspicious agent behavior can blend into normal operational noise. In the worst case, an organisation retains telemetry that is too incomplete for detection and too sensitive for broad use, which delivers cost without control.

Practitioner Guidance

What to prioritise: Decide the destination after defining the investigation questions you expect the telemetry to answer. If security operations needs to alert on it, keep the normalized, queryable subset in the SIEM. If the data is mainly for hunting, trend analysis, or deep forensic review, preserve the richer record in the lake and index only the fields needed for search.

What to verify: Make sure every stored event can be tied back to a session, actor, action, and outcome. If analysts cannot reconstruct the sequence without cross-team help, the telemetry design is not ready for production use.

Practitioner takeaway: The destination is a secondary decision; the primary decision is whether the telemetry preserves enough context to support real investigations without overexposing sensitive fields.

Related resources from NHI Mgmt Group

• How do organisations decide whether to route security data to a SIEM, data lake, or AI system?
• How can organisations decide whether an AI agent belongs in PAM, IAM, or NHI governance?
• How should organisations decide whether AI agent access belongs in IAM or separate governance?
• How do organisations decide whether an AI agent security platform is effective?