AI Data Protection in Capital Markets Starts Before Model Transmission
SEC safeguards rules require covered institutions to protect defined customer information and supervise service providers. FINRA also expects generative AI governance to address data privacy and integrity. This article maps those duties to the model request path, where identity, classification and destination policy can stop protected data before transmission.

A research application sends an HTTPS request to an LLM endpoint. Inside the request body sits a customer portfolio, an unpublished allocation change or account correspondence. TLS protects the connection, but the request can still reach a provider that the firm never approved for that class of information. AI data protection capital markets controls have to make the identity, content and destination decision before transmission.
The regulatory sources already describe the objective. SEC safeguards rules protect defined customer information. FINRA expects supervision of generative AI to address data privacy and integrity. Neither source prescribes an AI gateway, so the architecture remains the firm's decision.
TL;DR
- SEC Regulation S-P requires covered institutions to maintain safeguards for defined customer information and oversee relevant service providers.
- FINRA says existing technology-neutral obligations continue to apply to proprietary, third-party and embedded generative AI.
- A routed HTTP control can classify prompt content, bind it to an authenticated principal and enforce an approved model destination before transmission.
- Browser sessions, local inference, vendor-internal model calls and routing bypasses sit outside that control boundary.
Regulation S-P protects a defined information set
SEC Regulation S-P section 248.30 requires covered institutions to maintain written administrative, technical and physical safeguards designed to protect customer information. Those safeguards address confidentiality, anticipated threats and unauthorized access or use that could cause substantial harm or inconvenience.
The rule's definitions determine which information falls within scope. A covered institution includes specified brokers, dealers, investment companies, investment advisers and transfer agents. Customer information is a defined regulatory category, so a firm should resist labeling every prompt as a Regulation S-P record. Classification has to start with the institution, the person and the data involved.
A practical inventory maps each approved AI use to the information it can receive. AI governance for capital markets covers the ownership and approval process. The protection design then enforces the result on each covered request.
FINRA puts data privacy inside supervision
FINRA Regulatory Notice 24-09 states that securities laws and FINRA rules continue to apply when member firms use generative AI or similar technologies. Its Rule 3110 discussion says a firm's supervisory system must be reasonably designed for its business. Policies for generative AI used in that system should address technology governance, including model risk management, data privacy and integrity, reliability and accuracy.
That expectation reaches proprietary tools, third-party products and embedded functions. A writing assistant inside a research platform deserves the same data-flow analysis as a standalone model API when it receives firm information.
Vendor approval alone gives an incomplete answer. The operational question is narrower: was this authenticated analyst permitted to send this class of information to this particular endpoint under the policy active at that moment? AI vendor risk in capital markets addresses diligence. Request policy controls actual use after approval.
The control belongs before the outbound request
A content inspection performed after the provider responds documents a transmission that already happened. Protection requires a decision on the outbound request. The application supplies the authenticated user or workload identity. The enforcement point classifies the request body, resolves the model destination and applies policy for that role, use case and data class.
Picture a deal-team analyst with a printed restricted list beside the keyboard and a draft prompt open on screen. One issuer code name appears in both places. An approved general research assistant may accept public filings, while policy blocks the restricted-list reference or routes it to an authorized private endpoint.
I would reject any capital-markets control description that treats an allowlist of model hostnames as data protection. A hostname says where traffic goes. It says nothing about the customer or deal information inside the request.
AI policy enforcement at the HTTP layer explains the decision point in more detail.
Data minimization applies to protection records too
The security record should prove what the control did without creating a second repository full of prompts. Useful fields include the authenticated principal, business route, content classification, resolved provider, policy reference, outcome, timestamp and correlation identifier. A controlled hash or protected reference can link the event to content held in an appropriate system.
Full prompt retention may be justified for a defined workflow, but it needs its own access, retention and disposal analysis. Copying customer correspondence or deal text into a broadly accessible observability platform expands the sensitive population.
The same discipline applies to model responses. A response that reproduces protected input, combines customer facts or returns restricted content may need inspection before the application displays or stores it. Keep the transmission decision and the business record connected without confusing the two. AI audit trails in capital markets covers the evidentiary relationship.
Service-provider controls continue after contracting
The SEC safeguards rule requires due diligence and monitoring for service providers that receive, maintain, process or gain permitted access to customer information while serving the covered institution. Contracts and assessment reports establish part of that oversight. Runtime routing records show which provider actually received a request.
The rule also contains provider notification duties for qualifying breaches, including notice to the covered institution as soon as possible and no later than 72 hours after awareness under the stated conditions. That timing applies to the provider-to-institution notice described by the rule. It should never be generalized into a deadline for every anomaly or blocked request.
Incident preparation should join the provider inventory to the request population. A correlation identifier can help investigators find covered traffic involving an affected endpoint. Legal and incident teams still determine scope, affected information, response and any notice obligations.
The HTTP boundary must appear in the control description
An inline gateway can inspect authenticated HTTP traffic deliberately routed between firm users or agents and LLM endpoints. That population may include research assistants, correspondence tools and approved agent workflows. It excludes direct browser sessions outside managed routing, local models, model calls executed entirely inside a vendor platform and any application that bypasses the route.
Those exclusions require separate controls. Managed browsers may need their own route and identity integration. Embedded vendor AI depends on contractual evidence and product-native records. Endpoint policy can address local inference. Shadow AI in capital markets covers discovery outside approved paths.
A coverage statement should name the applications, user populations and destinations included on October 5, 2026. Broad claims that the firm protects all AI traffic collapse as soon as one embedded feature sends data through a supplier's private path.
DeepInspect
DeepInspect is a stateless proxy for authenticated HTTP traffic between capital-markets users or agents and LLM endpoints. It evaluates application-supplied identity, request classification, approved destination and policy before forwarding. Each permit, redaction, reroute or block produces a signed per-decision record outside the calling application's write path.
For routed traffic, that places a data-protection decision before customer information reaches a model provider. DeepInspect does not classify the firm's legal obligations, perform vendor due diligence, run incident response or cover local, direct-browser and vendor-internal inference that bypasses the proxy. Book a demo today.
Frequently asked questions
- Does Regulation S-P make every AI prompt customer information?
Regulation S-P reaches prompts that contain customer information within the rule's scope. A firm should classify the prompt based on the information it contains and the relevant relationship. Public issuer data and defined customer information can travel through the same interface while requiring different policies.
- Is TLS enough to protect customer information sent to an LLM?
TLS protects data in transit on a connection. It cannot decide if the authenticated caller may send that information to the chosen provider. Identity-aware classification and destination policy supply that authorization decision before transmission.
- Can a provider contract replace request-level controls?
A contract supports service-provider oversight and sets security duties. It cannot determine if one analyst's specific prompt fits an approved use. Runtime enforcement applies the firm's policy to that request, while vendor diligence evaluates the provider relationship.
- What should happen when a request is blocked?
Record the principal, time, destination, data classification, policy reference and block reason. Send the event to the assigned review queue when the rule requires investigation. A blocked request is control evidence, but it is not automatically a reportable incident or proof that another route was unused.