Skip to main content

Trade Secret Protection: Preventing IP Leakage Through AI Systems

Trade Secret Protection: Preventing IP Leakage Through AI Systems

Trade secrets usually leak through convenience, not malice. An engineer pastes a debugging transcript that contains internal algorithm names. A product manager asks for a summary of an unreleased roadmap memo. A legal team requests a cleaner draft of a confidential licensing analysis. None of those requests look like classic personal-data incidents, yet each can expose the information that actually creates enterprise value. Keeptrusts helps treat those prompts as governed traffic instead of as harmless productivity requests.

Use this page when​

  • Your teams use AI with source code, research notes, unreleased product plans, pricing models, or confidential legal drafts.
  • You need controls for proprietary information that is not covered by standard PII policies.
  • You want the gateway to block dangerous IP disclosures before they reach a provider.

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, security and legal stakeholders

The problem​

Trade-secret programs often fail in AI because teams lean on the wrong control. PII detection is necessary for personal data, but trade secrets are rarely obvious emails or SSNs. They are project codenames, formula references, source paths, merger workstreams, unreleased designs, and negotiation language that only your organization recognizes.

There is also a workflow problem. High-value IP is usually mixed with ordinary business text. A product planning prompt can contain employee names, customer account references, legal privilege markers, and a line about an unreleased semiconductor mask. If the control surface only recognizes one of those categories, the rest of the prompt still leaves the organization.

Finally, provider routing matters more than many teams admit. Even a sanitized prompt can still reveal sensitive strategy if it reaches a provider lane with the wrong retention or training posture. Trade-secret protection therefore needs both content controls and a constrained upstream route.

The solution​

Use DLP Filter as the primary trade-secret control because it is designed for your configured regexes and blocked terms. This is where you encode codenames, structured internal identifiers, and phrases such as acquisition-room labels or restricted engineering terms that should never leave your environment.

Pair it with PII Detector because many IP-heavy prompts also contain employee or customer data. There is no reason to let those identifiers travel upstream when the business task can succeed without them.

Then use Data Routing Policy to restrict the provider pool to targets that declare zero retention, no training, and other handling guarantees you require for IP-sensitive traffic. If legal-review or litigation materials are part of the same workflow, add Legal Privilege to block output that contains configured privilege markers.

Implementation​

This configuration blocks common trade-secret patterns while still allowing sanitized requests to use a compliant model lane:

pack:
  name: trade-secret-guard
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: ip-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

policies:
  chain:
    - dlp-filter
    - pii-detector
    - data-routing-policy
    - audit-logger
    - legal-privilege

policy:
  dlp-filter:
    detect_patterns:
      - 'ALGO-[A-Z]{3}-[0-9]{4}'
      - 'FORMULA-[0-9]{6}'
      - 'CAD-[A-Z0-9]{8,16}'
    blocked_terms:
      - Project Helix
      - unreleased silicon mask
      - customer bid matrix
      - merger room memo
    action: block
    fuzzy_matching: true
    max_distance: 1
    sensitivity_level: restricted

  pii-detector:
    action: redact
    healthcare_mode: false
    pci_mode: false
    detect_patterns:
      - 'EMP-[0-9]{6}'
      - 'ACCT-[0-9]{8,12}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-INTERNAL-ID]"

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    sanitize_before_provider: true
    tokenize_sensitive_fields: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

  legal-privilege:
    privilege_markers:
      - attorney-client privilege
      - work product
      - for legal review only
      - settlement draft

The reason this works is that each policy owns a different slice of the risk. dlp-filter blocks organization-specific IP markers. pii-detector removes ordinary personal identifiers that do not need to travel with the request. data-routing-policy constrains the provider path for the requests that remain. legal-privilege catches a separate but related output risk when legal material is involved.

In practice, rollout is easiest when you begin with a small, high-confidence term list instead of trying to enumerate every secret in the company. Start with the codenames, workstream labels, and structured identifiers that would clearly trigger a serious incident if they appeared in model traffic. Then inspect the governed event stream and expand deliberately.

Results and impact​

The immediate impact is fewer accidental disclosures of proprietary content. Engineers and operators stop treating any prompt that lacks obvious PII as safe by default. Instead, the gateway distinguishes between a harmless summary request and a request that contains internal formulas, unreleased designs, or sensitive negotiation language.

There is also a review benefit. Because Keeptrusts records blocked and redacted outcomes in the event stream, legal and security teams can inspect how often IP-sensitive prompts are being stopped and whether any route remains that needs tighter controls.

Key takeaways​

  • Trade-secret protection in AI depends on custom DLP, not only generic personal-data detection.
  • DLP Filter is the right control for codenames, formulas, unreleased design labels, and other organization-specific IP markers.
  • PII Detector still matters because proprietary prompts often include employee and customer context.
  • Data Routing Policy prevents sanitized IP traffic from drifting into a provider lane with the wrong handling guarantees.
  • Legal Privilege is useful when trade-secret workflows overlap with legal drafts or privileged analysis.

Next steps​