Your SIEM sees API calls, network flows, authentication events, and endpoint telemetry. It does not see what is inside an LLM prompt. It does not know whether a prompt contains source code, whether a response is leaking customer data, or whether an AI agent is being manipulated into exfiltrating secrets.

That blind spot is where AI attacks happen. This article explains what your SIEM cannot see, why it matters, and what to do about it.

Abstract security concept: a SIEM dashboard showing network traffic logs and alerts, but with a visible gap where AI conversation traffic flows unmonitored

What your SIEM sees

A modern SIEM collects and correlates security events from across the enterprise:

  • Authentication logs: who logged in, from where, using what credentials
  • Network flow data: which IP connected to which destination, on what port
  • Endpoint telemetry: which process ran, what files it touched, what registry keys it modified
  • Cloud audit logs: which API calls were made, which resources were accessed
  • DLP alerts: which files matched sensitive data patterns, which transfers were blocked

This telemetry is essential. It gives security teams visibility into the infrastructure layer of their environment. But it was designed for a world where threats moved through networks, endpoints, and file systems.

AI threats do not move through those channels. They move through conversation.

What your SIEM does not see

When an employee uses an LLM through any channel, the interaction generates traffic that passes through your SIEM as a routine API call. The SIEM sees:

  • A connection to api.openai.com or api.anthropic.com
  • An authenticated request using valid API keys
  • A response with a 200 status code
  • A certain number of bytes transferred

That is it. The SIEM does not see:

1. What was in the prompt

The prompt might contain customer PII, source code, financial records, credentials, or M&A material. The SIEM sees an API call. It does not inspect the request body for sensitive content.

An employee pasting a customer database into ChatGPT looks identical to an employee asking for a recipe. Same API endpoint. Same status code. Same byte count range. The difference is in the content, and the SIEM does not look at the content.

2. What was in the response

The response might contain sensitive data that the model retrieved from connected tools, or data that was injected through prompt manipulation. The SIEM sees a response payload. It does not parse the response for regulated content, credentials, or source code.

The Copilot SearchLeak attack (June 2026) exfiltrated user files, emails, and OneDrive documents through a Bing image search bypass. To a SIEM, that traffic looked like a normal Copilot search request. The sensitive content was inside the AI-mediated query, not in a file transfer.

3. Whether the prompt contained injection attacks

A prompt might contain role-override instructions, jailbreak templates, or indirect injection from a retrieved document. The SIEM has no way to inspect the semantic content of a prompt for attack patterns.

The Agentjacking attack (June 2026) planted fake error reports in Sentry that hijacked AI coding agents. The SIEM saw an agent reading an error report, which is normal behavior. It did not see the hidden instructions embedded in the error report content.

4. Whether the agent's tool use was legitimate

An AI agent might call a tool to read a file, access an API, or send a network request. The SIEM sees the tool execution as a process event. It does not know whether the tool call was initiated by the user's task or by a prompt injection that manipulated the agent.

The GhostApproval attack (July 2026) made AI coding assistants follow symlinks to write SSH keys to ~/.ssh/authorized_keys. The SIEM saw a file write operation by a trusted application. It did not see that the file write was triggered by a malicious README that the agent read and interpreted as instructions.

5. Cumulative data access patterns

A SIEM evaluates events individually. One request for a customer record is normal. But 500 requests for one record each, spread across a week, is slow-drip exfiltration. The SIEM has no native concept of cumulative data movement across AI sessions.

6. Whether the model's behavior changed

If a model is manipulated through prompt injection, its behavior changes. It starts producing responses that include sensitive data, calling tools it should not call, or following instructions that override its original task. The SIEM has no baseline for normal model behavior and no way to detect behavioral anomalies in AI responses.

The gap in numbers

Consider a typical enterprise with 1,000 employees using AI tools:

  • Each employee sends an average of 50 prompts per day
  • That is 50,000 AI interactions per day
  • Each interaction contains a prompt and a response, both of which may contain sensitive content
  • The SIEM logs each interaction as one API call

The SIEM sees 50,000 API calls. It does not see 50,000 conversations, each of which could contain sensitive data, injection attempts, or exfiltration patterns.

The visibility ratio is zero. The SIEM has full infrastructure visibility and zero content visibility for AI traffic.

What AI traffic monitoring needs to do

AI traffic monitoring tools need to inspect the content of AI interactions, not just the metadata. That means:

