Skip to main content

LLM data egress and security controls

Understand which CodeGraph prompt data can reach an LLM provider and configure DLP, routing, audit, and deployment controls for that boundary.

Enterprise

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 current boundary is implemented in src/security/llm/secure_provider.py:

  1. The caller supplies system_prompt, user_prompt, operation context, and provider settings.
  2. Prompt governance resolves the active policy and approval state.
  3. Pre-request DLP scans the combined prompts.
  4. The active DLP action may BLOCK, MASK, WARN, or LOG_ONLY.
  5. AI FinOps routing selects the target provider.
  6. The runtime calls target_provider.generate(system_prompt, user_prompt, **kwargs) with the filtered prompt values.
  7. Post-response DLP scans the provider response before it is returned.

If pre-request DLP is disabled in the effective configuration, the scanner does not remove data from the request. Operators must verify the effective runtime profile instead of relying on this page alone.

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.

Selecting a provider changes the data-processing boundary. A deployment statement is valid only for the profile actually running in the customer environment.

DLP behavior

The ContentScanner uses the effective configuration from src/security/config.py and src/security/dlp/scanner.py.

  • 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.

WARN and LOG_ONLY are not redaction. MASK depends on the patterns and categories currently enabled. Unknown sensitive data can remain undetected, so repository scope and prompt construction remain primary controls.

Operator checklist

Before enabling a remote provider:

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

Incident response

If sensitive content may have reached a provider:

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

Source references

  • src/security/llm/secure_provider.py
  • src/security/dlp/scanner.py
  • src/security/config.py
  • src/llm/interface.py
  • src/api/services/dashboard/security_core/security_dlp.py

See also DLP Security and SIEM.

Report a documentation issue