Does the inspection layer handle voice support flows differently from chat flows?

The voice flow reaches the inspection layer through the transcript and the post-call summarization step. The voice-to-text transcription typically runs outside the inspection layer's HTTP path. The text the transcription produces is what the bot's runtime sends to the LLM, which is what the inspection layer reads. The record series at the LLM request boundary covers the voice flow at the point where the text reaches the model. The voice-side telemetry remains separate and the deployment composes the two record series for the full flow.

How does the inspection layer handle customer PII that the end customer types into the bot?

The end customer's input is part of the prompt the bot sends to the model. The inspection layer reads the prompt, runs the PII classifier on the content, and applies the policy. The policy can pass the content (the model can reason over the PII for the support workflow), block (the prompt contains PII the model is not authorized to process for this customer), or modify (redact the PII from the prompt before forwarding, with the redaction recorded in the audit record). The decision depends on the identity, the route, and the policy version at decision time.

How does the inspection layer cover the tool calls the bot makes against internal APIs?

The inspection layer sits in front of the LLM API and, in deployments where the tool calls also cross an HTTP boundary the deployment wants to audit, in front of the tool APIs. The records produced at the tool boundary carry the same fields and the same correlation identifier as the records at the LLM boundary. The reviewer reads a single record series for the full conversation.

What is the audit record retention period for customer support bot data?

The retention period varies by regime. PCI DSS Requirement 10.5 expects 12 months of audit logs with at least 3 months immediately available. GDPR requires retention only as long as needed for the stated purpose. HIPAA 45 CFR 164.316(b)(2) expects 6 years for required documentation. EU AI Act Article 12 expects retention for the lifetime of the system. The inspection layer commits records to durable storage; the retention period is configured per the regimes the deployment operates under and the records remain accessible across the regimes' retention windows.

AI Security for Customer Support Bots: The Inspection Layer Between the Bot and the Customer Data

Q: How does the inspection layer help with the prompt-injection surface in retrieved content?

The inspection layer reads the prompt content the bot sends to the model, which includes the retrieved content the bot pulled into the prompt context. Classifier passes detect known injection patterns and structural cues. The policy evaluates the detection against the identity and the route. The decision can pass, block, or modify the prompt (sanitize the suspicious span, annotate the prompt for the model). The audit record carries the detection signal and the decision

Customer support bots reach the customer's records, the recent ticket history, the payment instruments on file, the order data, and any PII the support workflow exposes. The bot authenticates the support agent or the end-customer at the start of the session, attaches the identity to the conversation, and makes a series of model calls and tool invocations as the conversation progresses. Each tool call returns customer data into the LLM context window. The model reasons over the data. The bot acts on the result. The security boundary is the HTTP path between the bot's runtime and the upstream model and tool APIs.

I want to walk through the data flows the bot exercises in production, the identity and authorization decisions the inspection layer commits at the request boundary, the audit record the customer auditor and the regulator consume, and the prompt-injection surface that retrieved customer content opens.

The data flows the bot exercises

The first flow is the end-customer-facing path. The end customer types a message into the bot. The bot's runtime calls the LLM with the customer's message and any system prompt. The model may call tools (look up the customer's order, check the refund eligibility, retrieve the FAQ entry, draft a response). Each tool call retrieves customer data into the model's context window. The model produces a response the bot returns to the end customer.

The second flow is the agent-assist path. A human support agent works the ticket. The bot's runtime provides suggested responses, summary of the ticket history, classification of the issue, and recommended next steps. The bot calls the LLM with the ticket context and the customer's records. The model reasons over the context and returns suggestions the agent reviews. The agent's identity carries through the session.

The third flow is the post-call summarization path. A call recording or transcript reaches the bot's runtime. The bot summarizes the call, extracts action items, and writes the result back to the ticket and the CRM. The data flow happens after the customer interaction.

Each flow produces multiple HTTP requests to upstream services. The model API is one. The tool API for order lookup is another. The retrieval API for the FAQ entry is a third. Each request carries data the security boundary has to evaluate.

The identity and authorization decisions the inspection layer commits

The decisions cover the same three axes the internal-copilot deployment exercises. The user-against-data axis restricts retrieval to records the user's tenant and role authorize: a support agent in tenant 1 reads only tenant 1 customer records, an end customer reads only their own account, a support agent without PCI authorization receives a block on payment card retrieval. The user-against-action axis caps tool actions by role: junior agents call the refund tool up to the junior limit, end customers escalate refunds only inside the workflow's defined paths. The data-against-model axis routes prompts to models whose data processing terms cover the content classification: PCI content routes only to PCI-covered models, PHI content routes only to PHI-covered models, MNPI content routes only to MNPI-covered models.

The inspection layer reads the request the bot sends to the LLM and the tool APIs. The request carries the prompt, the system prompt, the tool list the bot exposed to the model, and any structured fields. The retrieval results from earlier tool calls show up in the prompt context. The classifier passes detect PII, PHI, PCI, and other sensitive categories in the content. The policy decision evaluates the identity, the data classification, and the route binding.

The decision the layer commits is pass, block, or modify. Pass forwards the request. Block rejects with a structured error the bot's runtime surfaces to the caller (the support agent or the end customer). Modify redacts detected sensitive content before forwarding (for example, removing the customer's full payment card number from the prompt, replacing with a token or a masked version the model can reason over without seeing the cleartext).

