TL;DR: Security operations still treat SIEM centralization as a prerequisite for investigation, but Query argues that the real requirement is access to distributed data, not moving everything into one platform first. That shift matters because AI only accelerates the same coverage gaps when it reasons over incomplete telemetry.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Query's blog post: Security operations inherit a centralization assumption that no longer matches how investigation data is distributed across modern estates.
Why it matters: Practitioners need to design SOC data access around investigation outcomes, because centralizing every source first can leave critical telemetry unavailable when analysts or AI systems need it most.
Context
Security operations still begin with a governance assumption rather than a technical necessity: that effective investigation requires every source to be centralised before it can be queried. That assumption made sense when storage, bandwidth and cross-system search were constrained, but it is weaker in environments where telemetry already lives across endpoint, identity, SaaS and cloud systems.
The core issue is not whether a SIEM exists, but whether analysts and automation can reach the evidence they need without forcing every log line into one repository. security data mesh thinking challenges the inherited model by separating access to data from wholesale centralisation, which is a more realistic lens for modern investigation architecture.
Key questions
Q: Why does SIEM centralization create blind spots in SOC coverage?
A: SIEM centralisation creates blind spots when only selected logs are forwarded, source systems have local detections that are not ingested, or volume limits force filtering before analysis. Once telemetry is reduced to a central pipeline, the SOC can miss raw context, delayed events, and data from environments with weak connectivity or incompatible formats.
Q: What does this mean for agentic AI governance in security operations?
A: Teams need to govern how the agent forms and carries belief about the world, not only what outputs it produces. That includes confidence handling, auditability of state changes and decision consistency under incomplete evidence. If the agent cannot explain its uncertainty clearly, the programme should treat that as a governance gap, not a tuning issue.
Q: What is the difference between centralised logging and federated investigation?
A: Centralised logging copies events into one repository for storage, search, and alerting, while federated investigation queries multiple telemetry sources in place and correlates results across them. Centralisation simplifies retention and indexing, but federation preserves local context and can cover distributed clouds, endpoints, and applications without requiring every event to be duplicated centrally.
Technical breakdown
Why distributed telemetry broke the old SIEM model
Centralised logging became dominant because it solved a 2005-era problem: distributed systems were hard to query, bandwidth was costly, and normalisation across sources was slow. A SIEM concentrated data so analysts could search one place, correlate events and build detections without stitching together multiple systems in real time. That architecture was a pragmatic response to the limits of the time, but those limits are no longer the whole story. The underlying mechanism has not changed, though. A central platform still only sees what was ingested, so coverage is bounded by collection decisions rather than by the actual estate.
Practical implication: Design investigation paths around source access and federation, not only around ingestion into a central platform.
How incomplete ingestion creates blind spots in investigations
An investigation is only as complete as the context it can reach. When identity, endpoint or cloud telemetry never enters the SIEM, the analyst gets a technically sound but structurally incomplete picture. The danger is not just missing evidence, but misreading absence as safety. If a command-and-control beacon appears in endpoint telemetry but is not visible in the main analytics layer, the SOC may conclude nothing happened. This is a data architecture failure, not a detection rule failure, because the signal exists somewhere but is outside the investigative boundary.
Practical implication: Map your highest-value telemetry sources and verify they remain queryable even when they are not fully ingested.
Why agentic AI amplifies data architecture gaps
AI-driven investigation does not remove the dependence on data access. An agent can reason only over the sources it can reach, whether that is a SIEM, an endpoint platform or a cloud control plane. That means AI can speed up analysis, but it cannot recover evidence that was never made available to it. The architectural risk is mistaken confidence: teams may assume automation has closed the visibility gap when it has only processed a narrower slice of the environment faster. The smarter the agent, the more obvious the missing-data problem becomes.
Practical implication: Treat AI-enabled investigation as a consumption layer, not as a substitute for evidence coverage.
NHI Mgmt Group analysis
Centralised investigation has become a coverage constraint, not a control objective. The historic reason for SIEM centralisation was operational efficiency in a lower-bandwidth, lower-scale era, but that rationale no longer justifies treating ingestion as the only route to usable evidence. Modern estates spread identity, endpoint, SaaS and cloud telemetry across different systems, so a single repository can never be the whole investigative surface. Practitioners should judge the architecture by evidence reach, not by log volume.
Data access density is a better operating concept than log hoarding. The useful question is not how much data an organisation can store centrally, but how much high-value data it can query when an investigation starts. That shifts the conversation from raw ingestion to fit-for-purpose retrieval, correlation and retention across source systems. For identity and security programmes, this is especially important where identity providers and cloud control planes hold decisive context that a SIEM may never see in full. Practitioners should optimise for investigative utility, not repository size.
AI does not repair missing evidence, it only speeds up what the model can already reach. Query is right to challenge the assumption that agentic tooling solves the SOC coverage problem by itself, because any AI layer inherits the same upstream data boundary. If the system cannot access the right telemetry, the output is faster analysis of an incomplete picture. That makes data architecture a prerequisite for trustworthy automation. Practitioners should evaluate AI security tooling by the reach of its evidence, not the speed of its interface.
Security operations now need governance over evidence placement, not just alerting outcomes. The next maturity step is to decide which classes of telemetry belong in central analytics, which should remain federated, and which must stay queryable at source for investigation and response. That is a governance question as much as a technical one, because the SOC’s effective scope is defined by data access policy. Practitioners should build for distributed observability with explicit investigative pathways.
What this signals
Investigation architecture is shifting from consolidation to reachability. Security leaders should expect the next wave of SOC design to be judged by whether analysts and AI can access the right evidence in place, not by how much telemetry is duplicated into a central stack.
Evidence boundaries will become a governance issue. As automation becomes more capable, the sharper risk is not tool failure but incomplete data access, especially where identity and cloud control-plane signals sit outside the main analytics path.
For practitioners
- Define evidence reach targets Set minimum investigative coverage for identity, endpoint, SaaS and cloud telemetry so the SOC can prove what it can query without assuming everything must be centralised.
- Classify telemetry by investigative value Separate high-value data that must remain queryable at source from low-value logs that only justify expensive central ingestion.
- Test AI against missing-data scenarios Run investigations where key evidence stays outside the SIEM and measure whether automation still reaches a defensible conclusion.
- Map cloud and identity control-plane visibility Verify that identity provider events, cloud control plane logs and endpoint telemetry are reachable during incident response, not just retained somewhere in the estate.
Key takeaways
- Security operations can no longer assume that centralised storage is the same thing as usable investigative coverage.
- The main failure mode is incomplete evidence access, which can make a real signal look like no signal at all.
- The next design choice is architectural: decide which data must be centralised and which must simply remain queryable when analysts or AI need it.
Related NHI Mgmt Group resources: OpenSSF OSPS Baseline Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Distributed telemetry visibility depends on knowing where security data resides across the estate. |
| DE.CM-01 — The organization monitors the network and physical environment to detect anomalies and events | The article is about monitoring coverage and what happens when data never reaches the detection layer. | |
| Recommendation — Inventory telemetry sources and keep source-of-truth records for where investigative evidence lives. Measure detection coverage across source systems, not only inside the central analytics platform. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The problem centres on what gets logged, retained and made available for investigation. |
| Recommendation — Define logging requirements by investigative value and ensure critical sources remain accessible. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The article challenges how organisations collect and use logs for security operations. |
| Recommendation — Use log management to support investigation access rather than treating ingestion volume as success. | ||
| MITRE ATT&CK | TA0006;TA0009 — Credential Access; Collection | Hidden telemetry can conceal the collection and access stages that analysts need to reconstruct. |
| Recommendation — Map blind spots to credential access and collection gaps in your threat hunting workflow. | ||
Key terms
- Security Information and Event Management (SIEM): SIEM is a security control that centralises event collection, correlation, and alerting so analysts can monitor suspicious activity. It is useful for visibility and detection, but it often produces large volumes of alerts and usually needs enrichment and response automation to become operationally effective.
- Security Operations Center (SOC): A Security Operations Center is the team and operating function responsible for monitoring, detecting, investigating, and responding to security events. In this context, the SOC is the primary environment where orchestration and automation are used to improve speed, consistency, visibility, and analyst efficiency.
- Endpoint Telemetry: Endpoint telemetry is the process and event data collected from managed devices to understand local activity. For shadow AI, it includes process spawns, file access, and direct outbound calls from the operating system, giving security teams visibility that network tools and SaaS logs often miss.
- Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme needs a grounded view of machine identity, access control, and governance across modern environments.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org