Vaikora › Blog › Detection & SOC

AI and CASB: Extending DLP to LLM Traffic

Detection & SOC · June 30, 2026 · 13 min read

AI DLP for LLM traffic means inspecting and redacting sensitive data in prompts before they reach an LLM API, blocking accidental disclosure of secrets, PII, and proprietary information. Traditional CASB and DLP tools monitor file uploads and SaaS API calls but cannot inspect LLM API request bodies or token streams. When employees paste customer data, API keys, or source code into an AI prompt, CASB sees a normal HTTPS connection to OpenAI or Anthropic and allows it. Inline prompt inspection at the LLM gateway detects and redacts sensitive patterns in real time, closing the gap between enterprise DLP and AI-native data leakage.

The CASB and DLP gap with AI applications

Enterprise DLP and CASB tools have protected data loss for over 15 years by monitoring file uploads to SaaS platforms and enforcing policy on risky API actions. A CASB enforcer sits between the user and SaaS applications, decrypting TLS traffic, parsing API calls, and blocking uploads of credit cards or source code. This architecture works well for document sharing, email, and traditional SaaS APIs. LLM applications break the assumption.

When an employee opens ChatGPT or uses an in-house LLM copilot, the traffic flows over HTTPS to an LLM provider or a self-hosted gateway. From the CASB perspective, this looks identical to a normal cloud application request. The request body contains a JSON object with a messages array and a model ID. CASB policies typically focus on file operations: blocking uploads of sensitive MIME types, enforcing encryption, or logging access by user. They do not parse the semantic content of a chat prompt.

The prompt itself is often plain text, free-form, and written by a user in the moment. A user might paste a database query result into the prompt to ask an AI to explain it. That query result contains customer names, email addresses, and order IDs. A developer might ask the AI to debug a script and paste an AWS access key by mistake. A financial analyst might share a CSV snippet with quarterly revenue projections. None of this triggers traditional DLP rules because DLP has not been taught to inspect prompts as a data channel.

Why traditional DLP misses AI data leakage

Data loss prevention systems enforce policy at predictable data boundaries. DLP scans email attachments, monitors clipboard operations, inspects file uploads to cloud storage, and watches USB device connections. These are well-defined, user-controlled data flows. A user clicks "upload" or hits send, and the DLP scanner intercepts and evaluates the action.

Prompt submission is different. Prompts are rapid, unstructured, and often ephemeral. A user types a query, hits enter, and the request arrives at an API endpoint in milliseconds. The prompt content is not a file with a MIME type and filename. It is a message in a conversation thread, mixed with system instructions, function calls, and chat history. DLP tools designed to scan documents or email bodies struggle to parse and classify prompt payloads correctly.

Additionally, traditional DLP has few incentives to inspect LLM traffic until recently. The volume of LLM API calls was low, and the threat model was unknown. Most organizations did not have deployed LLM applications five years ago. DLP policy was written for email, cloud storage, and web uploads, not for AI APIs. The vendors and security teams did not prioritize it.

The result is a silent data leak. Employees send sensitive information into LLM applications every day. CASB logs a connection to api.openai.com or api.anthropic.com as a "high-risk application" and may block it entirely, but does not inspect what was sent. Organizations with restrictive CASB policies may ban public LLM use, forcing employees to use local or in-house models, but they still have no visibility into what data flows through those models.

How CASB and DLP tools see LLM API traffic today

A typical CASB implementation decrypts TLS traffic, reassembles HTTP requests and responses, and runs policy rules against headers, query parameters, and sometimes the request and response bodies. For most SaaS applications, the body is JSON or form data with predictable schemas: a document upload, a config change, a user creation. The CASB vendor has reverse-engineered the API and knows which fields are risky.

LLM APIs present a problem for this model. OpenAI's Chat Completions API accepts a messages array with variable content. The CASB cannot know in advance what a user will ask or what data might be in the prompt. The body size can be large, containing chat history, file transcripts, or encoded images. Parsing the semantic meaning of a prompt requires understanding natural language, context, and the sensitivity of different data types.

