Noma Security for financial services: does it meet SEC and FINRA AI governance requirements?

Updated July 21, 2026

TL;DR: Noma Security provides runtime policy enforcement and broad AI visibility, but its Kong Gateway plugin routes enforcement telemetry to api.noma.security:443, placing governance logic outside your perimeter. SEC (Securities and Exchange Commission) Rule 206(4)-7 and FINRA (Financial Industry Regulatory Authority) Rule 3110 require firms to maintain tamper-evident records of every governed AI interaction, retained within the institution's own infrastructure, not a vendor's. AIUC-1's Data and Privacy pillar provides the cross-framework anchor that maps these SEC and FINRA obligations to a unified AI governance posture, and a self-hosted deployment model is the only architecture that satisfies it without introducing third-party data custody risk. For broker-dealers and investment advisors with non-public personal financial information in scope, a self-hosted AI control plane that enforces AI governance policy inside your VPC and generates SIEM-ready logs locally is the defensible architectural choice.

Most AI security tools claim to protect institutional data, yet their architecture routes enforcement telemetry to external vendor infrastructure before any AI governance policy decision returns. For financial institutions subject to GLBA (Gramm-Leach-Bliley Act), this creates a risk and compliance exposure that no vendor contract clause fully resolves: the audit evidence trail that SEC and FINRA examiners ask for lives outside your custody.

This guide analyzes Noma Security's architecture against the specific supervision and recordkeeping requirements of SEC Rule 206(4)-7 and FINRA Rule 3110, identifies the structural gaps that external routing creates under GLBA, and maps how a self-hosted sovereign AI control plane closes those gaps for broker-dealers and investment advisors deploying AI in trading, lending, and risk management.

Key SEC and FINRA rules for AI implementation

The regulatory baseline for AI governance in financial services is not a dedicated AI statute. It applies existing supervision and recordkeeping obligations to AI systems that have become part of the firm's operational and supervisory chain.

SEC Rule 206(4)-7, the Compliance Rule for investment advisers, requires firms to maintain policies and procedures reasonably designed to prevent Advisers Act violations. Once an AI model drafts client communications, flags suspicious activity, or supports supervisory review, firms must treat it as part of the supervisory chain under Rule 206(4)-7.

FINRA Rule 3110 imposes a parallel supervision obligation on broker-dealers, requiring a reasonably designed supervisory system tailored to the firm's business. FINRA Regulatory Notice 24-09 states that firms using AI in supervisory systems must address technology governance, including model risk management, data privacy and integrity, and reliability and accuracy of the AI model. FINRA's 2026 Annual Regulatory Oversight Report extends that guidance to include storing prompt and output logs for accountability, tracking which model version was used and when, and human-in-the-loop review of model outputs.

Together, these rules require financial institutions to satisfy key obligations for any AI system in production:

• System-level policy enforcement: Policies should be enforced at the system level, not documented in a wiki and left to individual developers to follow. Governance frameworks and FINRA's published guidance both indicate that supervisory controls must be consistently applied across AI systems, not developer-dependent.
• Tamper-evident audit logs: Every AI interaction should produce a structured, timestamped record that can be produced to an FFIEC examiner or FINRA examiner on demand. FINRA guidance identifies output logging and model version tracking as components of a reasonably designed supervisory system.
• Custody of evidence records: The records that constitute the risk and compliance evidence package should remain under the institution's control. While regulatory documents do not explicitly mandate local custody, routing governance telemetry to external vendor infrastructure introduces chain-of-custody questions that examiners may scrutinize during examination.

Manual spreadsheets do not satisfy these obligations. Automated system logs generated by operational infrastructure carry materially higher evidentiary weight during examination because the chain of custody and tamper-evidence properties cannot be replicated in a spreadsheet.

Generating defensible audit logs for SEC compliance

This section examines what constitutes a defensible audit log under FINRA and SEC standards, and how Noma Security's external routing architecture compares to a self-hosted control plane on the specific properties examiners evaluate.

A defensible audit log is a complete, timestamped, replayable record of every action an AI agent took, every piece of data it accessed, and every governance control that fired or blocked, all generated inside the institution's own infrastructure. FINRA examiners do not evaluate audit logs by data volume. They evaluate the chain of custody, tamper-evidence, and whether the record was generated at the moment of enforcement or assembled retrospectively.