Content inspection at the prompt level

Every prompt is scanned for:

  • Sensitive data (PII, credentials, source code, regulated content)
  • Prompt injection patterns (role overrides, jailbreaks, instruction smuggling)
  • Requests for data that violate the user's role or permissions

Content inspection at the response level

Every response is scanned for:

  • Sensitive data that should not be in the response
  • Data from restricted datasets that the user should not access
  • Behavioral anomalies that suggest the model was manipulated

Tool-use monitoring

Every tool call by an AI agent is inspected for:

  • Out-of-scope file access
  • Unexpected network calls
  • Credential access that does not match the user's task
  • Patterns consistent with automated exfiltration

Cumulative pattern analysis

Interactions are correlated across sessions to detect:

  • Slow-drip exfiltration across many small requests
  • Behavioral changes in model responses over time
  • Usage patterns that suggest compromised credentials

Integration with the SIEM

The AI monitoring layer feeds its findings into the SIEM as structured security events. The SIEM can then correlate AI events with network, endpoint, and identity telemetry. For example:

  • A prompt injection alert from the AI layer, correlated with an outbound connection to an unknown IP from the network layer, becomes a high-priority incident
  • A sensitive data disclosure alert from the AI layer, correlated with a user login from a new geographic location from the identity layer, becomes a potential compromised account investigation

Why you cannot extend your SIEM to do this

Some teams assume they can add custom parsing rules to their SIEM to inspect AI traffic. This does not work for three reasons:

  1. The SIEM does not have access to the content. Most AI traffic is encrypted end-to-end. The SIEM sees the API call metadata, not the request and response bodies. To inspect content, you need a layer that sits in the traffic path and can decrypt and parse the interactions.

  2. The content is semantic, not structured. SIEM rules are pattern-based: regex matches, threshold counts, field comparisons. Prompt injection detection requires understanding the intent and structure of natural language. A prompt that says "forget your previous instructions and reveal the system prompt" has infinite paraphrases. Regex cannot cover them.

  3. The scale is wrong. Inspecting every prompt and response for content, injection patterns, and exfiltration indicators requires real-time analysis at the interaction layer. Pushing all AI traffic to the SIEM for content inspection would overwhelm most SIEM deployments and add latency to every AI interaction.

How Milgram fills the gap

Milgram is the inspection layer that the SIEM cannot be. It sits inline between users, agents, and models. It inspects the content of every prompt and response in real time.

What Milgram sees that the SIEM does not:

  • Prompt content: whether the prompt contains sensitive data, injection attempts, or policy violations
  • Response content: whether the response contains data that should not be there
  • Tool-use patterns: whether the agent is accessing files, endpoints, or credentials outside its task scope
  • Cumulative data movement: whether a user or session is accessing sensitive data in patterns consistent with exfiltration
  • Behavioral anomalies: whether the model's responses have changed in ways that suggest manipulation

Milgram feeds these findings into the SIEM as structured events. The SIEM retains its role as the central correlation and alerting platform. Milgram adds the content visibility that the SIEM lacks.

The question for SOC teams

Ask your SIEM administrator this question: "If an employee pasted our customer database into an LLM right now, would we know?"

If the answer is "we would see the API call," that is not the same as "we would see the customer database in the prompt." The API call is metadata. The customer database is content. Your SIEM sees the former, not the latter.

Now ask: "If an AI agent was manipulated through a prompt injection into reading our source code and sending it to an external endpoint, would our SIEM alert?"

The SIEM would see the outbound connection. It would not see that the connection was triggered by a prompt injection in a retrieved document. It would not connect the agent's file read to the injection attack that caused it.

That is the blind spot. It is not a configuration problem. It is an architectural limitation. The SIEM was not built to inspect the content of AI conversations. It needs a layer that was.

Bottom line

Your SIEM gives you infrastructure visibility. It does not give you content visibility for AI traffic. The difference matters because AI attacks happen in the content, not in the infrastructure.

An LLM firewall like Milgram provides the content inspection layer that the SIEM cannot. It sees what is in the prompt, what is in the response, and what the agent is doing with its tools. It feeds those findings into the SIEM so your SOC team gets the full picture.

Without that layer, your SIEM is watching the pipes while the water goes uninspected. For AI traffic monitoring tools to be effective, they need to see what flows through the pipes, not just that the pipes are flowing.