Some CASB tools have begun to add basic DLP pattern matching to LLM traffic. They scan the prompt for patterns like social security numbers, credit card numbers, or database credentials. This is a good start but has limitations. Pattern-matching for credit cards (Luhn-algorithm validation) is reliable. Pattern-matching for API keys, database URLs, or customer PII is less reliable. A fake credit card number might match the Luhn check. A database query result might look like PII if it contains email addresses, but it might also be legitimate test data. False positives and false negatives are common.

Also, pattern-matching is a static, rule-based approach. It cannot detect novel forms of data leakage, such as an employee pasting a PDF export of a customer relationship management system containing names and contact information in an image. It also cannot enforce policy based on user role, department, or data classification. A sales representative might be allowed to ask an AI for help analyzing customer data, while a finance team member should not.

The technical solution: Inline prompt inspection at the gateway

An LLM gateway sits between client applications and the LLM API, handling request routing, authentication, caching, and cost control. Injecting DLP and data sanitization into the gateway layer allows inspection and redaction of prompt content before it reaches the model. This is where Vaikora's approach differs from traditional CASB.

Gateway-based inspection works at the request body level. When a user or application sends a prompt to the LLM, the request passes through the gateway. The gateway parses the messages array, extracts text content, and runs a battery of detectors on each message:

• Pattern-based detection: regex or Luhn-check for credit cards, social security numbers, API keys, and known secret formats.
• Semantic detection: machine learning models that classify text as containing PII, source code, trade secrets, or regulated data (HIPAA, PCI DSS scope).
• Contextual detection: knowledge of the user's role, department, and data classification labels, combined with policy rules to determine if this data is authorized for this user to submit to an LLM.

If sensitive data is detected, the gateway can apply one of several actions:

• BLOCK: reject the prompt and return an error to the user.
• REDACT: replace sensitive values with placeholders (e.g., [REDACTED_SSN], [REDACTED_SECRET]) before sending the prompt to the model.
• LOG: allow the request but record the detection event for audit and threat investigation.
• CONSTRAIN: allow the request but add a safety constraint to the LLM's system instructions (e.g., "do not repeat the following data in your response").

Redaction is the most practical approach for most organizations. If an employee pastes a database query result into a prompt and accidentally includes customer email addresses, redaction removes those addresses before the prompt reaches the LLM. The LLM still answers the question using the remaining data (query structure, table names, row counts) and does not see the PII.

Vaikora's approach to inline prompt inspection

Vaikora's runtime control system includes an LLM gateway that performs this inspection. The gateway is deployed as a reverse proxy or sidecar in your infrastructure and intercepts all LLM API calls. It supports any model API that uses a JSON request body (OpenAI, Anthropic, Azure OpenAI, open-source models, etc.). When a prompt arrives, Vaikora's detectors inspect the messages array and any other user-controlled fields, apply redaction or blocking policies, and forward the sanitized request to the LLM.

Vaikora also signs each decision into a SHA-256 append-only audit chain, creating an immutable record of what data was flagged, what action was taken, and why. This audit trail is essential for compliance with regulations like HIPAA, GDPR, and SOC 2, and for incident response when a data breach is suspected.

Detection example: Sentinel KQL for LLM data exfiltration patterns

Here is a KQL query for Microsoft Sentinel that detects suspicious patterns in LLM API traffic logged from a gateway like Vaikora. This example uses known LLM API hostnames and inspects request payloads for embedded secrets. Substitute your organization's LLM provider hostnames and adjust detection thresholds based on your threat model.

CommonSecurityLog
| where DeviceAction == "Allow" and ApplicationProtocol == "http"
    and DestinationHostname in ("api.openai.com", "api.anthropic.com", "api.azureopenai.com")