Noma Security's Kong Gateway plugin routes enforcement telemetry externally. The plugin configuration specifies https://api.noma.security as the base URL for AI governance policy decisions, and Kong Gateway nodes must maintain outbound HTTPS access on port 443 to api.noma.security. Noma does provide runtime policy enforcement and real-time monitoring, and the plugin integrates Kong traffic flows with Noma Security Cloud Services for behavioral analysis. For institutions subject to GLBA and FINRA's recordkeeping rules, that means the audit evidence chain includes a segment that transits infrastructure the institution does not control.

Prediction Guard takes a structurally different approach. The entire control plane deploys inside your VPC. AI governance policy checks run inside your environment. The control plane generates the audit log inside your environment as evidence that enforcement happened, then forwards it natively to your SIEM (Security Information and Event Management system) through your own ingestion pipeline. Prediction Guard does not store or retain audit logs and holds no SIEM credentials. Generation stays under your custody from the moment it occurs.

Automating audit logs for SEC compliance

Risk and compliance teams that fail SEC recordkeeping examinations typically fail because their audit log is assembled retrospectively from email threads, developer questionnaires, and vendor dashboards. By the time the next examination cycle begins, the evidence is already stale.

Automated runtime enforcement structurally changes the evidence posture. When a governance control plane enforces every AI interaction at the system level, the audit log is a continuous, machine-generated byproduct of enforcement. The log records what was allowed, blocked, or rewritten, which model was used, and which version was active at the time. That is the evidence package an FFIEC examiner expects, produced automatically rather than during a risk and compliance sprint before the examination begins. The Prediction Guard NIST AI RMF playbook covers the practical path from framework selection to audit-ready documentation.

Automating SEC-ready evidence packages

For investment advisers subject to SEC disclosure rules, a complete AI asset inventory is the foundation of a defensible materiality assessment. The SEC's cybersecurity disclosure rules, which took effect for larger reporting companies on December 18, 2023, require public companies to disclose material cybersecurity risks and incidents. As AI systems become material to business operations, the question of whether a model vulnerability affects disclosed risk calculations becomes a board-level concern, and that question cannot be answered without knowing which model versions are in production.

Prediction Guard's AI System registration captures models, tools, MCP (Model Context Protocol) servers, and datasets as registered assets. The AIBOM export in CycloneDX format generates the structured inventory that risk and compliance teams can provide to an SEC examiner for materiality assessment. The AIBOM is the byproduct of registration, not the headline capability, but it directly answers the examiner's asset question.

Securing AI assets to meet SEC and FINRA standards

AI asset registration is the prerequisite for both FINRA model version tracking and SEC disclosure materiality assessment. Without a structured inventory of what is running, neither obligation can be satisfied.

FINRA's supervision requirements and SEC's disclosure rules both assume the firm knows which AI systems are running, what they do, and under what governance controls they operate. The gap between what engineering teams have deployed and what compliance teams have documented is where examination findings originate.

Registering AI assets in a controlled inventory gives risk and compliance teams a structured record they can produce to a FINRA examiner without a sprint to reconstruct what was running at the time of an incident. The Prediction Guard agentic AI governance blog covers the governance trade-offs at enterprise scale.

Structuring AI assets for SEC compliance

SEC disclosure materiality assessment for AI requires a "reasonable basis" for every claim about how AI is used in firm operations. You cannot establish a reasonable basis for a model you have not inventoried. This creates a direct link between AI System registration and SEC disclosure compliance: the AIBOM is not just a technical asset list, it is the evidentiary foundation for the firm's disclosure position.

Prediction Guard maps AI System registration to the NIST AI RMF 1.0 Govern function, which requires establishing organizational practices for AI risk management, and to the Map function, which requires identifying AI risk across the system. A registered inventory with documented model versions, tool dependencies, and MCP server connections satisfies the inventory requirements of both functions.

Monitoring ungoverned agent interactions

