Why can't our SIEM or EDR see analyst AI traffic?

Because the prompt does not travel in the layer those tools inspect. A SIEM correlates logs and an EDR watches endpoints, while an analyst's model call is an encrypted API request whose payload is a context window. The SIEM records an outbound connection to a provider and cannot read the telemetry inside the prompt unless TLS is terminated for that domain and the body is parsed. The SOC's own tooling is blind to the content of its AI calls.

What is the specific risk of a SOC using AI copilots?

That triage sends a map of the environment to an external model. Alerts, logs, and incident timelines carry asset names, account activity, detection logic, and occasionally a credential, and pasting them into a copilot moves that detail out of the environment on every run. For a security team, the exposed content is unusually sensitive, because it describes how the organization is defended. The output speeds up triage and the request needs the same controls the SOC applies to any other privileged data.

Does a gateway replace our detection stack?

No. The SIEM, EDR, and SOAR platforms detect and investigate on their own data planes, and they stay in place. A gateway governs the HTTP call between the analyst's AI tool and the model, which is a surface the detection stack does not cover. The gateway controls what internal telemetry leaves for the model and records it. The two address different points, one watching the environment, the other governing what the SOC sends to a model.

How does this connect to the inline-enforcement argument?

Directly. The SOC already knows that at machine speed, a control that only logs and alerts cannot prevent damage, which is why prevention has to happen inline. The same logic applies to the SOC's own AI traffic: a decision that blocks a disallowed prompt before it reaches the model prevents the disclosure, while an after-the-fact log only records it. Enforcing at the gateway puts the SOC's AI use under the same inline standard the team applies to everything else.

AI Security for SOC Teams: Governing What Analysts Send to the Model

A SOC analyst using an AI copilot feeds the environment's internal detail into a prompt during every busy shift. Triage a flood of alerts by pasting the raw events. Enrich an indicator by sending the surrounding log context. Summarize an incident by dropping in the timeline, the host names, and the account activity. Each request is an HTTPS POST to a model endpoint, and the body carries telemetry that maps the internal environment: asset names, user accounts, detection logic, sometimes a credential caught in a log line. The triage moves faster. The request sends the organization's security posture to a model, and the tooling built to watch the environment does not watch this.

The irony sits at the center of the SOC. The team that instruments everything runs its SIEM and EDR on traffic and endpoints, and those tools read a layer the prompt does not travel in. An analyst's model call is an encrypted API request whose payload is a context window, so the SIEM sees an outbound connection and the internal telemetry inside stays invisible. The SOC is blind to its own AI traffic in the same way shadow AI is invisible everywhere else.

Draw the boundary around the model call

A gateway governs the HTTP traffic between the analyst's AI tools and the model. It does not govern the SIEM or the endpoints.

Inside the boundary:

The copilot's HTTP call to the LLM, carrying the alert, log, or incident content.
The model's response returning to the analyst.

Outside it:

The SIEM, EDR, and SOAR platforms, which detect and investigate on their own data planes.
A query an analyst runs locally against a log store.

The gateway controls what internal telemetry leaves for the model and which analyst sent it. The detection stack keeps doing its job on the traffic and endpoints it already sees.

Bind each call to an analyst identity

A shared SOC key to the model erases attribution at the exact place a security team should demand it. Every analyst's triage prompt reaches the model as one credential, so nothing distinguishes a routine enrichment from a call that pasted an entire incident timeline. Route calls through the gateway and bind each to the analyst identity from the existing SSO. Policy can then apply to role and shift, and every prompt carrying internal telemetry names the analyst behind it, which the SOC would insist on for any other privileged action.

Classify internal telemetry in the prompt

A triage prompt is assembled from whatever the analyst is staring at, so the content leaving is not a reviewed template. A pasted log block can carry customer PII, a session token, or the internal hostnames and detection rules that describe how the environment is defended. The gateway classifies the outbound prompt against sensitive telemetry classes and applies policy on the class, so a call asking the model to explain an alert pattern is allowed while a call carrying a live credential or a block of raw PII is redacted or blocked before it reaches the model. Classification runs on the actual prompt, which is where the exposure is, rather than on a data source labeled once.

Constrain egress so triage does not become exfiltration

A per-analyst identity is enforceable only if a copilot cannot reach the provider directly. Restrict egress from the SOC tooling so the only route to any model endpoint runs through the gateway:

With egress constrained, a personally configured copilot key or an assistant instructed to send output to an outside endpoint fails at the network. The egress control keeps the gateway as the single path every triage call travels, which matters more in the SOC than almost anywhere, because the content is a map of the defenses themselves.

Record what left during triage

Every call produces a decision record: the analyst identity, the telemetry class in the prompt, the outcome, the policy version, and a timestamp. When an incident review turns to the response itself and asks whether internal detail reached an external model during triage, that record answers per call. It commits before the response returns, on a write path the copilot does not control, which is what a security team should expect of any control it relies on. The same argument the SOC makes about inline prevention versus log-and-alert applies to its own AI use, and the case for inline AI enforcement is one the SOC already understands.

DeepInspect

This is exactly what DeepInspect does. A SOC copilot sends internal telemetry to an LLM over HTTP, and DeepInspect sits inline at that boundary between the tool and the model endpoint it calls.

For every request, DeepInspect binds the call to the analyst identity the application supplies, classifies the prompt against sensitive telemetry classes, applies per-role policy, and makes a deterministic, fail-closed decision before the alert or log reaches the model. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the copilot never controls. DeepInspect reads the prompt content that the SIEM and EDR run underneath, and it governs the model traffic rather than replacing the detection stack that watches the rest of the environment. If your analysts are pasting alerts and logs into copilots and the SOC cannot see its own AI traffic, book a demo today.