Noma Security: architecture, limitations, and fit for defense-adjacent enterprises

Updated July 21, 2026

TL;DR: Noma Security delivers strong build-side AI discovery, posture management, and commercial integrations for enterprises without strict data sovereignty requirements. For defense contractors handling Controlled Unclassified Information (CUI) under ITAR or CMMC Level 2, its reliance on outbound telemetry routing to external endpoints creates a risk and compliance boundary most defense programs cannot accept. The architectural question is where your data travels during governance operations. A fully self-hosted AI control plane that keeps governance logic, runtime enforcement, and audit logs inside your own infrastructure is the only architecture that closes this gap. AIUC-1 provides the unified compliance crosswalk that maps a single runtime enforcement implementation to NIST AI RMF, OWASP, and EU AI Act requirements simultaneously, making it the recommended framework anchor for defense-adjacent AI governance programs.

When evaluating AI governance for a defense-adjacent environment, the most consequential architectural question is not which features a vendor demonstrates in a sales call. It is where your data and telemetry route when those features execute. For Chief Information Security Officers (CISOs) and risk and compliance officers at organizations handling ITAR-regulated technical data or CMMC-scoped CUI, that question is not optional and the wrong answer is disqualifying.

This review examines Noma Security's architecture, deployment patterns, framework alignment, and practical fit for defense contractors, aerospace manufacturers, and federal-adjacent enterprises. It draws on publicly available documentation, primary regulatory sources, and a direct architectural comparison with Prediction Guard's self-hosted AI control plane.

What Noma Security delivers for AI governance

Per noma.security, the platform "discovers, governs, and protects AI and agents across the enterprise, from homegrown AI to SaaS agents and coding assistants," providing AI Security Posture Management (AI-SPM) that catalogues models, agents, MCP servers (see the Practical AI episode 358 for background on this protocol), and data sources across the enterprise. Noma's public product materials describe a capability set spanning runtime detection and response (AI-DR), agent access control, discovery and posture management, and adversarial testing via AI red teaming.

Mapping Noma to compliance frameworks

Noma's posture management capabilities produce AI asset inventories that support several governance frameworks. The risk and compliance mapping, however, depends on what each framework actually requires as evidence:

• GOVERN function (NIST AI RMF): Noma's discovery layer supports evidence for policy existence and AI asset identification, relevant to GOVERN 1 requirements.
• MAP function: Posture scanning and asset discovery contribute to context documentation about which AI systems are in use.
• MEASURE and MANAGE gap: These functions require quantitative, system-level evidence that enforcement happened at the point of each model interaction, not just that assets were catalogued. Build-side posture scanning does not generate the same evidence as runtime enforcement applied before each call completes.

For DCSA assessors and C3PAOs reviewing AI governance evidence, the distinction between asset inventory and per-call enforcement evidence is material.

Noma deployment and data sovereignty

Noma offers self-hosted components for some deployment patterns, but its core control infrastructure routes telemetry outbound to api.noma.security on port 443. This is verified through Noma's Kong Gateway plugin documentation, which requires outbound HTTPS to that endpoint as part of its standard gateway integration. Even in a nominally self-hosted configuration, telemetry, governance signals, and detection events transit Noma's external infrastructure. Build-side visibility (discovering which models exist) is architecturally different from usage-side enforcement (governing active AI inputs (prompts, retrieved context, tool call arguments) and responses). Noma's architecture is stronger on the build side, and that gap has direct consequences for defense-sector buyers.

Deployment patterns for Noma Security oversight

Understanding where data flows during a Noma deployment is the core technical due diligence task for any defense-sector procurement review.

Cloud versus self-hosted deployment and data perimeters

Noma operates as a SaaS-delivered governance control plane with optional self-hosted components. For the gateway integration to function, traffic must reach external Noma infrastructure. This is a fundamental architectural constraint, not a configuration choice. Self-hosted deployments that still require external telemetry routing are not fully self-contained governance systems. They are hybrid architectures with a data egress dependency, and that dependency is the risk and compliance exposure for defense-adjacent buyers.

In a defense-adjacent deployment handling CUI or ITAR-regulated technical data, the data perimeter is the risk and compliance boundary. When an AI agent running inside a secured environment routes governance telemetry to an external endpoint, that telemetry carries inference inputs, which may include CUI, through an uncontrolled data pathway.