Ungoverned agent interactions, where AI agents call external tools, retrieve from external APIs, or invoke MCP servers without enforcement on each outbound call, create interaction chains that are invisible to compliance teams and ungoverned under FINRA's supervision framework. These interactions represent a material and often underestimated risk exposure in financial services AI deployments, because agents that operate autonomously across tool calls can generate material risk exposures in a single session.

Prediction Guard governs every registered AI asset: models, tools, and MCP servers. Every agent call is checked against governance policy at the control plane before it completes. The Zero Trust for AI Agents episode of Practical AI, co-hosted by Prediction Guard CEO Daniel Whitenack with Chris Benson, covers how zero-trust principles map to runtime enforcement in production agent deployments.

Verifying AI deployments for SEC auditors

Proving to an FFIEC examiner or FINRA examiner that policies are actively enforced at runtime requires more than an AI governance policy document. It requires a structured log record showing which policy was applied, what the model input and output were, whether the policy blocked or allowed the interaction, and a timestamp of enforcement, generated at the moment of enforcement rather than reconstructed afterward.

Prediction Guard's control plane enforces policy before the model call completes and generates the structured audit log at the moment of enforcement. The log is SIEM-ready and formatted natively for Splunk, Datadog, or generic syslog, so your security operations team can query it within existing tools.

How Noma Security automates runtime policy

Noma Security provides genuine runtime enforcement capabilities, but the architectural path that telemetry takes before a policy decision returns creates a structural compliance constraint that financial institutions must evaluate before deployment.

Noma Security provides runtime policy enforcement and real-time monitoring capabilities, including prompt injection detection, content violation controls, and behavioral analysis. The platform integrates with Copilot Studio and Salesforce AgentForce, making it a competitive offering for enterprises running heterogeneous AI deployments. These are genuine capabilities, not marketing claims.

The architectural constraint that creates compliance risk for financial institutions is documented in Noma's own integration materials. Its Kong Gateway plugin requires outbound HTTPS access on port 443 to api.noma.security as the base URL for policy decisions. The plugin integrates Kong traffic flows with Noma Security Cloud Services, where enforcement telemetry is processed externally. For broker-dealers and investment advisors handling non-public personal financial information under GLBA, this creates a third-party risk exposure that requires ongoing oversight obligations. The GLBA Safeguards Rule requires financial institutions to ensure that service providers maintain adequate safeguards for customer NPI while in their custody. External telemetry routing introduces vendor oversight obligations under GLBA that self-hosted deployment avoids by removing the external data pathway from the governance architecture.

Prediction Guard's control plane runs entirely inside your VPC. No data, governance logic, or audit logs transit Prediction Guard's infrastructure.

System-level controls for SEC compliance

System-level controls prevent policy violations before they occur by evaluating every AI interaction at the moment of the call. Alert-after-the-fact tooling generates an incident report when a violation has already completed. Proxy architectures that evaluate content after the call has initiated introduce a timing gap between initiation and enforcement that pre-call control plane evaluation is designed to avoid. For financial institutions where a single AI interaction can result in a material disclosure or a supervisory failure, the timing of enforcement is a structural compliance distinction, not a minor technical detail.

Prediction Guard enforces policies including prompt injection defense, toxicity filtering, PII detection and masking, and factual consistency checking at the control plane level, before the model response returns to the requesting application. The OWASP Top 10 for Agentic Applications documents how prompt injection cascades across agent workflows when left unaddressed at the control plane.

Replacing manual checks with system controls

Manual vs. automated audit readiness

Meeting SEC and FINRA audit standards

A self-hosted control plane satisfies SEC and FINRA audit standards through three structural properties that external routing architectures cannot replicate: policy enforcement happens before the model call completes, the audit log is generated inside the institution's environment at the moment of enforcement, and the SIEM receives that log through the institution's own ingestion pipeline. Those three properties together produce the tamper-evident, locally retained, continuous audit log that FINRA examiners and FFIEC examiners expect.

Where does Noma Security align with AIUC-1, NIST AI RMF, and OWASP requirements?

The following crosswalk maps Prediction Guard's specific technical controls to AIUC-1, NIST AI RMF, and OWASP LLM Top Ten to support procurement due diligence and framework conformity assessments.

