Why is an analyst's AI use a recordkeeping problem?

Because a prompt to a model is a business communication that the firm cannot see or retain when it runs through an unsupervised tool. SEC Rule 17a-4 retention, FINRA Rule 4511 recordkeeping, and FINRA Rule 3110 supervision all assume the firm can answer what was communicated, by whom, and where the record is. An analyst pasting client or non-public data into a public model produces exactly the kind of communication those rules govern, in a channel most compliance stacks do not capture.

How does MNPI end up in a model prompt?

Usually by accident, inside otherwise routine work. An analyst pastes a research note to get a summary and the note contains non-public issuer detail, or exports holdings to draft a memo and the export carries client identifiers. The intent is a quick task and the prompt carries regulated content along with it. Classifying the outbound prompt at the model boundary is what catches the MNPI or client data before it reaches the model.

Does the firm's DLP cover this?

Generally not at the prompt layer. Network DLP reads traffic beneath TLS and classifies documents, while an analyst's prompt is an encrypted API payload carrying a context window. The appliance sees an HTTPS call to a provider and cannot read the non-public content inside unless TLS is terminated for that domain and the body is parsed. The regulated data leaves in a layer the existing tool was not built to inspect.

What does the audit record need to contain?

Enough to satisfy a supervisory review: the analyst identity, the class of data in the prompt, the pass, block, or redact outcome, the policy in force, and the time. Committed on a write path the analyst's tool does not control, that record lets the firm show which analyst sent which class of data to which model, which is the evidence a retention and supervision obligation expects for any business communication.

AI Security for Financial Analysts: Governing What Reaches the Model

A financial analyst using AI sends the firm's most sensitive material into a prompt as a matter of routine. Summarize this research note. Check the assumptions in this model. Draft a memo from these holdings. Each request is an HTTPS POST to a model endpoint, and the body can carry client positions, non-public financial data, or material non-public information about an issuer. The output moves the work forward. The request is regulated information leaving the firm through a channel the compliance stack was not built to supervise.

Two things make an analyst's model call different from a general employee's. The data class is often MNPI or client non-public personal information, where the consequences of an uncontrolled disclosure are legal, not only reputational. And the activity sits inside a recordkeeping and supervision regime that expects the firm to know what its people communicated and to retain the evidence.

The recordkeeping and supervision backdrop

Broker-dealers operate under SEC Rule 17a-4 retention requirements and FINRA Rule 4511 recordkeeping, and under FINRA Rule 3110, which requires a supervisory system reasonably designed to achieve compliance. Regulation S-P governs the handling of customer non-public personal information. None of these rules names a chatbot, and all of them assume the firm can answer a basic question: what business communication occurred, by whom, and where is the record. An analyst pasting client data into an unsupervised model produces a communication the firm cannot see or retain, which is the gap these rules were written to close in every prior channel.

Draw the boundary around the model call

A gateway governs the HTTP traffic between the analyst's AI tools and the model. It does not govern the order management system or the analyst's local spreadsheet.

Inside the boundary:

The AI tool's HTTP call to the LLM, carrying the prompt.
The model's response returning to the tool.

Outside it:

Trading and order management systems, which have their own controls.
A spreadsheet the analyst builds locally and never sends to a model.

The gateway controls what leaves for the model and which analyst sent it. Supervision of trading activity itself is a separate system.

Bind each call to an analyst identity

A shared desk key to the model erases attribution. Every analyst's prompt reaches the model as one credential, so the firm cannot tie a disclosure of MNPI to the person who sent it, which is precisely what a supervisory review needs. Route calls through the gateway and bind each to the analyst identity from the firm's directory. Policy can then apply to role and desk, and every prompt carrying regulated data names an individual, which is the identity context a banking model-risk and supervision program already assumes elsewhere.

Classify MNPI and client data in the prompt

An analyst rarely sets out to send MNPI to a public model. It happens when a research note pasted for summarization contains non-public detail, or a holdings export carries client identifiers. The gateway classifies the outbound prompt against MNPI markers and client-NPI patterns, and applies policy on the class, so a call asking for a general summary is allowed while a call carrying non-public issuer detail or client identifiers is blocked or redacted before it reaches the model. Classification runs on the actual prompt, not on a document labeled once, because the analyst assembled the context by hand.

Constrain egress and retain the decision record

Restrict egress from the analyst tooling so the only route to any model endpoint runs through the gateway, which stops a personal key from bypassing policy. Every call then produces a decision record: the analyst identity, the data class in the prompt, the outcome, the policy version, and a timestamp. That record commits before the response returns, on a write path the tool does not control, and it is the artifact a supervision and retention obligation expects for a business communication. When an examiner or an internal review asks what client or non-public data reached which model and under whose authority, the record answers per call.

DeepInspect

This is the problem DeepInspect was built to solve. An analyst's AI tools send regulated financial data to LLMs over HTTP, and DeepInspect sits inline at that boundary between those tools and the model endpoints they call.

For every request, DeepInspect binds the call to the analyst identity the application supplies, classifies the prompt against MNPI and client-NPI patterns, applies per-role and per-desk policy, and makes a deterministic, fail-closed decision before the data reaches the model. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the tool never controls, which is the retained evidence a supervision regime expects. DeepInspect governs the model traffic and does not supervise the trading systems, which keep their own controls. If your analysts are sending research and holdings into models and you cannot retain what left, let's talk today.