ITAR, codified at 22 C.F.R. Parts 120-130, prohibits the export of ITAR-controlled technical data to any foreign person or foreign destination without specific authorization from the U.S. State Department. A "deemed export" under 22 CFR 120.17 occurs even when data never leaves U.S. territory if it is released to a foreign person. When telemetry routes through external vendor infrastructure, the organization loses direct control over where that data is processed and by whom, creating a deemed export risk that most ITAR compliance programs cannot accept. As export controls specialists note, managing server location is critical to maintaining trade compliance and preventing violation of U.S. export regulations.

By contrast, a purpose-built self-hosted AI control plane deploys the entire governance stack inside the customer's own infrastructure, whether that is a self-hosted Kubernetes cluster, a cloud VPC, or an air-gapped environment. No data, telemetry, or governance signal leaves the customer's perimeter, and that is the default architecture, not a premium configuration option.

Ensuring defensible AI oversight at scale

For defense contractors and federal-adjacent enterprises, the distinction between retrospective detection and system-level enforcement determines whether an AI governance platform can produce audit-ready compliance evidence. This section examines how enforcement timing shapes the evidence available to assessors evaluating CMMC and ITAR compliance.

Defensible audit posture in a regulated environment requires more than build-side posture scanning and policy documentation. It requires evidence that enforcement happened at the system level on every interaction, not just that policies were defined and assets were inventoried.

System-level enforcement versus retrospective detection

A policy that exists in a wiki but is not enforced at the system level is not a control. It is a documented intention, and documented intentions do not satisfy a C3PAO auditor asking for evidence that CUI was protected during active AI inference. The structural difference between advisory governance and system-level enforcement is where the check happens: before the model call completes, or after the fact via log review.

Noma's runtime detection and response capability performs in-line enforcement, including PII redaction, sensitive data masking, and blocking non-compliant requests, through its Kong Gateway plugin. The architectural distinction is not whether enforcement happens but where the enforcement decision is computed. Noma's plugin routes each request out to api.noma.security for evaluation before the enforcement action returns to the customer's environment. For organizations that need to demonstrate to a Defense Counterintelligence and Security Agency (DCSA) assessor that no unauthorized data left the AI system's authorized boundary during a specific interaction, an enforcement decision computed by external infrastructure produces a different audit narrative than an enforcement decision computed inside the customer's perimeter. The episode of Practical AI, co-hosted by Prediction Guard CEO Daniel Whitenack with Chris Benson, covers Zero Trust principles for AI agents and agentic security risks, providing relevant background on the architectural considerations that shape enforcement decisions in regulated deployments.

Prediction Guard enforces AI governance policies on every agent call before the call completes, checking the call, allowing it, blocking it, or rewriting it in real time. The audit log is the record that enforcement happened. It is not the enforcement mechanism. This is the architectural distinction that matters for regulated buyers: the log proves the decision was made at the right moment, not that someone reviewed logs afterward and flagged a violation.

Structuring logs for SIEM ingestion

Prediction Guard generates structured audit logs as a byproduct of runtime enforcement, consumed by your Security Information and Event Management (SIEM) directly from within your own environment. Those logs forward natively to Splunk, Datadog, and generic SIEM targets, and are available for SIEM-native querying without intermediate transformation. Noma produces detection events that can similarly be forwarded to enterprise SIEM platforms, but because that telemetry processes through Noma's external infrastructure before SIEM delivery, defense-sector buyers should confirm in procurement exactly which data elements are processed externally before reaching the customer's SIEM.

Risk and compliance evidence: AIUC-1 crosswalk and framework mapping

For defense-adjacent enterprises navigating multiple risk and compliance obligations simultaneously, AIUC-1 provides the organizing framework that maps a single control implementation across NIST AI RMF, OWASP, and EU AI Act requirements (see AIUC-1 crosswalks for the full list of published framework mappings). The episode of Practical AI covers AIUC-1 in the context of AI red-teaming and certification, providing relevant background on the framework for regulated buyers. Rather than maintaining separate evidence packages for each framework, organizations using AIUC-1 as their primary governance anchor can demonstrate through one unified crosswalk how system-level runtime enforcement satisfies the control requirements of each named framework. NIST AI RMF and OWASP are two of the most directly mapped targets within that crosswalk, and their requirements are covered in the subsections below. This matters for prime contractors and supply chain participants who must satisfy federal contract requirements (CMMC, NIST SP 800-171) and voluntary standards (NIST AI RMF, OWASP) within the same risk and compliance program without duplicating evidence collection.