AIUC-1, the cross-framework standard that enterprise procurement teams increasingly require in AI vendor due diligence, provides a crosswalk at aiuc-1.com/crosswalks that maps its six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, Society) to aligned frameworks including NIST AI RMF, OWASP, and ISO/IEC 42001. For financial institutions evaluating Noma Security, the question is not whether Noma addresses individual framework requirements in isolation, but whether its architecture supports the cross-framework conformity posture that AIUC-1 assessors and enterprise procurement reviewers expect. The AIUC-1: Building trust in AI agents episode of Practical AI covers how AIUC-1 applies to AI agent deployments and the governance obligations its six pillars address. Prediction Guard's built-in policy mapping addresses AIUC-1 requirements without requiring the institution to build a separate conformity layer.

The capability-to-framework mappings in the table below reflect the authors' interpretation based on available documentation. Verify each row against the published AIUC-1 crosswalk ataiuc-1.com/crosswalksand Prediction Guard's published capability-to-function mapping before using this table in a procurement due diligence or conformity assessment context.

Control-to-framework crosswalk

For financial services teams building agentic workflows, the primary reference is the OWASP Top 10 for Agentic Applications, not the LLM Top Ten alone. The agentic framework addresses the cascading threat patterns, including prompt injection, excessive agency, and memory poisoning, that multi-step AI agents introduce.

Securing AI applications against OWASP threats

AI systems including LLMs face OWASP threat categories that cascade across agent workflows when left unaddressed at the control plane level. An agent's ability to chain actions autonomously means a single prompt injection can escalate into data exfiltration, unauthorized tool execution, or financial loss. System-level control planes intercept and enforce policy before agent execution, preventing cascading failures by blocking or rewriting the interaction before the model call completes.

Prediction Guard enforces prompt injection defense and output validation at the control plane. For ISO/IEC 42001 alignment, the enterprise AI management system standard that certification bodies use during third-party conformity assessment, a sovereign control plane that generates locally retained, structured audit logs provides the evidence artifacts that conformity assessors expect. External governance architectures where enforcement telemetry routes to vendor infrastructure create a gap in the evidence chain because the institution does not have direct custody of the records demonstrating control effectiveness.

How does Noma Security handle data sovereignty for financial institutions?

Data sovereignty under GLBA is not satisfied by contractual assurances alone. It requires that governance telemetry never leave the institution's own infrastructure, a requirement that external routing architectures cannot meet by design.

Data sovereignty for financial institutions is a specific regulatory obligation with direct consequences under GLBA. When AI governance telemetry routes to an external vendor's infrastructure, the institution extends its data perimeter to include that vendor's processing environment. The GLBA Safeguards Rule requires financial institutions that share customer NPI with third-party service providers to contractually prohibit use of that information outside the agreed purpose and to take reasonable steps to verify the provider maintains appropriate safeguards. External telemetry routing increases the scope of that obligation and the oversight burden required to manage it.

Prediction Guard's self-hosted deployment model addresses this directly. The control plane deploys inside your VPC, air-gapped network, or self-hosted cloud environment. Governance logic, policy evaluation, and audit log generation all occur inside your control boundary. The vendor never touches your data.

On-premises deployment for audit control

Financial institutions handling non-public personal financial information under GLBA cannot route that data through external vendor infrastructure without accepting third-party risk obligations and potential liability exposure. The self-hosted deployment model eliminates the external data pathway entirely.

Prediction Guard deploys inside your own Kubernetes environment, whether self-hosted on-premises or inside your cloud VPC, so governance records are generated and retained within the institution's own environment. Developers do not change application code: existing OpenAI-compatible and Anthropic-compatible SDK calls work unchanged, with only the base_url repointed to the control plane endpoint.

What gaps exist in Noma Security for financial services risk and compliance?

The gaps identified below are architectural rather than functional: Noma's runtime controls are substantive, but the external routing model creates compliance exposures that affect data custody, audit chain integrity, and GLBA third-party risk scope.

The gaps in Noma Security's architecture for financial services are not about platform breadth. Noma offers comprehensive runtime controls, discovery, posture management, and integrations. The gaps are architectural: enforcement telemetry routes to api.noma.security:443, which is external infrastructure outside the institution's perimeter. That external routing prevents absolute data custody guarantees under GLBA and introduces third-party risk that a self-hosted control plane can mitigate.

