TL;DR: Security architecture should place detection, hunting, and investigation workloads where latency, state, and data dependencies fit the job, according to AiStrike's analysis. The practical shift is away from treating storage location as the main design choice and toward separating execution from retention, which is especially relevant as agents increase query volume and control-plane load.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AiStrike's blog post: Security telemetry architecture should separate where data is stored from where detection and investigation logic executes.
Why it matters: It matters because IAM, SOC, and cloud security teams increasingly need to place detection and hunt workloads based on latency, state, and dependency requirements rather than storage convenience alone.
Context
Security telemetry architecture breaks down when teams treat storage location as the main design decision instead of asking what each workload needs to do. Detection, hunting, and investigation are related, but they have different timing, state, and dependency profiles, so they should not all be forced through the same execution model. The identity angle is real here because modern detection and investigation increasingly touch authentication events, service accounts, and agent-driven workflows.
The article contrasts centralized storage, federation, and hyper-indexed object storage as different answers to the question of where telemetry should live. Its core point is that the right place to run security logic depends on the workload, not on a legacy assumption that all useful analytics must sit beside the data.
Key questions
A: Use the workload's timing and state requirements. If the decision must evaluate every event, maintain per-entity state, or act within milliseconds or seconds, run logic close to the source. If the work is retrospective and can tolerate slower execution, centralized storage is usually the better fit.
Q: Why does federation create risk for security telemetry workflows?
A: Federation turns source-system behaviour into part of the control plane. Retention limits, schema drift, API quotas, and temporary unavailability can all make a query incomplete even when it returns a valid answer. That is acceptable for some hunts, but dangerous for live detections that assume full coverage.
Q: What breaks when streaming detections are treated like search queries?
A: Polling creates gaps, overlapping windows, duplicate evaluations, and delayed responses that undermine continuous detection. A streaming detector needs stateful evaluation as events arrive, not repeated snapshots of a changing dataset. When teams misuse search for detection, they often lose the very timing guarantees the control was supposed to provide.
Q: When should teams keep telemetry centralized instead of federating it?
A: Centralize telemetry when completeness, long retention, and historical correlation matter more than source locality. That is especially useful for hunts, retroactive detections, and investigations that need one consistent query model across many months of data.
Technical breakdown
Why detection logic is not the same as search
Detection logic and search queries use different execution models. A detection may maintain state across a stream, evaluate every event as it arrives, and return an answer within seconds or milliseconds. Search starts after the question is formed and can tolerate slower execution because the result is still useful even if it arrives later. That difference matters in security telemetry because a streaming rule is not just a query over history, it is a continuously running decision process.
Practical implication: place streaming detection where latency and state can be controlled, not where historical storage is most convenient.
How federation changes telemetry dependencies
Federation keeps telemetry in source systems and queries those systems when needed, which avoids making a second copy. The trade-off is that the query inherits every source dependency, including retention limits, schema differences, API behavior, and rate limits. For retrospective work that may be acceptable, but for security logic that expects stable completeness and predictable latency, the dependency chain becomes part of the control surface.
Practical implication: treat source-system availability and API limits as part of the detection architecture, not as an afterthought.
Why hyper-indexed object storage changes the centralisation trade-off
Cheap object storage, compression, and better indexing have weakened the old cost argument against centralization. Historical telemetry can now sit in low-cost storage while the query layer handles search over large datasets more efficiently. That does not eliminate federation, but it does make centralized historical analysis and retrospective detection more practical than it was when SIEM-era ingest costs dominated design decisions.
Practical implication: re-evaluate whether expensive federation is still justified when indexed historical storage can preserve access without keeping every source live.
NHI Mgmt Group analysis
Execution placement is now a governance decision, not a storage afterthought. Security teams have spent too long treating telemetry placement as the primary architecture choice, when the real question is where the workload can execute correctly. Detection, hunt, and investigation should be separated by timing, state, and dependency profile, because those characteristics determine whether a control is operationally credible. Practitioners should treat workload placement as part of security governance, not just data engineering.
Security logic should move toward the event source when the decision is time-sensitive. A streaming rule, per-entity threshold, or enforcement-adjacent decision cannot wait for central collection if the latency budget is only seconds or milliseconds. That does not mean every event must be centralized first. It means the control should run where the answer can be produced in time to matter. Practitioners should design for local evaluation where timing is the limiting factor.
Historical analysis and live detection are different control problems. Retroactive hunt work benefits from long retention, complete history, and query flexibility, while detection benefits from stateful evaluation and predictable execution. Conflating them creates architectures that are good at neither. The stronger model is a split one: local or distributed execution for live logic, centralized history where retention and completeness matter. Practitioners should architect these as separate controls with separate success criteria.
Agentic investigation will magnify control-plane pressure unless query volume is governed. When software can issue hundreds or thousands of investigative queries, federated designs inherit API quotas, concurrency limits, and third-party variability as operational constraints. That is an identity-adjacent issue as well, because the actors driving query load may be automated investigators or security agents acting on behalf of analysts. Practitioners should assume that autonomous query generation changes the economics of telemetry access.
Detection health becomes an access and execution problem when AI agents enter the workflow. If agent-driven investigation depends on remote systems, then rate limits, retention gaps, and schema drift are no longer background issues. They become control failures that shape what the security system can see and how fast it can react. Practitioners should govern the query plane with the same discipline they apply to the data plane.
What this signals
Telemetry execution is becoming a control-plane design problem. As detection logic moves closer to event sources, teams need to define which decisions can run locally and which must remain centralized for governance, retention, or evidence handling. That split matters most where identity events, cloud activity, and agent-driven workflows converge.
Autonomous investigation changes the cost model for security operations. AI agents can amplify query volume fast enough to expose quota, concurrency, and schema assumptions that were invisible under human analyst usage. For practitioners, the question is no longer only where the data lives, but how much remote dependency the investigation plane can safely absorb.
For practitioners
- Split streaming detection from retrospective hunting Run streaming detections close to the event source when low latency and stateful evaluation are required, and reserve centralized storage for hunts that can tolerate slower execution.
- Document source-system dependencies in federated workflows Track retention periods, schema drift, API behaviour, and rate limits for every federated telemetry source so analysts can tell a complete miss from an incomplete query.
- Reassess centralization economics for historical telemetry Compare the cost of indexed object storage and query acceleration against the operational limits of federation before deciding that telemetry must remain distributed.
- Govern agent-driven query volume Set concurrency and quota controls for automated investigation workflows so agent activity does not turn remote telemetry access into a control-plane bottleneck.
Key takeaways
- Security telemetry architecture should be designed around the workload's latency and state requirements, not around storage convenience.
- Streaming detections, retrospective hunts, and agent-driven investigations place different demands on telemetry systems, so one execution model will not fit all.
- The strongest operating model separates live decision logic from historical retention, then governs federated dependencies and query volume accordingly.
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 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Telemetry access and query placement affect who can reach security data and how it is used. |
| Recommendation — Apply PR.AA-05 to govern access paths for telemetry, queries, and automated investigation workflows. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The article centres on how security teams review and analyse telemetry across live and historical contexts. |
| SC-7 — Boundary Protection | Federation and source-local execution both depend on clear trust boundaries between systems. | |
| Recommendation — Use AU-6 to separate continuous detection logic from retrospective review and reporting duties. Apply SC-7 to control cross-system telemetry access and constrain remote query paths. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The article is fundamentally about collecting, retaining, and querying security telemetry. |
| Recommendation — Use CIS-8 to define how telemetry is collected, retained, and made searchable across environments. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | The article discusses detection and investigation logic used to find adversary activity across systems. |
| Recommendation — Map telemetry coverage to TA0007 and TA0008 so detections support discovery and movement analysis. | ||
Key terms
- Federated telemetry: Telemetry that remains in the systems where it was created and is queried there instead of being copied into a central repository. This reduces duplication but shifts dependency, completeness, and latency risks onto the source systems and their APIs.
- Streaming Detection: Streaming detection evaluates events while they are still in motion through the pipeline instead of waiting for them to be indexed in a SIEM. That reduces latency, shortens mean time to detect, and can make alerting less dependent on a single downstream analytics platform.
- Retrospective Hunting: Retrospective hunting is the process of searching historical telemetry for evidence that a known threat or indicator was present earlier in the environment. For NHI incidents, it is essential because compromised software can leave behind access, execution, or credential artefacts long before detection occurs.
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a shared control model for the identity layer that underpins telemetry, automation, and access decisions.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org