ISO/IEC 42001 compliance mapping

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AI Management System (AIMS), with controls covering risk and impact assessments, AI system lifecycles, and data management. It is certifiable, meaning organizations can undergo third-party audits to receive formal certification. ISO 42001 certification requires demonstrable controls over the AI system lifecycle, including runtime governance. Governance infrastructure that only provides build-side visibility cannot satisfy the runtime control requirements that a third-party conformity assessor will verify during certification audit.

NIST AI RMF compliance audit mapping

The NIST AI Risk Management Framework 1.0 core functions require different types of evidence:

• GOVERN: Accountability structures for AI risk decisions, including who approves high-risk AI use cases and how third-party AI systems are introduced.
• MAP: Documented context about which AI systems are in use, what data they process, and what risks they carry.
• MEASURE: Quantitative or qualitative analysis of AI risk, benchmarked and monitored over time.
• MANAGE: Active controls that respond to identified risks, with demonstrable evidence that controls operated at the point of each interaction.

For a CISO preparing for an internal AI governance review, all four functions need system-level evidence, not only policy documentation. Prediction Guard maps its enforcement capabilities directly to NIST AI RMF functions, NIST AI 600-1 sections, OWASP LLM Top Ten items, and OWASP Top 10 for Agentic Applications, with structured mapping tables that a CMMC Third-Party Assessment Organization (C3PAO) or DCSA assessor can review against the framework text. The NIST AI RMF implementation playbook covers how to build audit-ready evidence packages from these function mappings.

Addressing OWASP agentic vulnerabilities

The OWASP Top 10 for Agentic Applications 2026 identifies the most critical security risks facing autonomous AI systems. Coverage for the runtime risks catalogued in the OWASP Top 10 for Agentic Applications 2026 requires system-level controls at the point where agent calls are made, because each risk category involves an active interaction between an agent and a model or agent, a tool, or an external data source. Posture scanning that runs periodically on configuration data does not cover runtime manifestations of these risks, where an attacker redirects an agent's objective or exploits a legitimate tool during an active session.

Real-world gaps in Noma Security deployments

Noma's architecture reflects a design optimized for commercial enterprise environments with broad SaaS footprints and development teams using commercial model APIs. These are genuine strengths in that context. The gaps emerge specifically when defense-sector requirements enter scope: strict data perimeter controls, air-gapped deployment mandates, and ITAR compliance obligations.

The table below contrasts the two architectures across the dimensions that matter most for a CMMC Level 2/3 or ITAR compliance program.

Model compatibility. Prediction Guard is model agnostic. Its control plane governs open-source families, closed-vendor endpoints, and self-hosted models under the same AI governance policy framework, regardless of model vendor. Proxy-based architectures that route all traffic through a centralized external inspection point must handle every vendor's request format consistently, and inconsistencies in that handling create coverage gaps that adversarial inputs can exploit in multi-vendor environments.

Governance portability. If AI governance policy definitions are held in a vendor's proprietary configuration format, migrating to a different governance tool requires rebuilding those configurations from scratch. Prediction Guard's governance policies are configured in the Admin Console and enforced uniformly at the control plane level across any registered model, regardless of vendor. Swap the underlying model and the governance policy follows automatically. See the Prediction Guard product comparisons page for a structured view of architectural differentiation.

Agent inventory gaps. Build-side scanning identifies AI assets that are registered or discoverable through integration APIs. It does not automatically capture every agent interaction at runtime, particularly when agents make lateral tool calls or access local data sources outside a centralized discovery service. System-level enforcement that intercepts every outbound agent call, regardless of which framework initiated it, provides runtime coverage that build-side discovery cannot replicate. For organizations managing fragmented agent ecosystems, the Prediction Guard agentic AI blog addresses the governance trade-offs at enterprise scale.

Meeting defense and ITAR compliance standards

ITAR and CMMC impose overlapping but distinct data handling requirements that shape AI governance architecture choices for defense contractors. This section examines how these risk and compliance obligations interact with telemetry routing, data residency, and audit logging requirements in AI governance platforms.

Addressing ITAR data obligations

