Operate CodeGraph data-loss prevention

CodeGraph DLP inspects selected content before it is sent to a model provider and after a provider response is received. It can block, mask, warn, or record a match. Secure sensitive workflows with DLP together with repository access control, provider contracts, network policy, secret management, and human review.

Control boundary

The maintained implementation is split across:

• src/security/config.py — typed DLP policy and action configuration;
• src/security/dlp/scanner.py — request and response scanning;
• src/security/dlp/actions.py — action handling;
• src/security/dlp/webhook.py — optional alert delivery;
• src/security/llm/secure_provider.py — the protected model-provider boundary;
• config.yaml under security.dlp — deployment defaults and environment references.

The API exposes authenticated DLP configuration, policy, and activity operations under the live /api/v1/security/dlp surface. Consult the deployed OpenAPI schema for request and response fields.

Actions and meaning

The highest applicable action wins when several patterns match. A configured WARN or LOG_ONLY policy records the match and allows the configured flow to continue; use the deployment’s access, network, provider, and review controls to manage egress.

Configure policy

The checked-in configuration has separate pre_request and post_response controls plus category, keyword, and webhook settings. The default categories include credentials, PII, and source-code signals; the exact pattern set comes from the installed src/security/config.py, not from a frozen count in this guide.

For each deployment, document:

• whether global security and DLP are enabled;
• which categories are enabled and their action and severity;
• approved keyword lists and their owner;
• pre-request and post-response default actions;
• webhook endpoint ownership, secret reference, timeout, retry, and notification actions;
• exception, expiry, review, and rollback process.

Do not weaken a policy only to make a test prompt succeed. Use a synthetic marker to validate the configured branch and remove it after the test.

Request and response flow

Before a protected model call, CodeGraph scans the system and user prompt through the configured pre-request policy. BLOCK stops the call; MASK forwards modified content; WARN and LOG_ONLY can still allow the original content to reach the selected provider.

After the provider returns, post-response scanning applies its own policy before the response is returned through the protected surface. Review both directions when deciding what data may leave or re-enter the customer boundary. See LLM security for the complete egress model.

Alerts and SIEM

DLP can create webhook alerts and maps actions to SIEM event types including dlp.block, dlp.mask, dlp.warn, and dlp.log. These are separate outcomes:

1. the scanner detected a match;
2. the action changed or allowed content;
3. the dispatcher accepted an event;
4. a configured handler reported delivery;
5. the downstream webhook or SIEM actually received and indexed it.

Confirm downstream receipt through handler status, retry or buffer state, and receiver-side evidence when delivery is an acceptance criterion. The local alert_sent flag and HTTP intake status record local processing state.

Validate the deployment

Use non-sensitive synthetic values for each enabled category:

1. record the effective policy and release revision;
2. submit a prompt expected to pass and one expected to match;
3. verify the selected action and whether the provider call occurred;
4. verify masking in the returned or forwarded content without logging the original secret;
5. inspect authenticated DLP activity;
6. verify webhook or SIEM receipt where configured;
7. restore the approved policy and record the result.

Test pre-request and post-response independently. Run the scenario again after provider, policy, pattern, or security-profile changes.

Limits and incident handling

Pattern matching can miss transformed, fragmented, encoded, domain-specific, or previously unseen sensitive data and can also produce false positives. Keep source access, least privilege, provider egress restrictions, secret scanning, and human approval as independent controls.

On a suspected leak, stop the affected workflow, preserve secret-free audit evidence, rotate the exposed credential if applicable, identify provider and receiver scope, and follow the customer incident process. Policy changes made during recovery must have an owner, reason, review, and expiry.