| where HTTPRequest has_any ("gpt-", "claude-", "/chat/completions", "/messages")
| extend PromptLength = strlen(RequestPayload)
| where PromptLength > 5000  // Large payloads may indicate data exfiltration
| extend HasSSN = RequestPayload has_regex @"\b\d{3}-\d{2}-\d{4}\b"
| extend HasAPIKey = RequestPayload has_regex @"(sk-|AKIA|ghp_|Bearer\s+)"
| extend HasCreditCard = RequestPayload has_regex @"\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b"
| where HasSSN or HasAPIKey or HasCreditCard
| project TimeGenerated, SourceUserID, DestinationHostname, PromptLength, 
    HasSSN, HasAPIKey, HasCreditCard, RequestPayload
| summarize DetectionCount = count() by SourceUserID, bin(TimeGenerated, 1h)
| where DetectionCount > 3

This query flags users sending multiple prompts with embedded secrets, SSNs, or credit cards to LLM APIs within a one-hour window. Analysts can drill into individual prompts to confirm the leakage and take corrective action. For accuracy, confirm the actual DNS names and IP ranges your organization uses for each LLM provider.

Integrating gateway-based DLP with your CASB policy

Gateway-based prompt inspection complements, rather than replaces, traditional CASB. Your CASB continues to monitor file uploads, enforce application access policy, and scan email. The LLM gateway adds a new data channel to your DLP scope.

To implement this integration:

1. Deploy an LLM gateway (self-hosted or SaaS) in front of all LLM APIs your organization uses.
2. Define sensitive data patterns based on your compliance requirements (HIPAA, PCI DSS, GDPR, etc.) and your industry-specific secrets (API keys, internal hostnames, customer IDs).
3. Set gateway policies that specify which redaction or blocking rules apply to which users or departments. For example, a finance employee might not be allowed to submit raw financial statements to a public LLM, but a summarized spreadsheet is acceptable.
4. Export gateway logs to your SIEM or data warehouse, so your SOC can correlate LLM data-loss events with other security alerts and trigger incident response workflows.
5. Audit the audit chain regularly. Vaikora's SHA-256 audit trail enables forensic analysis if a breach occurs. You can prove what data was flagged, what action was taken, and when.

Regulatory and compliance alignment

The EU AI Act, the NIST AI Risk Management Framework (AI RMF), and ISO 42001 all emphasize the importance of input validation and data protection in AI systems. Inline prompt inspection is a control measure that demonstrates compliance with these frameworks. It shows auditors that your organization has adopted technical safeguards to prevent unauthorized data flows into AI models.

Organizations using LLM services must assess data protection requirements carefully. For HIPAA-covered entities, protected health information (PHI) requires careful handling. If your LLM provider (e.g., OpenAI, Anthropic) does not offer a Business Associate Agreement (BAA), you cannot legally send PHI to their APIs. In such cases, gateway-based redaction allows a covered entity to use LLM services while filtering out PHI before transmission, provided the LLM provider consents to this arrangement in a BAA. Consult your legal and compliance team on BAA availability before deploying LLM applications.

For organizations handling payment card data, PCI DSS requires technical and administrative controls. Gateway-based redaction is a necessary technical control; it removes card numbers from prompts before they reach an LLM. However, PCI DSS compliance also requires contractual controls. If the LLM provider is a service provider that processes card data, you must have a written Service Provider agreement in place and ensure the provider is PCI-compliant. Redaction alone does not satisfy PCI DSS if the LLM provider itself is not assessed.

GDPR requires that personal data processing is limited to specified purposes. If an LLM is used for customer support automation, personally identifiable information should be minimal. Gateway-based inspection allows European organizations to enforce this principle automatically, redacting email addresses and names from customer service prompts before they reach the model.

Common challenges and practical tips

Challenge: False positives. A regex pattern for API keys might match random strings in a customer's support ticket. Redacting legitimate data degrades user experience. Solution: Combine pattern-based and semantic detectors. Machine learning models trained on real secrets are more accurate than regex alone. Allow users to whitelist certain data if necessary, with audit logging.

