Skip to main content

Preventing Material Non-Public Information Leakage in Investment Banking AI

The practical answer is to move MNPI enforcement to the gateway instead of trusting prompt templates, user training, or model instructions to do the job. In Keeptrusts, that usually means requiring caller identity with rbac, blocking firm-specific deal language with dlp-filter, redacting obvious identifiers with pii-detector, constraining which upstream providers can receive traffic with data-routing-policy, and using mnpi-filter as an output-side stop for phrases that should never leave the model. That stack does not replace legal walls, surveillance, or banker judgment, but it gives operations and compliance teams a deterministic control point before content leaves the bank.

Use this page when​

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, AI Agents

The problem​

Investment banking AI leaks usually happen in ordinary workflow moments, not dramatic ones. An analyst pastes a deal memo into a drafting assistant. A sector banker asks a model to summarize a board update for an internal email. A research workflow blends public filings with confidential diligence notes. By the time anyone notices that the prompt or response crossed a line, the content may already have been sent to an upstream provider, echoed into downstream tools, or copied into a note that looks authoritative because it came from an assistant.

That is why operator teams should be precise about what Keeptrusts can and cannot do today. The current MNPI Filter is an output-phase phrase matcher. It is useful, but it is not a universal detector for every form of confidential finance context and it does not inspect prompt text in the same way a DLP control does. If a banker pastes unreleased financials, pending acquisition details, or a client-specific valuation model into the prompt, you need input controls such as dlp-filter, pii-detector, and identity checks to catch those issues earlier.

The second problem is routing. Global banks often need different execution paths for UK, EU, and US teams, or for internal versus client-facing workflows. Keeptrusts supports provider filtering with Data Routing Policy, but the real operating model is architectural: region-specific gateways plus provider data_policy metadata. In other words, multi-jurisdiction routing is a deployment pattern backed by gateway policy, not a single magic toggle.

The third problem is evidence. Compliance officers do not just ask whether you blocked one bad response. They ask what policy version was active, which desk sent the request, why the gateway allowed or blocked it, and how quickly you can reconstruct the affected period. That is where the platform event stream, exports, and Spend & Wallets model matter. If a desk launches a new assistant without budget or control ownership, you have a governance problem even before you have a leakage problem.

The solution​

The workable pattern is to split the control stack into four layers.

First, enforce who is calling the gateway. rbac gives you a place to require headers like X-User-ID, X-User-Role, or a desk identifier. That does not solve authorization by itself, but it prevents anonymous or weakly attributed traffic from sharing the same assistant path as restricted desks.

Second, treat deal codes, client IDs, internal codenames, and valuation artifacts as input-side data loss concerns. dlp-filter works on the patterns and blocked terms you configure. pii-detector can redact or block structured identifiers and custom regexes. For investment banking, this is usually more useful than hoping an output-only MNPI guard will catch prompt-side mistakes.

Third, keep sensitive flows off non-compliant provider targets. The Data Routing Policy can exclude targets that do not declare zero-data-retention, training opt-out, or other operator-defined data policy metadata. That is the technical layer that supports multi-jurisdiction and restricted-routing programs.

Fourth, use mnpi-filter and financial-compliance as output controls, not as your whole compliance story. mnpi-filter is good at catching known phrases that should not appear in model output. Financial Compliance gives you a practical place to block or rewrite finance-advice language on client-facing or banker-assist surfaces where recommendation-style phrasing is not allowed.

Implementation​

The following draft is intentionally conservative. It uses only fields that are documented for the current gateway runtime and keeps the audit-logger block minimal because event persistence and retention are platform capabilities, not policy-local enforcement knobs.

pack:
  name: investment-banking-mnpi-guard
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: eu-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
    - id: us-zdr
      provider: openai
      model: gpt-5.4-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0

  routing:
    strategy: ordered

policies:
  chain:
    - rbac
    - dlp-filter
    - pii-detector
    - data-routing-policy
    - mnpi-filter
    - financial-compliance
    - audit-logger

policy:
  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role
      - X-Desk-ID
    require_auth: true

  dlp-filter:
    blocked_terms:
      - Project Redwood
      - pending acquisition
      - board decision
    detect_patterns:
      - 'DEAL-[0-9]{6}'
      - 'MANDATE-[A-Z0-9]{8}'
    action: block

  pii-detector:
    action: redact
    detect_patterns:
      - 'CLIENT-[A-Z0-9]{8}'
    redaction:
      marker_format: label
      include_metadata: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block

  mnpi-filter:
    detect_patterns:
      - earnings before announcement
      - merger not public
      - insider information
      - board decision

  financial-compliance:
    blocked_patterns:
      - guaranteed return
    required_disclaimers:
      - This is not financial advice.

  audit-logger: {}

There are two practical details worth calling out.

The first is that your most valuable dlp-filter terms will be firm-specific. Public docs can show placeholders like Project Redwood, but your real value comes from codenames, list names, internal identifiers, and phrases your surveillance or legal teams already track. The Finance page is a good starting point for the policy chain, but your local blocked terms are what make it operational.

The second is that mnpi-filter should be tuned as a last output gate, not the only bank-grade control. If you want to validate the config before rollout, use the same operator loop you would use for any high-sensitivity policy change:

kt policy lint --file ./policy-config.yaml
kt gateway run --policy-config ./policy-config.yaml --port 41002
kt events tail --policy mnpi-filter
kt export create --format json --filter "policy=mnpi-filter,audit-logger"

Results and impact​

The immediate impact is not that every confidentiality risk disappears. The real improvement is that restricted workflows stop depending on hope.

  • Prompt-side mistakes are more likely to fail closed because desk identity, deal codes, and custom restricted terms are evaluated before the upstream model call.
  • Output-side mistakes are easier to explain because mnpi-filter and financial-compliance produce explicit policy outcomes instead of ad hoc moderator decisions.
  • Multi-jurisdiction routing becomes reviewable because provider eligibility is declared and enforced through data_policy metadata rather than tribal knowledge.
  • Desk-level ownership becomes easier to enforce when you pair restricted assistants with Spend & Wallets, so a new assistant cannot quietly become both a data-risk surface and a budget sink.

For operations teams, the biggest gain is reproducibility. When compliance asks how the restricted M&A assistant differs from the public research assistant, you can point to the policy chain, the provider constraints, the desk headers, and the event export. That is a stronger answer than "we trained users not to paste confidential material."

Key takeaways​

  • Treat MNPI Filter as an output guard, not a full prompt-side leakage program.
  • Use dlp-filter and pii-detector for the internal codes, identifiers, and prompt content your bankers actually paste into assistants.
  • Use Data Routing Policy with region-specific gateways and declared provider metadata for multi-jurisdiction routing.
  • Keep the audit story simple: minimal audit-logger config, reliable events, and tested exports.
  • Pair sensitive desk rollouts with Spend & Wallets so governance includes both risk and cost ownership.

Next steps​