Notifications
Clear all
Topic starter
14/09/2026 10:09 am
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.
NHIMG editorial — based on content published by AiStrike: Ship the Logic, Not the Data
Questions worth separating out
Q: How should security teams decide where detection logic should run?
A: Place detection logic where its timing, state, and dependency requirements can be met.
Q: Why does federation create risk for security investigations?
A: Federation makes investigations depend on source-system retention, availability, schema consistency, and API behavior.
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.
Practitioner guidance
- Separate streaming detections from retrospective hunts Classify each security use case by latency tolerance, statefulness, and evidence depth, then place streaming detections near the event source and reserve centralized history for retrospective search.
- Map federated dependencies into the security control plane Inventory source-system retention, schema behavior, API quotas, and export limits before allowing federation to support investigations or detections.
- Adopt execution-plane separation for identity telemetry Keep authentication, service-account, and agent activity signals available for local or near-source evaluation when response timing matters, while retaining searchable history centrally where practical.
What's in the full article
AiStrike's full blog covers the operational detail this post intentionally leaves for the source:
- The article's deeper comparison of centralization, federation, and hyper-indexed object storage across security workloads.
- Practical examples of where detection should execute at the event source versus where historical hunts should run.
- The discussion of how agent-driven investigation changes query volume, cost, and external dependency management.
- The operational failure modes of each architecture, including completeness gaps, parser issues, and API limitations.
👉 Read AiStrike's analysis of why security architecture should follow the workload →
Detection versus hunt workloads: where should security logic run?
Explore further
14/09/2026 10:10 am
Security telemetry architecture is becoming a workload-placement problem, not a storage problem. The old model assumed that once data was centralized, analysis should follow automatically. This article shows that detection, hunting, and investigation have different execution requirements, so governance now has to distinguish between where data lives and where logic should run. For identity programmes, that means workload identity, access review, and security monitoring cannot all be treated as the same analytical class.
A question worth separating out:
Q: How do security teams balance centralized history with federated access?
A: Use centralized indexed storage for datasets that are practical to collect, normalize, and retain, then reserve federation for sources that cannot be exported well or should stay in place for legal, technical, or operational reasons. The right model is usually mixed, with each workload matched to its own execution point.
👉 Read our full editorial: Ship the logic, not the data for security telemetry workflows
