Your SIEM knows that eventType: user.session.start happened at 14:32:07 UTC from IP: 203.0.113.42. That log line alone doesn’t establish that the user is your VP of Engineering, that she’s an admin in six SaaS applications, or that she doesn’t have strong MFA on two of them. It doesn’t establish that the IP belongs to a VPN provider your organization has never seen before, that she was in New York an hour ago, or that the S3 bucket she’s about to access contains your production database backups.
A SIEM sees a log line. A security analyst needs to see a story.
That gap between what your tools ingest and what your team needs to act is where modern threats can slip through. This post is about why that gap exists, what’s structurally wrong with a SIEM workflow built around logs alone, and what it takes to close it.
The Core Problem: Context Blindness
The limitation we’re concerned with isn’t performance, cost, or query language. It’s whether a SIEM knows what the entities in its logs are.
A SIEM ingests logs: timestamped records of events. But the entities involved in those events — people, devices, API endpoints, code repositories, cloud storage buckets, SaaS applications, Drive files, service accounts, OAuth tokens — have properties, relationships, history, and security posture. Ingesting their events doesn’t capture all of that context.
SIEMs can enrich events, correlate identities, and learn behavioral baselines. The question is how much work your team must do to make that context consistent, current, and reusable across detections.
Consider the entities and relationships in a typical enterprise:
- Identities: employees, contractors, service accounts, API keys, OAuth apps
- Devices: laptops, servers, containers, Kubernetes nodes, mobile phones, plus which user owns which device, learned from mobile device management (MDM) enrollment and identity provider (IdP) configuration
- API endpoints: the hundreds of internal and external APIs your services expose
- Code repositories: your source code, who has access, what changed
- Cloud resources: S3 buckets, Identity and Access Management (IAM) roles, compute instances, databases
- SaaS resources: Google Drive files, Slack channels, Jira projects, Okta applications
- Network context: firewall zones, proxy policies, DNS domains
Every one of these has configuration, permissions, relationships, and a behavioral history. And the relationships between them are just as important as the things themselves. Knowing from MDM records that Device X belongs to User Y lets you connect a phishing email received by Y to the malware that appears on Device X three minutes later. Without that user-to-device mapping, those events appear unrelated, in separate log streams.
When a SIEM receives a log line saying user X accessed resource Y, the line alone doesn’t establish whether X is an admin or an intern, whether Y contains PII or marketing collateral, whether X has ever accessed Y before, or whether X’s device has a healthy EDR agent.
When those connections are missing, the result is context blindness. And it’s a root cause of the investigation work a SIEM leaves to your team.
What Context Blindness Costs You
1. Every Alert Needs Context
When a SIEM fires an alert for “login from an unusual location,” a thorough analyst’s first move may be to open five other tools. Who is this user? What’s their role? Are they an admin? Do they have MFA? What device are they on? Is the device compliant? What did they do after logging in?
The login event alone can’t answer all of these questions. Without that context, the SIEM can tell you what happened but not whether it matters. An admin logging in from an unusual country is a very different situation from an intern doing the same thing. But a rule that doesn’t account for their roles can fire the same alert for both, with the same severity.
The analyst reconstructs the missing context manually, across multiple tools, alert after alert. That repeated work has a structural cause: the tool that detects threats lacks the information needed to assess them.
2. Identities Are Fragmented
A single person in your organization might be:
jane@acme.comin Oktajane.doein GitHubU08ABCDEFin Slackarn:aws:sts::123456789012:assumed-role/JaneDev/janein an AWS role session- A device user in CrowdStrike
Without identity resolution, a SIEM treats these as unrelated identifiers. If Jane’s Okta session is compromised and the attacker uses her AWS credentials to exfiltrate data from S3, the SIEM can miss the connection between the two sources. Connecting them requires mapping the Okta identity to the AWS role session. If your team handles that with a manually maintained correlation rule for each pair of systems, every new source adds more mappings to maintain.
That pairwise approach doesn’t scale well. For an organization with 20+ SaaS applications, multiple cloud providers, and EDR across thousands of devices, maintaining identity mappings becomes a project of its own. Gaps in those mappings can let cross-source attacks go undetected.
3. Human vs. App Actions Get Blurred
When a SIEM ingests an event showing that Jane deleted 500 files from Google Drive, the event may be presented under Jane’s name without distinguishing whether she acted directly or a third-party backup app with OAuth access acted on her behalf.
A human bulk-deleting files is a potential insider threat; a backup tool doing it on its expected schedule may be routine. Clues to the acting app can be in the log, but not in a consistent place: a client ID in Google Workspace event parameters, identity and session fields in CloudTrail, or an application ID in a differently shaped Microsoft 365 record. The fields vary by source and event type. Without normalization, those clues stay where they landed, reachable if you know the exact path but absent from the common schema your team writes rules against.
And a client ID alone is an opaque string. What makes it meaningful is the app’s configuration: which scopes it holds, whether an admin consented tenant-wide or one user clicked through, and whether the publisher was ever verified. That’s configuration state. Unless the SIEM ingests and links that state, detections can’t use it.
So rules get written against the human identity alone, producing false positives on routine app activity and missing attacks carried out through a compromised token in the user’s name.
4. Resources Are Opaque
When a SIEM ingests a CloudTrail GetObject event for arn:aws:s3:::customer-vault-2023/export.dat, the event alone doesn’t establish whether the object contains production customer data or public marketing assets. When it ingests a Google Workspace event for file sharing, the event alone doesn’t establish whether the file contains the company’s financial projections or a lunch menu.
Resource sensitivity, ownership, and permissions require context beyond the access event. Unless the SIEM fetches and models that state, it can’t use it in detection. The analyst has to figure out whether the resource matters.
5. API Endpoints Are Reduced to URLs
Your applications expose hundreds of API endpoints. Some handle authentication. Some return sensitive data. Some are internal-only. In the raw log, a SIEM sees a URL like /api/v2/users/550e8400-e29b-41d4-a716-446655440000/documents/export. Without endpoint discovery, it doesn’t recognize that this URL and /api/v2/users/a1b2c3d4-ef56-7890-abcd-1234567890ef/documents/export refer to the same endpoint. Without a baseline, it doesn’t know that the endpoint normally receives 10 requests per minute, that the expected query parameters are format and limit, or that a request contains a parameter this endpoint has never seen.
API endpoints have their own schemas and normal traffic patterns. Detecting deviations requires a baseline for each endpoint. Indexing the URL as a text field doesn’t build those models.
6. Vendor Dialects Are Your Problem
Login events arrive in different forms: user.session.start in Okta, login_success for successful logins in Google Workspace, user_login in Slack, and user.login in GitHub’s security log. Microsoft Entra ID exposes sign-in records, while AWS CloudTrail records console sign-ins as ConsoleLogin.
These sources use different JSON structures, field names, nesting, and semantics for success and failure. A SIEM can normalize them into a common schema. Where that normalization is missing or incomplete, a detection for “suspicious login” requires source-specific logic and maintenance as vendor schemas change.
The problem goes beyond data formats. A shared semantic model needs to preserve what each event means: who authenticated, to which service, by what method, and with what outcome. That model is what makes detection logic portable across vendors without treating different actions as interchangeable.
7. Static Rules Decay
Static SIEM rules look like this: “alert if more than 5 failed logins in 10 minutes” or “alert if login from a country not in the allowlist.” A human picked those thresholds and conditions, once, based on what looked normal that quarter.
But normal moves. The company opens an office in a new country. A team adopts a CI/CD tool that generates hundreds of API calls. A user changes roles, and their access pattern shifts. The rule doesn’t. It either fires constantly against the new normal or sits above real activity and never fires at all.
SIEMs can do better: behavioral analytics and the tools for custom baselines exist. You can build a summary index, run streamstats over a trailing window, and set up an anomaly job. For a custom detection, building a baseline can become its own small project: pick the entity, pick the window, handle the cold start, store the state, and keep it fresh. When that baseline belongs to the query that built it, rather than a shared model of the entity it describes, the work repeats for the next detection.
The risk is that a handful of high-value detections get real baselines, and everything else stays a threshold someone typed years ago.
The cost traces back to the same root: with no shared model of the entity, you’re baselining a field value in isolation. The baseline lacks the context that the user changed roles last month or that the account is a service principal expected to act on a predictable schedule.
8. Alert Fatigue Has a Structural Cause
Security teams drown in alerts. The usual diagnosis is “too many rules” or “thresholds too sensitive.” One structural cause is that the detection engine lacks the context to decide whether an alert matters.
If the engine knew that a user was new and had no baseline, it could defer detections that depend on that baseline until there was enough data. If it knew that the user was already under active investigation, it could suppress redundant signals. If it knew that the resource being accessed was a public marketing bucket, it could give that access lower priority than access to a production database.
All of these prioritization decisions require context beyond the individual event. Without it, the analyst becomes the context engine, manually filtering signal from noise, alert by alert, hour by hour.
What It Would Take to Fix This
More rules alone won’t close this gap. SIEMs are built to ingest, index, and search logs. Making context consistently available to detections requires more than another lookup:
Fetching configuration and learning state. Knowing that Jane is an admin requires fetching her role from the IdP. Knowing that a bucket is classified as containing PII requires fetching its classification tags from AWS. Knowing that an API endpoint normally takes three parameters requires observing its traffic over time. Detections need that configuration and learned state alongside events.
Building a knowledge graph. People belong to departments. Departments have access to cloud accounts. Those accounts contain storage buckets tagged as PII. This graph of relationships helps you assess whether Jane accessing that bucket is routine or alarming. Indexing the events alone doesn’t establish those relationships.
Normalizing events into semantic models. Transform vendor-specific events into models that capture their meaning: who did what, to what, from where, with what outcome. This transformation makes detection logic portable across vendors and lets you reason about events in terms of people, resources, and actions.
Learning behavioral baselines. Build models that adapt to each user, device, and API endpoint. Cross-source baselines require shared identities: you can’t build a per-user ASN baseline across systems if you don’t know which events belong to that user.
Closing the feedback loop. Feed investigation outcomes back into detection. When an analyst determines that an alert was a false positive or marks a user as high risk, that context should change how future events are evaluated, without requiring a manual rule update.
The AI Agent Problem: Garbage In, Hallucinations Out
Adding an AI agent to a SIEM comes with a compelling pitch: “Let an AI investigate alerts so your analysts don’t have to.” But the quality of that investigation depends on the data the agent can access. If it gets only raw logs, it inherits the same context gaps as the analyst.
When an agent investigates a “login from an unusual location” alert using only the log line, it lacks the user’s role, access, resource sensitivity, and behavioral history. Without that grounding, it can fill the gaps with plausible-sounding reasoning that may or may not reflect reality. It might tell you, “This is likely benign because the user has logged in from multiple locations,” when in fact the user has never logged in from anywhere but New York. The answer sounds authoritative. It’s guessing.
An AI agent with access to a knowledge graph has more evidence to work with. When the graph contains the relevant data, the agent can look up the user’s identity, admin status, MFA posture, and historical login cities and ASNs. It can find resources accessed in the same session, check their sensitivity tags, and see whether the user’s device has a healthy EDR agent. It can also check whether the user’s HR record shows them as active or recently terminated.
The agent can reason from a structured representation of the enterprise and ground its findings in specific identities, relationships, and configuration state. That context gives analysts evidence they can check when assessing the agent’s conclusions.
The same applies to agentic workflows: automated investigation playbooks that chain multiple steps together. When context hasn’t been collected and linked, “look up the user’s role” requires a separate call to the IdP. “Check if the resource is sensitive” requires a lookup of its classification, and “find other activity from this user” requires queries across source-specific identifiers. Each step adds integration work. A knowledge graph makes those lookups available through shared relationships when the relevant data has already been collected, normalized, and linked.
The organizations that will get real value from AI in security operations are the ones whose AI has access to reality, not just to logs.
What Comes Next
This isn’t a theoretical exercise. In the next post, we’ll walk through how Exaforce transforms raw logs into purpose-built semantic models and enriches them with context for detection.
The difference between “we collect your logs” and “we understand your threats” starts with knowing what the logs are about.
Next: Part 2 — From Raw Logs to Semantic Intelligence
