LLM Security Monitoring: Five Vantage Points, and What Each One Can Physically See
An LLM security monitoring program is decided by where the telemetry is collected, because each vantage point has a physical limit on what it can observe. DNS and proxy logs see domains. CASB sees applications. Provider dashboards see usage without corporate identity. Application logs see everything and are written by the system under investigation. This compares all five, states the fidelity limit of each, and gives the event schema worth sending to a SIEM.

A monitoring program is defined by its collection point. Everything downstream, the detections, the dashboards, the SIEM correlation rules, inherits a hard ceiling from what the collector could physically observe. For LLM traffic there are five candidate vantage points, and their ceilings differ by orders of magnitude.
Start with the ceiling rather than the tooling.
Vantage point 1: DNS and network proxy logs
What they see: a resolution for api.openai.com, a TLS session opened from a source IP, a byte count, a duration.
What they cannot see: the prompt, the model, the system prompt, the retrieved documents, the response, or which human is behind the session when the traffic originates from a shared egress. Network DLP sits at this layer and is blind to prompt content, because the payload rides inside the TLS session and the DLP was built to classify documents rather than a context window assembled at request time.
Value: discovery. This is how a security team first learns that 40 unapproved AI domains are being reached from the engineering VLAN. Cloud Radix put unauthorized AI tool use at 78% of employees and found 86% of IT leaders are completely blind to those interactions (Cloud Radix). DNS is the cheapest instrument that begins to close that gap.
Vantage point 2: CASB and secure web gateway
What they see: which sanctioned and unsanctioned AI applications are in use, by which user account, at what volume. Some perform TLS inspection against a known list of AI domains and can extract a prompt field.
What they cannot see: anything travelling to a self-hosted inference endpoint, an internal agent calling a model over a private link, or a provider domain the vendor has not yet added to its catalog. The coverage is a list, and the attacker's traffic and the developer's traffic both leave the list regularly.
Value: employee-facing shadow AI, which is a real and large problem. Zscaler's ThreatLabz 2026 report measured 18,033 TB of enterprise data flowing into AI tools and more than 410 million ChatGPT DLP policy violations, up 99% year over year (Infosecurity Magazine).
Vantage point 3: model provider dashboards
What they see: token counts, latency, error rates, and usage per API key.
What they cannot see: your corporate identity model. The provider knows the key. Mapping key to human requires an inventory the provider has never had. They also see nothing about the requests your other three providers served.
Value: cost and capacity. Treat this as billing telemetry that happens to contain some security signal, and never as an investigative record.
Vantage point 4: application logs
What they see: potentially everything, since the application assembled the prompt and received the response.
The limit here is not visibility. It is custody. The application that made the AI decision is also the system under investigation whenever something goes wrong, which produces three specific failure modes. It logs the paths its instrumentation anticipated, and the anomalous path is the one that goes unrecorded. Its logs can be modified or dropped by the same process that failed. And it loses the record entirely when the process dies after the model responded and before the write committed, leaving an executed action with no evidence it happened.
In every other regulated domain, the system under audit does not author its own evidence. The CFO does not sign the audit of the statements they prepared.
Vantage point 5: the AI request boundary
What it sees: the assembled context window in plaintext, the verified identity of the caller, the role that identity holds, the model and version being addressed, the policy evaluated, the decision made, and the full response before it returns.
This is the only collection point where the payload, the identity, and the policy state are all available at the same moment, and the only one outside the process it is observing. A proxy terminating the request writes the record before the response goes back, which removes the crash-loss and suppression failure modes structurally rather than procedurally.
Fidelity, side by side
| Vantage point | Prompt content | Corporate identity | Model + version | Policy state | Independent of app | |---|---|---|---|---|---| | DNS / proxy | No | Partial | No | No | Yes | | CASB / SWG | Partial (listed domains) | Yes | Partial | No | Yes | | Provider dashboard | No | No | Yes | No | Yes | | Application logs | Yes | Yes | Yes | Partial | No | | AI request boundary | Yes | Yes | Yes | Yes | Yes |
The signals worth alerting on
Volume metrics fill dashboards and change nothing. Five signals carry enough information to justify a page:
- An unrecognized in-environment identity making model calls. This is what an attacker's agent looks like from the gateway. Sysdig's JadePuffer disclosure on July 1, 2026 documented an LLM agent running a full ransomware operation, and every step of it required the agent to reach a model (Sysdig).
- A refusal-to-compliance flip inside a session, which is the observable form of a successful jailbreak.
- A prompt carrying a data classification the requesting role has never carried before.
- A call to a model endpoint or provider that policy has not authorized for that identity.
- A per-identity spend or call-rate departure from its own baseline, rather than from a global threshold.
Monitoring and the 22-second problem
Be honest about what monitoring buys. Mandiant's M-Trends 2026, built on over 500,000 hours of frontline incident response, found the median time from initial access to handoff to a secondary threat group collapsed from more than eight hours in 2022 to 22 seconds in 2025 (Help Net Security).
At that tempo, an alert is a forensic artifact. It has real value: it is the record a regulator asks for, the timeline an incident responder reconstructs, and the evidence a court accepts. Its prevention value at machine speed is zero, because the decision it describes has already executed.
The conclusion follows directly. Collect at the request boundary, where the same component that observes the request also holds the authority to stop it. Then the monitoring program and the enforcement program are the same system, and the record is a byproduct of the decision rather than an echo of it.
What to send the SIEM
One event per AI decision, normalized:
Hashes rather than payloads keep the SIEM from becoming a second copy of the data the policy just refused to release. Retention runs against the regime: EU AI Act Article 12 requires automatic recording of events over the lifetime of a high-risk system to ensure traceability, including timestamps, input data, and identification of the natural persons involved (Practical AI Act).
I cover the narrow cases in prompt injection monitoring and LLM egress monitoring.
DeepInspect
This is exactly what DeepInspect does. DeepInspect is a stateless proxy at the AI request boundary, between authenticated users or agents and any HTTP-based LLM endpoint. It observes the assembled prompt, the verified identity, the model addressed, and the policy in force, then permits, redacts, or denies inline before the request reaches the model, with a fail-closed default and under 50 ms of overhead in internal testing.
Each decision writes a signed record committed before the response returns to the calling application, and that record is the monitoring event. The enterprise gets telemetry with prompt content, corporate identity, model version, and policy state on the same line, produced by a component the application under observation does not control. Because the proxy is model-agnostic, the same event schema covers OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and self-hosted endpoints.
If your AI monitoring currently stops at the DNS layer, book an AI readiness assessment.
Frequently asked questions
- What should LLM security monitoring collect?
One structured event per AI decision, carrying the verified identity of the caller, the role, the model and version addressed, the classification of the content in the assembled context window, the signal scores that were evaluated, the policy version in force, the outcome, and hashes of the prompt and response. Volume and latency metrics belong in the same event and answer capacity questions. The security questions are answered by identity, classification, policy, and outcome.
- Can a SIEM monitor LLM traffic on its own?
A SIEM correlates events it is sent. The limiting factor is the collector: if the only AI events reaching it are DNS resolutions and proxy byte counts, no correlation rule recovers the prompt content or the corporate identity behind a shared egress. Get the collection point right first, then the SIEM becomes useful for correlating AI decisions against endpoint, identity, and cloud events.
- How do you monitor for shadow AI?
Start at DNS and the web proxy, because they see reachability regardless of sanction. That produces the list of domains being contacted and the rough volume. It stops there: the prompt content stays inside TLS. Closing the loop requires routing AI traffic through an enforcement point that terminates the request, attaches corporate identity, and classifies the payload, which converts a list of domains into a record of what left the environment and who sent it.
- What is the difference between AI monitoring and AI enforcement?
Monitoring produces a record of what happened. Enforcement produces a decision about what is permitted, evaluated before the request reaches the model. With a 22-second median handoff time between an initial access and a secondary threat group, an asynchronous record cannot prevent an outcome. The practical resolution is to collect at the same point that enforces, so the record is a byproduct of a decision rather than a report about one.
- How long should AI decision logs be retained?
Set the period against the regime that governs the system. EU AI Act Article 12 obligations run over the lifetime of a high-risk system, and sector regimes add their own horizons, with financial services and healthcare typically running multi-year. Storing hashes and structured decision metadata rather than raw prompts keeps the retention cost bounded and keeps the evidence store from becoming a fresh copy of the sensitive data the policy was protecting.