How to Prevent MNPI in LLM Prompts at a Broker-Dealer

Start by mapping where MNPI can enter a prompt

Policies, training and after-the-fact review do not stop a specific prompt from carrying MNPI at the moment it is sent. The control has to operate on the interaction itself, so the first task is an inventory of paths into a model.

A broker-dealer may receive MNPI through transaction work and from sources that provide confidential information on an ongoing basis. That information can then reach a model in several ways. Employees paste deal details, restricted-list names, unreleased earnings or client order details into a chat interface. Retrieval pipelines pull internal documents into context without the user ever typing the sensitive text. Coding assistants send source files, configuration and test data. Agents make tool calls whose outputs return into the model context. Employees may also use third-party AI sites that the firm does not operate.

OWASP guidance on LLM applications makes the same structural point: retrieved documents, tool output, web pages and email bodies are inputs to screen, not only user text. Record, for each path, who can use it, which model or tool it reaches, and which MNPI categories could plausibly appear.

• User chat to internal or third-party assistants
• Retrieval over internal documents
• Coding assistants
• Agent and tool calls, including tool output
• Third-party AI sites

Choose detection methods per entry point

No single detector covers every path. Combine methods and weight them by what the path exposes.

Restricted-list matching uses names maintained by Compliance. In published firm practice, Compliance adds issuers to a Restricted List when MNPI is identified and maintains the lists, which makes the list a compliance-owned data source a matching rule can consume. Define how quickly list changes take effect, since a stale list is a gap.

Entity and pattern detection finds identifiers, tickers, deal code names, account numbers and figures that resemble unreleased financials. Classification labels carry sensitivity from source systems, so a retrieved document tagged as deal material can be handled without reading its content. Context-based rules use who is asking, whether that person is wall-crossed, and which destination model or tool is involved. This last method applies the need-to-know principle that SEC staff describe as an important part of an information barriers program.

• Restricted-list matching: Best for chat and tool calls where named issuers appear in text.
• Entity and pattern detection: Useful for identifiers and figures, with higher false-positive risk.
• Classification labels: Most reliable for retrieval, provided source documents are labeled.
• Role and wall-crossed context: Decides who may send which category to which destination.

Place enforcement in the execution path

Enforcement should sit between the requester and the model, and between tool output and the model context. A control that only observes traffic can report a leak but cannot stop it. A pre-model check lets the decision change what the model receives.

Content screening is not enough on its own. OWASP describes classifier-based screening as one layer, not a complete defense, and recommends controls that do not depend on the language of the text: tool permissions, parameter validation and least privilege. For agents, restrict which tools a role can call and which parameters are valid, so that a missed detection still cannot reach a restricted system. Apply data sanitization before any data can reach a model training path.

Trussed is one example of this pattern. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls, with allow, redact, block and escalate for human approval, and it produces audit-ready evidence from those decisions. Insurance is where Trussed is deepest, and this guide does not claim financial-services deployments. The design requirements above apply whichever tooling a firm selects.

Map actions to MNPI scenarios

Choose the least disruptive action that still protects the barrier, and decide in advance what happens when detection is uncertain. The mappings below are starting points for Compliance to adjust.

• Allow: No MNPI indicators, or the role is wall-crossed and the destination is approved for that deal. Record the decision anyway.
• Redact: Incidental identifiers such as a client name or order detail that the task does not need. Replace before the prompt leaves the firm.
• Block: A restricted-list issuer sent by a public-side user, or labeled deal material headed to an unapproved third-party site.
• Escalate for approval: Legitimate need with ambiguous status, such as a wall-crossed team using an external model. A compliance owner decides before release.

Understand the limits of detection-based controls

Detection will produce false positives and false negatives, and neither can be eliminated. Paraphrased deal descriptions, code names, partial figures and context spread across several prompts can all evade matching. Broad rules block legitimate work, which pushes users toward unmanaged tools and defeats the control.

Treat the control as risk reduction, not guaranteed prevention, and say so in model risk and supervisory documentation. Measure false-positive and false-negative rates on the firm's own data rather than relying on generic accuracy claims. Use sampling and review of allowed prompts to find misses, and feed findings back into rules and lists.

Set a default for uncertain cases per entry point. Escalation suits low-volume, high-stakes paths such as agent tool calls into deal systems. Redaction or block may suit high-volume chat. Reconcile these rules with existing over-the-wall procedures and surveillance, so wall-crossed teams are treated consistently across AI and non-AI channels.