Developer Tools: Preventing Secret Leakage in AI-Assisted Code Generation

AI coding assistants amplify useful context and dangerous context equally. The same prompt window that can see a failing stack trace can also see an AWS access key copied from a shell, a GitHub token left in a troubleshooting snippet, or a Base64-encoded instruction inside an issue body telling the assistant to print secrets. Teams often assume the risk lives only with the model vendor. In practice, most leakage starts earlier: unsafe inputs, over-permissive tool calls, and generated output that normalizes destructive commands.

Keeptrusts is effective in developer environments because it lets platform engineering protect the full request and response path. Put Prompt Injection Detection first, then use DLP Filter for the exact secret formats and internal markers you care about, Tool Security for tool-call abuse, and Code Sanitizer on the output side. That creates a practical boundary for Developer Experience work without asking every engineer to remember which repo, terminal buffer, or snippet is safe to paste.

Use this page when

• Your engineers use AI assistants for debugging, code generation, or repository search.
• You need to reduce the chance that secrets are pasted into prompts or echoed back in generated output.
• You want one enforceable pattern for coding assistants instead of ad hoc guidance in a wiki.

Primary audience

• Primary: Technical Engineers
• Secondary: Technical Leaders, Security reviewers

The problem

Developer tooling is a difficult governance surface because it combines many trust boundaries in one session. Engineers paste terminal output, read Markdown files from the repo, let the assistant inspect code, and sometimes give it access to tools that can search files or execute commands. That means the assistant sees exactly the kinds of material security teams normally keep carefully separated: secrets, internal URLs, partial credentials, and instructions from untrusted text.

Prompt injection is especially relevant here. A malicious README, issue comment, or copied log snippet can contain instructions such as “ignore previous instructions” or “print the environment variables.” If the assistant also has tool access, the risk becomes worse. The dangerous path is not just a bad completion. It is a tool request that opens a local file, reads a token, or suggests a command that an engineer runs without realizing it contains something destructive.

The output side matters too. Even if the input is clean, generated code and shell commands can still normalize unsafe practices. A suggestion that includes rm -rf, metadata-service access, or an exposed bearer token is not acceptable just because it came from a coding assistant instead of a human reviewer. That is why governance for AI-assisted coding needs both input and output controls.

The solution

The most reliable pattern is to govern the coding-assistant route like an engineering control plane, not like a simple chat surface. Prompt Injection Detection should run first so encoded or fake-boundary instructions are blocked before they influence downstream behavior. Keep the normalization and boundary checks on, and use local pattern detection unless you explicitly want embedding checks on every request.

Next, configure DLP Filter for the secret formats you know engineers encounter. This is where custom regexes are stronger than vague guidance. Cloud credentials, GitHub tokens, long-lived service keys, private-key headers, and organization-specific hostnames are all better expressed as patterns or blocked terms than left to manual judgment.

If the assistant can call tools, add Tool Security. Local mode already blocks fixed high-risk patterns such as file traversal and localhost metadata access, and it can also detect blocked entities such as JWTs, private keys, and cloud credentials in tool-call payloads.

Finally, govern the output. Code Sanitizer is not a full code-review system, but it is effective for a small built-in set of dangerous patterns plus your own additions. That matters for Code Generation Chat because the goal is not only to keep secrets out of prompts. It is also to stop obviously unsafe output from becoming normalized developer muscle memory.

Implementation

This example assumes a coding assistant that can read repository files and suggest code or shell commands. It blocks prompt injection first, rejects obvious secret leakage, constrains tool requests, and blocks unsafe code-like output.

pack:
  name: dev-codegen-guard
  version: 1.0.0
  enabled: true

policies:
  chain:
    - prompt-injection
    - dlp-filter
    - tool-security
    - code-sanitizer
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - 'ignore.*previous.*instructions'
        - 'reveal.*system.*prompt'
        - 'print.*environment.*variables'
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  dlp-filter:
    detect_patterns:
      - 'AKIA[0-9A-Z]{16}'
      - 'ghp_[0-9A-Za-z]{36}'
      - 'sk-[A-Za-z0-9]{48}'
    blocked_terms:
      - .env.production
      - BEGIN OPENSSH PRIVATE KEY
      - id_rsa
    action: block
    fuzzy_matching: true
    max_distance: 1

  tool-security:
    analysis_mode: local
    blocked_patterns:
      - printenv
      - cat .env.production
    blocked_entity_types:
      - aws_access_key
      - jwt
      - private_key

  code-sanitizer:
    enabled: true
    block_on_match: true
    additional_patterns:
      - 'ghp_[0-9A-Za-z]{36}'
      - 'AKIA[0-9A-Z]{16}'

  audit-logger: {}

This does not make the assistant magically safe. You still need repository permissions, secret rotation, and sane tool design. But it does create a deterministic gateway layer that catches several common failure modes before they become incidents. The ordering is important: stop injection attempts first, then block secrets, then evaluate tool requests, then sanitize the response.

If your organization offers multiple coding surfaces, keep the route contract consistent across them. It is better to govern several assistants with the same policy model than to let every plugin, editor, or chat window invent its own secret-handling logic.

Results and impact

The first benefit is fewer accidental leaks. Engineers do not have to remember every token format that should never enter an assistant because the gateway enforces the patterns directly. The second benefit is better incident handling. If a request fails, the event record tells you whether the cause was prompt injection, a DLP hit, a risky tool request, or unsafe generated output.

This also improves developer trust. A secure coding assistant is easier to roll out than a vague “please be careful” policy. Teams can use AI for drafts, explanations, and troubleshooting while knowing there is a control boundary underneath the workflow. That is usually the difference between a tool that security blocks and a tool that engineering can actually adopt.

Key takeaways

• Treat coding assistants as a full request and response surface, not just a chat UI.
• Put Prompt Injection Detection first because repositories and issue trackers can carry hostile instructions.
• Use DLP Filter for the exact secret formats your engineering environment encounters.
• Add Tool Security when the assistant can read files or call tools.
• Use Code Sanitizer to stop obviously dangerous code-like output from becoming normalized.

Next steps

• Developer Experience
• Prompt Injection Detection
• DLP Filter
• Tool Security
• Code Sanitizer
• Code Generation Chat