ITAR applies to defense articles, defense services, and related technical data as defined in 22 C.F.R. Parts 120-130. When an AI system processes ITAR-controlled technical data, every component that touches that data becomes subject to ITAR's export control requirements. AI governance infrastructure that routes inference inputs through external vendor infrastructure for analysis creates an uncontrolled data pathway that most ITAR compliance programs cannot accept. A fully self-hosted AI control plane eliminates this risk by design because governance logic, enforcement decisions, and audit logs are generated and retained inside the customer's own infrastructure.

CMMC control validation for Noma

CMMC Level 2 applies to vendors handling CUI and requires implementation of all 110 NIST SP 800-171 Rev. 2 controls, including multi-factor authentication, encryption of CUI at rest and in transit, continuous audit logging, incident response plans, and secure configuration management. CMMC Level 2 also requires AU family controls covering system logging and monitoring, including requirements that audit records contain timestamps, source and destination addresses, user or process identifiers, event descriptions, success or failure indications, filenames involved, and access control rules invoked (see AU.L2-3.3.1). For organizations preparing a CMMC assessment, the key question for any AI governance vendor is: are the audit records generated inside our authorized boundary, or are they generated by the vendor's infrastructure and then forwarded to us?

Defense-sector readiness checklist for Noma evaluations

Defense-sector CISOs evaluating Noma for production deployment should work through the following checklist before advancing to contract review. Each item identifies a documentation gap that Noma users will need to address manually:

1. ITAR audit log origin: Confirm in writing whether all audit records are generated inside the customer's authorized boundary or processed by Noma's external infrastructure before delivery.
2. Air-gapped deployment documentation: Request documentation for a fully air-gapped deployment with zero external connectivity and verify whether all Noma components function without outbound internet access.
3. Foreign person access controls: Obtain a written attestation from Noma regarding which personnel have access to customer telemetry processed through Noma's infrastructure, including citizenship and location of those personnel.
4. CUI boundary certification: Request a formal statement on whether Noma's SaaS infrastructure is authorized to process CUI under CMMC and whether that authorization covers the data types in scope for your program.
5. CMMC AU control mapping: Request a field-level mapping from Noma's audit log schema to the specific AU control requirements under NIST SP 800-171 Rev. 2, confirming all required audit record elements are captured.

Mile Corrigan, Noblis president and CEO, described the value of Prediction Guard's approach directly: "This alignment offers significant opportunities for strategic collaboration on secure deployment of AI systems, including through Noblis' Artificial Intelligence Assurance Implementation (AI2) solution for AI safety, and further strengthens our ability to help customers navigate AI adoption while safeguarding sensitive data." Noblis, a leading science, technology, and strategy services provider to the federal government, made a strategic investment in Prediction Guard specifically because its architecture keeps AI systems and their governance evidence inside the customer's own infrastructure.

Identifying Noma Security architectural risks

Beyond compliance boundaries, Noma's reliance on external telemetry routing introduces operational risks that compound as agent deployments scale. This section examines availability dependencies, integration complexity, and the questions defense-sector buyers should ask during technical due diligence.

Scaling constraints and integration bottlenecks

External telemetry dependencies create operational bottlenecks that scale with usage volume. Every agent call that routes telemetry externally adds a network round-trip, introduces a dependency on external service availability, and creates a potential chokepoint when traffic spikes. In high-availability defense programs, dependence on an external SaaS endpoint is an availability risk that must be documented in the program's continuity plan. The self-hosted vs. cloud deployment guide covers the operational trade-offs of each architecture in detail.

Defense-sector security stacks typically include SIEM platforms, security orchestration tools, and identity management infrastructure deployed inside the secure boundary. Integrating an external AI governance control plane with this internal stack requires data flows between the internal stack and that external control plane, introducing firewall rule changes, certificate management, and ongoing monitoring of the integration point as a potential attack surface.

Questions to ask Noma's sales team

In a defense-sector evaluation, request written answers to these specific questions:

1. Can you provide a reference customer from a CMMC Level 2 or Level 3 certified organization using Noma in a production environment handling CUI? Request contact information for a peer call.
2. What is the exact list of Noma infrastructure endpoints that require outbound connectivity from within the secure boundary? Request this in writing with IP ranges.
3. Has Noma received a formal legal opinion or DDTC guidance confirming that telemetry routing through Noma's cloud infrastructure does not constitute a deemed export under 22 CFR 120.17?
4. Does Noma maintain SOC 2 Type II certification for the specific infrastructure components that process customer telemetry?
5. What is the documented process for handling a Noma service outage? Can the AI governance system remain operational without connectivity to Noma's external endpoints?