Trading controls for SEC AI compliance

AI systems used in trading algorithms operate under latency and data integrity constraints that make external routing architectures particularly problematic. Any governance architecture that adds external network hops to the enforcement path introduces variable latency that can affect execution quality. A self-hosted control plane enforces AI governance policy on the same network segment as the trading workflow, with no external dependency in the critical path.

Meeting SEC standards for lending AI

AI systems used in credit scoring and lending decisions face additional explainability requirements under fair lending regulations, on top of SEC and FINRA audit trail requirements. Factual consistency checking, which verifies that AI-generated outputs are grounded in the data sources used to produce them, is a capability required to defend lending AI decisions against regulatory challenge. Prediction Guard's factual consistency checking runs inside the control plane before the model response returns, and the result is logged in the SIEM-ready audit record, providing a documented basis for defending individual credit decisions to examiners.

Identified SEC and FINRA coverage gaps

The coverage gaps for financial institutions evaluating Noma Security against SEC and FINRA requirements:

• Data perimeter sovereignty: Noma routes enforcement telemetry externally. Prediction Guard enforces policy entirely inside your VPC with no external data pathway.
• Audit log custody: Noma streams telemetry to its Security Console. Prediction Guard generates logs inside your environment, forwarded through your SIEM ingestion pipeline.
• GLBA third-party risk: External telemetry routing may expand the institution's third-party risk obligations. Self-hosted deployment removes the external data pathway.
• FINRA supervision evidence: External processing introduces a chain-of-custody question in the examination evidence package. Internal generation provides continuous, locally held records.

Mapping Noma Security capabilities to AI risk and compliance needs

The checklist below gives risk and compliance and procurement teams a structured comparison of the architectural properties that directly determine examination readiness under SEC Rule 206(4)-7 and FINRA Rule 3110.

Financial institutions that have evaluated Noma Security should understand that the platform's runtime controls address many content-level governance requirements, but the external routing architecture creates a data sovereignty gap that contractual controls alone cannot fully resolve.

Risk and compliance gatekeeper checklist for AI vendor evaluation

Documenting Noma for FINRA audit readiness

A FINRA examiner reviewing a broker-dealer's AI supervision program asks for the complete evidence chain from policy definition to runtime enforcement to audit log retention. For a firm using Noma Security, that chain includes a segment where telemetry routes to external infrastructure before returning a policy decision. Documenting that segment requires a third-party service provider agreement, ongoing oversight evidence, and a clear answer to what data transited the external infrastructure and under what controls.

For a firm using Prediction Guard's self-hosted control plane, the evidence chain is entirely internal. The AI governance policy was defined in the Admin Console, enforced inside the VPC on every model call, and the audit log was generated inside the environment and forwarded to the firm's SIEM through its own ingestion pipeline.

Addressing SEC and FINRA AI controls

A self-hosted sovereign AI control plane addresses the core SEC and FINRA AI controls by design. AI governance policy is enforced at the system level on every agent call before it completes. The audit log is generated inside the institution's environment as evidence of enforcement. The SIEM receives the log through the institution's own ingestion controls. The AIBOM provides the structured asset inventory that satisfies both FINRA's model version tracking requirement and the SEC's materiality assessment baseline.

Deployment timeline for risk and compliance teams

Self-hosted deployment inside a financial institution's VPC does not require rebuilding the engineering team's existing toolchain. Prediction Guard's control plane is OpenAI-compatible and Anthropic-compatible at the API level, so developers repoint existing SDK calls to the control plane endpoint by changing only the base_url parameter. Application code is unchanged. Governance is enforced transparently on every call. For teams already using LangChain, the langchain-predictionguard Python package integrates directly without additional tooling. Prediction Guard states that self-hosted deployment has realized ROI in less than one week in customer environments, dependent on deployment environment and integration scope. This is a company-stated figure and has not been independently verified.

What evidence does Noma Security provide for auditors?

Noma Security provides audit log data through its Security Console, with SIEM integrations available for Splunk and Datadog. The evidence it provides reflects enforcement evaluated through external infrastructure, which means the evidence chain includes a third-party segment outside the institution's direct custody.