Challenge: Latency. Inspection adds processing time. If a gateway adds 100 milliseconds to every prompt, user experience suffers. Solution: Implement caching for frequently seen prompts and responses. Use a tiered detection approach: fast pattern-matching first, semantic detection only if patterns trigger. Most modern gateways can inspect and redact a prompt in under 50 milliseconds.

Challenge: Model unavailability. If your gateway is offline, should prompts be allowed or blocked? Solution: Default to block in security-sensitive environments. For user-facing copilots, allow prompts with a degraded detection set (pattern-based only) and log for later audit.

Challenge: Encrypted or encoded data. If sensitive data is base64-encoded or embedded in a PDF or image, pattern matching will fail. Solution: Decode common encodings and extract text from images before detection. This is computationally expensive but necessary for compliance in regulated industries.

Frequently asked questions

Can CASB tools monitor LLM traffic?

Basic CASB tools can see that a user is connecting to OpenAI or Anthropic but cannot inspect the prompt content. Advanced CASB solutions are beginning to add pattern-based detection to LLM traffic, flagging credit card numbers or known secrets. However, they typically lack semantic understanding of what data is sensitive in a given context and cannot redact data in prompts before they reach the model. Full LLM DLP requires a dedicated gateway or proxy with semantic detection.

Why does traditional DLP miss AI data leakage?

Traditional DLP was designed to scan file uploads, email attachments, and clipboard operations. These are predictable data boundaries. Prompts are unstructured text, submitted rapidly, often mixed with chat history and system instructions. DLP policies written for documents do not parse prompts correctly, and the semantic meaning of a prompt is difficult to classify automatically. Additionally, most organizations did not deploy LLM applications when current DLP policies were written, so LLM APIs are not in scope.

How do you apply DLP to AI prompts?

Deploy an LLM gateway between your applications and the LLM API. The gateway intercepts requests, extracts the prompt text from the JSON request body, and runs detectors (pattern-based, semantic, or contextual) to identify sensitive data. If sensitive data is found, the gateway redacts it, blocks the prompt, logs the event, or constrains the model's response, depending on policy. The sanitized prompt is then sent to the LLM.

What sensitive data leaks through LLM applications?

Common leakage includes API keys and secrets (AWS access keys, database passwords), personally identifiable information (names, email addresses, phone numbers, social security numbers), payment card data (credit card numbers), customer relationship data (account numbers, contact lists), and proprietary information (source code, product roadmaps, internal documentation). Employees often paste these accidentally when asking an LLM for help debugging, analyzing data, or explaining a technical concept.

Do I need to block all LLM access if I cannot inspect it?

Blocking public LLM services is a risk-mitigation option if you have no gateway-based inspection. However, it also blocks productivity and forces employees to use shadow IT. A better approach is to deploy a gateway with inline DLP, allowing controlled use of LLM services while protecting sensitive data. Alternatively, limit LLM access to less-sensitive use cases (brainstorming, code documentation, writing assistance) where accidental leakage is lower-risk.

How does inline redaction affect LLM output quality?

Redaction can improve output quality if the sensitive data is not essential to the question. For example, redacting a customer email address from a debugging question usually does not hurt. The LLM still understands the technical problem. Redacting a customer ID from an analytics prompt might make the response less specific. Administrators should tune policies to balance privacy and utility. Logging allows you to audit cases where redaction degraded output and adjust policies accordingly.

What compliance frameworks require LLM DLP?

The EU AI Act requires risk assessment and mitigation for high-risk AI systems, including data protection. HIPAA requires technical safeguards for protected health information (subject to Business Associate Agreement requirements with your LLM provider). PCI DSS requires that payment card data is protected and not sent to unauthorized systems (and service provider agreements if the LLM vendor processes card data). GDPR requires that personal data processing is minimized and justified. ISO 42001 and ISO 27001 both recommend input validation and data protection controls for AI systems. Gateway-based inspection demonstrates compliance with all of these frameworks, though contractual agreements with LLM providers may also be necessary.

More from the Vaikora blog