If your evaluation concludes that a fully self-hosted control plane is the right architecture for your program, book a deployment scoping call to assess infrastructure requirements and risk and compliance fit before advancing to procurement.

FAQs

Does Noma Security support fully self-hosted deployment with complete data residency?

Noma offers self-hosted components, but its core telemetry and governance processing routes outbound to api.noma.security on port 443 via its Kong Gateway plugin (see Kong Gateway plugin documentation), which means full data residency inside the customer's own infrastructure is not achievable in a standard Noma deployment. Organizations requiring zero external data egress should request formal air-gapped deployment documentation and confirm in writing whether all Noma functionality operates without that outbound connectivity.

Can Noma Security enforce NIST AI RMF policies at runtime?

Noma provides real-time monitoring and detection capabilities through its AI-DR module, but its telemetry processes externally, so enforcement evidence for NIST AI RMF MANAGE function controls does not originate entirely within the customer's authorized boundary. Defense programs requiring system-level evidence that AI policies were enforced at the point of each model interaction inside a specific security enclave will need supplemental documentation to satisfy that requirement.

Who owns and retains Noma Security audit logs?

Noma forwards detection events and telemetry to customer-designated SIEM platforms, but because the telemetry processes through Noma's external infrastructure before delivery, the chain of custody for the raw log data includes a vendor-managed external system. Organizations subject to CMMC AU control requirements should verify whether Noma's log delivery model satisfies the requirement that audit records remain under customer control throughout their lifecycle.

Can Noma Security meet ITAR compliance requirements for defense contractors?

Based on publicly available documentation, Noma's standard deployment requires outbound telemetry routing that creates potential ITAR compliance exposure for organizations handling ITAR-controlled technical data. ITAR under 22 C.F.R. Parts 120-130 requires strict control over where technical data is processed and who has access to it, so ITAR-regulated programs should obtain a formal legal opinion on Noma's data handling before deployment rather than relying on vendor risk and compliance claims alone.

What SIEM platforms does Noma Security integrate with?

Noma supports integration with enterprise SIEM platforms commonly used in security operations, delivering formatted detection events after processing through Noma's external infrastructure. Defense-sector buyers should confirm whether delivered event field schemas include all required CMMC AU audit record elements, including timestamps, source and destination identifiers, user or process identifiers, event descriptions, success or failure indications, filenames involved, and access control rules invoked, as specified in NIST SP 800-171 AU requirements.

Key terms glossary

Controlled Unclassified Information (CUI): Information the U.S. government creates or possesses, or that an entity creates or possesses on behalf of the government, that requires safeguarding under law or regulation but is not classified.

Deemed export: Under ITAR 22 CFR 120.17, the release of ITAR-controlled technical data to a foreign person within the United States, treated as an export to that person's country of nationality even if the data never leaves U.S. territory.

CMMC Level 2: The Cybersecurity Maturity Model Certification level applying to defense contractors handling CUI, requiring implementation of all 110 NIST SP 800-171 Rev. 2 controls and third-party assessment by a C3PAO.

AI Security Posture Management (AI-SPM): A category of tools that continuously discover, assess, and report on AI assets and their configurations, focused primarily on build-side inventory and configuration risk. AI-SPM alone does not provide runtime enforcement on active agent calls; runtime enforcement is a separate capability category (see AI-DR).

AI-DR (AI Detection and Response): A capability category that combines real-time monitoring with in-line enforcement actions (redaction, masking, blocking) on agent behavior. The architectural distinction from a self-hosted control plane is where enforcement decisions are computed: inside the customer's perimeter or in vendor-hosted infrastructure.

Runtime enforcement: AI governance controls that intercept, evaluate, and act on agent calls before the call completes, as distinct from retrospective log review or post-hoc alerting.

Model Context Protocol (MCP): A protocol for structuring context and data exchange between AI models and external systems, including MCP servers that manage tool calls and data pipelines.

AI Bill of Materials (AIBOM): A structured inventory of AI system components in CycloneDX format, produced as an exportable byproduct of AI System registration, enabling organizations to report on which models, tools, and datasets are in production.

C3PAO: A CMMC Third-Party Assessment Organization, authorized to conduct official CMMC Level 2 and Level 3 assessments for defense contractors seeking certification.