LLM data egress and security controls

CodeGraph sends the selected provider a system_prompt and a user_prompt. Those prompts can contain user text, code fragments, generated summaries, or structured CPG evidence, depending on the calling workflow. The runtime applies configured governance and DLP before the provider call. Use the configured provider, access, network, and review controls to manage the payload contents and data path.

Actual request path

The request passes through these stages:

The caller supplies system_prompt, user_prompt, operation context, and provider settings.
Prompt governance resolves the active policy and approval state.
Pre-request DLP scans the combined prompts.
The active DLP action may BLOCK, MASK, WARN, or LOG_ONLY.
AI FinOps routing selects the target provider.
CodeGraph sends the prepared system instructions and user prompt to the provider.
For ordinary generate, post-response DLP scans the response before returning it to the caller.

SecureLLMProvider performs this sequence for workflows that call the provider through the wrapper. The scanner processes system_prompt and user_prompt. Additional **kwargs arguments reach the provider separately. Configure checks for attachments and other data in these arguments within the calling workflow.

For generate, DLP scans the completed response and applies the masked text prepared by the scanner before returning it to the caller. Response masking applies to detected matches for all action labels, including MASK. For generate_stream, chunks are yielded immediately; after the stream completes, DLP scans the assembled response and records detections. Chunks already delivered retain their original text. To check a response before delivery, use ordinary generation with configured DLP or buffer and filter the stream within the client workflow.

Request scanning is enabled through dlp.enabled and dlp.pre_request.enabled in the security configuration. When scanning is disabled, the provider receives the original prompt text.

get_embeddings also sends texts to a provider. The wrapper combines them for DLP scanning, filters them when a scanner is present, and forwards the prepared texts to target_provider.get_embeddings. The embedding model and route are configured separately from generation. Record the endpoints for both operations in the deployment profile.

What can cross the provider boundary

What can cross the provider boundary
Data	Can be included?	Required control
User request and system instructions	Yes	Purpose limitation, access policy, DLP, and audit.
Selected code snippets or diffs	Yes, when a workflow puts them in a prompt	Data classification, minimum necessary scope, provider/deployment approval, and DLP.
CPG-derived symbols, paths, findings, or summaries	Yes	Treat as potentially sensitive engineering data; minimize and audit.
Secrets, tokens, credentials, and regulated identifiers	Must not be sent intentionally	`BLOCK` or `MASK`, secret management, and an incident path for detections.
Raw repository or database contents	Not sent automatically as a separate attachment	Confirm that no calling workflow has embedded them into either prompt.
Provider response	Returns through CodeGraph	Post-response DLP, audit metadata, and bounded retention.

Deployment profiles

Deployment profiles
Profile	Egress boundary	Operator decision
Local model	The request stays within the configured local inference environment.	Verify host, model storage, logs, and local access controls.
Customer-managed remote provider	Prompts leave CodeGraph for the customer’s approved provider endpoint.	Record endpoint ownership, region, retention, training use, encryption, and incident contacts.
Public SaaS provider	Prompts cross the customer’s infrastructure boundary.	Require explicit data classification and provider approval; restrict source context to the minimum necessary.

A deployment profile connects each workflow to a provider endpoint and its data-handling rules. Use it when configuring routing and checking pilot requests.

DLP behavior

Configure data categories and scanner actions using the DLP guide. The actions work as follows:

BLOCK rejects the request before provider execution.
MASK replaces detected values and forwards the modified prompts.
WARN records the detection but can still allow the request.
LOG_ONLY records the event and allows the request.

When matches are found, the scanner selects the highest-priority action from the matching categories and pre_request.default_action. Priority order is BLOCK, MASK, WARN, LOG_ONLY. For example, a category set to LOG_ONLY with a default action of WARN produces an effective action of WARN.

WARN and LOG_ONLY forward the original text and record the detection. MASK replaces matches from enabled patterns and categories. Configure patterns for each sensitive-data category and verify them with a canary value. Include the context needed for the selected task in each prompt.

Operator checklist

Before enabling a remote provider:

Identify the workflows allowed to call it and the prompt fields each workflow supplies.
Classify source, findings, paths, personal data, credentials, and customer identifiers.
Verify pre-request and post-response DLP in the effective runtime configuration.
Set high-risk categories to BLOCK or an approved MASK policy.
Confirm provider endpoint, tenant, region, retention, training-use terms, encryption, and access logging.
Use a synthetic canary secret to verify that the request is blocked or masked; never test with a real credential.
Confirm that audit records store bounded metadata rather than raw sensitive prompts.
Record the approved profile and evidence in the pilot or release packet.

Incident response

If sensitive content may have reached a provider:

Stop or reroute the affected workflow.
Preserve request identifiers and DLP/audit metadata without copying the raw secret into the incident report.
Rotate exposed credentials and follow the provider’s deletion or incident process.
Determine which prompt builder introduced the content and tighten scope or policy.
Re-run the synthetic canary check before restoring the route.