TL;DR: Raw logs alone leave SIEM workflows blind to who is acting, what they can access, and whether the resource matters, according to Exaforce. Modern detection needs shared identity, resource, and configuration context, or analysts remain the context engine and AI investigations inherit the same blind spots.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Exaforce's blog post: SIEMs become context-blind when they ingest events without the identity, resource, and configuration state needed to judge what those events mean.
Why it matters: For IAM, NHI, and security teams, the issue is that detections and AI investigations inherit the same blind spots if identity resolution, resource sensitivity, and app context are not modelled centrally.
Context
A SIEM can collect events at scale and still miss the meaning of those events if it does not know who or what generated them. The governance gap is not log volume, but the absence of shared entity context across identities, devices, applications, cloud resources, and API activity.
In this article's framing, context blindness is a security operations problem with a clear identity edge: without identity resolution, privilege state, and resource sensitivity, analysts are forced to act as the correlation layer themselves. That is typical of many mature environments, which still rely on manual joins between source systems.
Key questions
Q: What breaks when a SIEM relies on raw logs without entity context?
A: The SIEM can still show that events happened, but it cannot reliably tell whether they matter. Without identity, privilege, device, and resource context, analysts must reconstruct the story manually, and detections become noisy or incomplete. That gap is most dangerous when one actor appears under multiple identifiers across SaaS, cloud, and endpoint tools.
Q: Why does missing identity context make alert triage so much harder?
A: Because severity depends on who acted and what they could reach. An admin login, a contractor login, and a service account action may look similar in raw telemetry but carry very different risk. When the SIEM cannot resolve those differences, every alert needs extra investigation before it can be trusted.
Q: How do security teams know if context enrichment is actually working?
A: Look for fewer alerts that require five separate tools to explain, better separation between routine app activity and suspicious user action, and more consistent severity decisions for the same actor across sources. If the same event still needs manual identity and resource lookups every time, enrichment has not become operational context.
Q: What should teams do when AI is used for SIEM investigations?
A: Treat AI as a consumer of governed context, not a replacement for it. Give the model access to identity resolution, access posture, and resource sensitivity so its conclusions are grounded in evidence. If it only sees raw logs, it will reproduce the same blind spots that already limit human analysts.
Technical breakdown
Why raw SIEM logs do not equal security context
A log entry records that an action happened, when it happened, and sometimes from where. It rarely captures whether the actor is privileged, whether the target resource is sensitive, or whether the action matches prior behaviour. SIEMs can enrich events, but enrichment is only useful when identity, asset, and configuration data are current and linked. Without that shared model, detections remain event-centric rather than entity-centric, and analysts have to reconstruct meaning from multiple tools. The architectural issue is not correlation in the abstract. It is that the detection engine lacks the underlying state needed to decide what matters.
Practical implication: build detections around entity state, not isolated event fields.
How identity fragmentation breaks correlation across tools
Modern enterprise identities are split across IdPs, SaaS platforms, cloud roles, EDR, and service accounts. A single person can appear as several different identifiers, and a single action can be performed by a human or by an app acting under delegated access. If those identities are not resolved into one semantic record, a SIEM can miss the relationship between a compromised session in one system and exfiltration in another. The same problem affects NHI and workload identities, where tokens, OAuth apps, and service accounts can act with legitimate-looking access paths that only become visible when identity, privilege, and resource relationships are joined.
Practical implication: resolve human and non-human identities before writing cross-source detections.
Why AI investigations inherit the same context gaps
An AI agent that investigates alerts is only as grounded as the data it can reach. If it sees only raw logs, it will infer meaning from incomplete evidence and may produce confident but unsupported conclusions. A semantic layer or knowledge graph helps because it exposes relationships such as user to role, role to resource, and app to permissions. That does not remove analyst judgment, but it gives the model a structured view of the environment instead of a pile of disconnected records. In operational terms, the quality of AI-assisted triage depends on whether context is available at query time, not whether the model is persuasive.
Practical implication: give AI triage systems access to governed identity and resource context before trusting their conclusions.
Threat narrative
Attacker objective: The objective is to move through trusted access paths without triggering meaningful detection because the environment cannot join identity, privilege, and resource context.
- Entry begins with a routine login or application session that looks ordinary in isolation because the SIEM only sees a timestamped event and source IP.
- Credential or session abuse becomes harder to spot when the same actor is represented by multiple identifiers across SaaS, cloud, and device systems, allowing access to blend into normal activity.
- Impact follows when analysts miss that the actor can reach sensitive resources, so exfiltration, destructive action, or misuse is evaluated too late.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Context blindness is a detection governance failure, not a tuning problem. If the SIEM cannot tell who an event belongs to, what that actor can access, or whether the target matters, the workflow is structurally under-informed. The analyst is forced to compensate with manual lookups, which turns investigation effort into the control plane. The practitioner conclusion is to treat context availability as a core detection requirement, not a nice-to-have enrichment layer.
Identity resolution is now a SOC dependency. The same person, app, or service can surface under multiple usernames, cloud role sessions, OAuth grants, and device records. Without a unified identity model, detections cannot reliably distinguish routine access from abuse, especially when non-human identities act on behalf of users. The practitioner conclusion is that identity correlation must be designed as part of detection architecture, not bolted on after the fact.
Semantic modelling is the real gap between logs and decisions. A log line says an action occurred; a semantic model says who acted, with what privilege, against which resource, and under what configuration state. That is the named concept here: semantic context debt, the accumulation of missing entity meaning that pushes investigation work back onto humans. The practitioner conclusion is to reduce that debt before layering on more rules or AI.
AI in security operations only works when the environment is already intelligible. Agents do not fix broken context. They amplify whatever the detection stack can already explain, so incomplete identity and resource data become incomplete automated reasoning. The practitioner conclusion is to validate ground truth, lineage, and object sensitivity before delegating triage to AI.
Resource sensitivity must be part of the detection decision. An access event against a public bucket and the same event against a production backup store are not equivalent. If the SIEM cannot bind resource classification to the event, severity is guesswork. The practitioner conclusion is to model resource posture alongside identity posture so triage reflects business impact.
What this signals
Semantic context debt: the longer detection logic depends on raw logs alone, the more manual correlation work accumulates across the SOC. That debt shows up as repeated lookups, inconsistent severity, and slow triage, especially when identity and resource data are spread across separate tools.
For practitioners, the next step is not another detection rule but a model of who and what is acting. Once identity, privilege, and resource sensitivity are shared across the stack, AI-assisted triage becomes more credible and alert fatigue becomes easier to reduce.
For practitioners
- Model shared identity resolution Link IdP, SaaS, cloud, and device identifiers so analysts and detections can see one actor across multiple systems and sessions.
- Enrich alerts with resource sensitivity Attach classification, ownership, and access scope to cloud objects, files, and endpoints before routing them for triage.
- Normalize vendor event semantics Map source-specific login, session, and application events into a common model that preserves actor, method, outcome, and target context.
- Feed investigation outcomes back into detections Use analyst findings to update baselines, suppression logic, and risk state so future alerts reflect what has already been learned.
- Ground AI triage in governed context Give automation access to identity posture, access entitlements, and historical behaviour before allowing it to explain or rank alerts.
Key takeaways
- SIEMs that ingest events without shared identity and resource state can record activity but still fail to explain why it matters.
- The operational cost of context blindness is manual correlation across IdP, SaaS, cloud, and endpoint tools for every meaningful alert.
- Detection improves when context is modelled as governed state, because analysts and AI systems can then reason from the same evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The article is about detection quality and the limitations of event monitoring without context. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity, privilege, and entitlements are central to deciding whether activity matters. | |
| Recommendation — Use DE.CM-01 to ensure monitoring is tied to meaningful entity context, not just raw event volume. Map entitlements into detections so access decisions reflect who can do what, not just who logged in. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The article focuses on the analysis gap between collected logs and actionable interpretation. |
| IA-5 — Authenticator Management | The post highlights MFA posture and session trust as factors SIEMs must understand. | |
| Recommendation — Augment AU-6 workflows with governed context so analysts can review events with full entity meaning. Link IA-5 state to detections so authentication events carry current posture and risk context. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | API endpoints are treated as opaque URLs unless they are inventoried and modelled. |
| Recommendation — Inventory API endpoints and baseline their behaviour before relying on them in detections. | ||
Key terms
- Context Blindness: A control failure where inspection logic cannot distinguish a sensitive meaning from a harmless one because it relies too heavily on shape, token patterns, or isolated strings. In AI workflows, context blindness creates both missed detections and unnecessary alerts.
- Identity Resolution: Identity resolution is the correlation step that determines whether multiple accounts belong to the same person or accountable role. It combines identifiers, context, and system-specific attributes to reduce false splits and missed matches, which is what makes governance outputs dependable rather than approximate.
- Semantic Context: Semantic context is the broader meaning of code, including purpose, intent, dependencies, and how components work together. In application security, it helps distinguish harmful patterns from benign ones and exposes issues that purely structural analysis misses. It is essential for finding business logic flaws and reducing false positives.
- Knowledge Graph: A knowledge graph is a data model that stores entities and the relationships between them instead of treating records as isolated rows. In security, it helps teams explain how identities, permissions, tokens, and resources connect, which is essential for understanding access paths and risk propagation across SaaS and NHI environments.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps identity and security practitioners build the governance foundations that modern detection and response depend on.
Published by the NHIMG editorial team on September 16, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org