DLP for AI Prompts on the Developer Machine

The developer machine is the first useful control point

Data loss prevention for AI coding tools should make a decision before sensitive input leaves the developer machine. That sounds simple, but coding assistants do not use one network path. A prompt may go through a browser, an IDE, a command-line client, a vendor endpoint, a customer-managed endpoint, or an MCP server. An agent can also read a file or environment variable after the initial prompt. A proxy sees only the traffic routed through it.

An endpoint control operates closer to intent. A provider hook or plugin can identify the event as a prompt submission, file write, shell call, or MCP tool invocation. It can apply repository and organization context before the tool acts. It can also keep the matched text local and emit only a policy outcome. This does not make proxies unnecessary. It gives the organization a control point for local and multi-provider workflows that a single gateway cannot cover.

Why proxy-only DLP has blind spots

• Direct vendor traffic may not use the organization proxy, especially from personal accounts or user-installed tools.
• Local stdio MCP servers communicate through processes and pipes rather than a central HTTP gateway.
• An agent can read a secret from a file or tool result after the visible prompt was submitted.
• TLS and vendor-specific payloads can remove the context needed to distinguish a prompt from another request.
• Remote or server-side agents may require vendor controls because no local endpoint hook sees their execution.

The correct architecture is layered. Use endpoint hooks for supported local assistants, an MCP proxy for opted-in local stdio servers, vendor administration for hosted surfaces, and network controls for destinations that should never be reached. Record which layer made the decision. A dashboard that combines these sources must not imply endpoint enforcement on a surface that only produced a network observation.

A local scan should minimize what it retains

When a supported hook exposes input before execution, the agent scans that input in memory for defined secret and personal-data patterns. Examples include cloud access keys, source-control tokens, private-key blocks, payment credentials, validated card numbers, IBANs, and carefully bounded high-entropy strings. Context and validators matter because an overbroad expression can interrupt ordinary code and train developers to ignore warnings.

The scanner needs the matched bytes to make a local decision, but the service does not. A privacy-safe finding contains a pattern identifier, count, surface, and salted match fingerprint used for deduplication. The salt prevents the server from testing a short candidate value against an unsalted hash. The event can also carry provider, repository state, session, time, and policy outcome. The original secret, prompt, command, and file content stay on the machine.

Warn, redact, and block are different promises

A warning tells the developer what class of sensitive data was detected and asks for correction. It is the safest fallback when a provider exposes the event but cannot replace or stop it. A warning must be shown before the action when the integration supports that timing. If the warning arrives only after submission, the product should label it as detection, not prevention.

Redaction replaces only the detected byte ranges with a marker such as [REDACTED:github_token] and lets the action continue. It preserves more of the workflow than a block, but it requires a provider interface that accepts rewritten input. Support differs by surface. A tool may allow rewriting file-write or shell arguments while offering no way to rewrite the submitted prompt. The policy engine must evaluate the exact provider, hook, and surface before claiming redaction was enforced.

A block prevents the prompt or tool call and gives the developer a reason. It is appropriate for credentials and restricted data when the provider honors a denial. Some integrations can block tool calls but not prompts; others provide detection only. MainLayer records the desired action separately from enforcement status, using values such as enforced, warn-only, observe-only, or unsupported. That distinction prevents a configured block from becoming a false assurance.

Policy context makes the scanner useful

A scanner alone can only say that a pattern matched. Policy supplies scope and action. An organization can select secret patterns and surfaces, then scope a rule to the organization, a team, a repository, a repository-name pattern, or a user. A sensitive repository can require metadata-only handling or restrict providers and models. The most restrictive matching action wins unless an active exception applies.

Start new rules in log mode and simulate them against recent metadata where possible. Review false positives, affected providers, and enforcement capability before moving to warn, redact, or block. Roll out high-confidence credential patterns first. Personal-data patterns need particular care because source code legitimately contains email validation, test fixtures, localization examples, and numeric identifiers. Validation and threshold rules reduce noise.

Build an audit chain without collecting the secret

The audit record should answer who changed the policy, which version reached the endpoint, what rule matched, what action was requested, whether the provider honored it, whether an exception applied, and whether a message was shown. It should not reproduce the sensitive text. Administrative writes belong in the same transaction as their audit event so a policy cannot change without its corresponding record.

For stronger integrity, order audit events per organization and chain each row to the previous row with a cryptographic hash. Exported CSV or JSONL can include sequence and hash fields, and a verification endpoint can recompute the chain and report the first mismatch. The chain helps detect alteration of the audit history. It does not prove that an unsupported provider enforced an action, which is why enforcement status must remain part of the event.

Access is part of the audit design. DLP summaries can be useful at team or organization level without exposing individual identities. Person-level views should be role gated, organization scoped, and logged when they reveal someone other than the requester. Small aggregates may need suppression. These controls reduce the risk that a security program becomes an employee-monitoring system.

Failure modes and safe defaults

Endpoint software will sometimes be offline, outdated, or unable to reach the control plane. Provider hooks also have strict response budgets. MainLayer hooks fail open on timeout so an agent outage does not unexpectedly halt development, and they spool privacy-safe events for later upload. Organizations with a fail-closed requirement should verify whether the provider itself supports that mode and understand the availability tradeoff before enabling it.

Never log hook input while debugging DLP. Diagnostics should contain redacted configuration, health, counters, file names where safe, and privacy-safe log lines, not prompts or file contents. Server validation should reject content-bearing event fields when the organization is in metadata-only mode. This defense in depth limits the effect of a faulty or outdated client.

A staged deployment plan

1. Map assistants, account types, repositories, data classes, and provider enforcement capabilities.
2. Deploy in metadata-only observe mode and confirm event coverage without collecting matched text.
3. Enable warnings for high-confidence secret patterns and publish a clear remediation message and policy contact.
4. Test redaction per provider and surface with synthetic credentials. Downgrade honestly where rewriting is unavailable.
5. Enable blocks for selected credentials and restricted scopes after reviewing false positives and timeout behavior.
6. Review findings, exceptions, policy versions, audit-chain integrity, and unsupported surfaces every month.

Success is not the largest possible finding count. It is a smaller exposure window, fast secret rotation when prevention fails, fewer repeat findings, and a clear path for developers to complete legitimate work. On-device DLP supports that outcome because it can act at the coding surface while sending the control plane only the evidence needed to govern the system.