Prediction Guard generates structured, SIEM-ready logs inside your VPC as a direct byproduct of runtime enforcement. Each log entry records the enforcement event at the moment it occurred, inside your environment, under your custody. That is the evidence package a FINRA examiner expects: continuous, locally generated, tamper-evident, and immediately accessible through your existing SIEM. The evidence posture difference between externally generated telemetry and internally generated audit logs is the structural reason financial institutions subject to SEC Rule 206(4)-7 and FINRA Rule 3110 should evaluate sovereign control plane architectures before committing to external gateway vendors.

To assess whether Prediction Guard's self-hosted control plane fits your SEC/FINRA compliance architecture, book a deployment scoping call.

FAQs

Does Prediction Guard store our audit logs?

No. Prediction Guard generates structured, SIEM-ready logs inside your VPC as a byproduct of runtime policy enforcement, and those logs are immediately consumed by your existing SIEM (Splunk, Datadog, or generic syslog). Prediction Guard has no log retention capability and does not hold your logs after generation.

What is the deployment timeline for Prediction Guard?

Prediction Guard states that self-hosted deployment inside a VPC has realized ROI in less than one week in customer environments, dependent on deployment environment and integration scope. Because the control plane is OpenAI- and Anthropic-compatible, developers only need to repoint their base_url without rewriting application code.

Does Prediction Guard hold our SIEM credentials?

No. Prediction Guard does not hold, store, or manage your SIEM API keys, HEC tokens, or credentials of any kind. The control plane configures how audit log output is formatted to match your SIEM's native field structure, and your existing ingestion pipeline handles delivery under your own controls.

Does Noma Security's Kong Gateway plugin route telemetry outside our VPC?

Yes. Noma's Kong Gateway plugin configuration specifies https://api.noma.security as the base URL for policy decisions, and Kong Gateway nodes must maintain outbound HTTPS access on port 443 to api.noma.security. Enforcement telemetry streams to the Noma Security Console for behavioral analysis and audit log generation.

Which SEC and FINRA rules govern AI systems at broker-dealers?

SEC Rule 206(4)-7 requires investment advisers to maintain policies and procedures reasonably designed to prevent Advisers Act violations, including governance of AI systems that participate in supervisory workflows. FINRA Rule 3110 requires broker-dealers to maintain a reasonably designed supervisory system. FINRA Regulatory Notice 24-09 confirms this must address technology governance for AI tools, including model risk management, data privacy and integrity, and reliability. FINRA's 2026 Annual Regulatory Oversight Report extends that guidance to output logging, model version tracking, and human-in-the-loop review.

What is the difference between an AIBOM and an audit log?

An AIBOM is a structured inventory of all AI assets in production, including model versions, tool dependencies, and MCP server connections, exported in CycloneDX format. An audit log is a timestamped, event-level record of individual AI interactions and the governance controls applied to each. Both are required for SEC and FINRA compliance, but they answer different examiner questions: the AIBOM answers the asset inventory question, and the audit log answers the enforcement evidence question.

Key terms glossary

Sovereign AI control plane: An internal governance infrastructure deployed entirely within an organization's security perimeter to compose, secure, and govern AI systems without data, telemetry, or governance logic leaving the VPC.

Runtime policy enforcement: The active evaluation and enforcement of security and compliance policies on every AI input and output in real time, before the model call completes, not after the fact.

AI Bill of Materials (AIBOM): A structured inventory of all AI assets, models, datasets, and dependencies in production, exported in standard formats like CycloneDX for compliance audits and SEC disclosure materiality assessment.

GLBA Safeguards Rule: The Federal Trade Commission regulation requiring financial institutions to maintain an information security program that protects customer non-public personal information, including obligations for third-party service provider oversight.

Factual consistency checking: A control plane capability that verifies AI-generated outputs and agent actions against trusted data sources to identify potential inaccuracies in model responses. This is a probabilistic capability that produces a risk signal rather than a binary pass/fail determination.

CycloneDX: An OWASP Foundation project for full-stack Bill of Materials generation, including AIBOM, supporting AI supply chain visibility and risk reduction for regulated enterprises.