The audit record the customer auditor and the regulator consume

The record carries identity (the agent identity for agent-assist flows, the end-customer identifier where applicable, the bot's session identifier), route (which conversation, which step), data classification (PII, PHI, PCI, regulated identifiers), policy version, decision outcome (pass, block, or modify with the rule identifier), upstream model and version, and integrity metadata. The format is the same format the EU AI Act Article 12, GDPR Article 32 security of processing, PCI DSS Requirement 10 audit trail, HIPAA 45 CFR 164.312 access record, and DORA Article 19 reviewers consume.

The record series satisfies the customer auditor who reviews the deployment under a SOC 2 Type II audit. The audit trail criterion (CC7.1) expects records of significant events with the identity, the timestamp, and the outcome. The inspection layer's record series satisfies the criterion at the AI request boundary, which is the boundary the SOC 2 reviewer increasingly asks for evidence at as AI traffic grows inside the deployment.

The record series also satisfies the customer auditor who reviews the deployment under a PCI DSS QSA assessment. The PCI DSS Requirement 10 logging obligation expects records that cover access to cardholder data. A customer support bot that retrieves payment card data into the model context window produces an access event the record covers.

The prompt-injection surface that retrieved content opens

Customer support bots retrieve content from customer messages, ticket history, FAQ knowledge bases, and call transcripts. The retrieved content reaches the model as part of the prompt context. The content can carry injection patterns that target the model's instruction-following.

The classic patterns include a customer message that asks the bot to ignore the system prompt and act as a different persona. A ticket history entry left by a previous customer that contains instructions to the model. A retrieved FAQ entry whose content has been edited (intentionally or unintentionally) to redirect the model's response. The injection succeeds when the model treats the embedded text as instructions on the next reasoning pass.

The defense is the inspection-layer policy at the request boundary, plus optional defense-in-depth layers inside the application (Rebuff, Llama Guard). The inspection layer reads the prompt content and applies classifier passes for known injection patterns and structural cues. The policy evaluates the detection result against the identity and the route. A high-confidence injection detection in a retrieval-derived field can produce a block or a modify (sanitize the content, strip the suspicious span, or annotate the prompt for the model).

The audit record carries the detection signal and the decision outcome. The reviewer reading the record series after a suspected incident reads the specific request that triggered the detection and the policy version that produced the decision. The forensic reconstruction does not depend on application-side telemetry.

What GDPR, CCPA, and PCI DSS expect

GDPR Article 32 expects technical and organizational measures appropriate to the risk. AI-mediated customer support that processes personal data of EU residents falls inside the scope. The inspection-layer record series satisfies the demonstrable-compliance obligation under Article 5(2). The data minimization principle under Article 5(1)(c) drives the redact-PII-from-prompts pattern the inspection layer's modify decision implements.

CCPA and the California Privacy Rights Act expect records of personal information handling and the right to know what is processed and how. The inspection layer's record series carries the access events at the AI request boundary, which the consumer's right-to-know request reads from.

PCI DSS v4.0 Requirement 10 (logging) expects records of access to cardholder data and to the systems that process cardholder data. A customer support bot that retrieves payment card data into the model context window operates as a system that accesses cardholder data. The inspection layer's record covers the access event with the identity, the timestamp, the route, and the outcome.

DeepInspect

This is exactly what DeepInspect does for customer support bots. DeepInspect sits inline between the bot's runtime and any HTTP upstream the bot calls (LLM endpoint, CRM, payment system, ticketing API, retrieval endpoint). The inspection layer reads the prompt and the retrieval context, classifies the content (PII, PHI, PCI, MNPI, regulated identifiers), evaluates identity-bound policy against the support agent or end-customer identity, the route, and the policy version, and applies pass, block, or modify before the response forwards.

The audit record series carries identity, route, data classification, policy version, decision outcome, upstream model and version, and integrity metadata in a format the EU AI Act Article 12, GDPR Article 32, PCI DSS Requirement 10, HIPAA 45 CFR 164.312, and DORA Article 19 reviewers consume. The series covers the agent-assist flows, the end-customer-facing flows, and the post-call summarization flows from the same pipeline. End-to-end inspection-layer overhead measures under 50 ms in production.

If you are running a customer support bot in production and the auditor is asking for the records of who saw what customer data through the bot, let's talk today.