Noma Security limitations: what the documentation doesn't tell you about deployment architecture

Updated July 21, 2026

TL;DR: Regulated enterprises evaluating Noma Security must look past marketing claims to understand its underlying hybrid architecture. While Noma offers runtime policy enforcement, its deployment model requires outbound HTTPS connectivity to api.noma.security:443 via its Kong Gateway plugin, making it incompatible with strictly air-gapped environments or sovereign private clouds. For organizations in defense, financial services, and manufacturing, this external telemetry routing raises material data residency questions. Resolving these bottlenecks requires a self-hosted control plane where all governance logic, policy enforcement, and audit logs remain entirely within your perimeter.

When evaluating any AI governance tool, the most critical question is not what the vendor's dashboard shows, but where the telemetry routes before an enforcement decision is returned, and which external servers receive that data during that process.

This analysis examines the operational and architectural constraints of Noma Security, specifically its outbound connectivity requirements and the data residency implications those requirements create.

It maps those constraints against AIUC-1, ISO/IEC 42001, and the OWASP Top 10 for Agentic Applications 2026 to give risk and compliance directors and CISOs a defensible architecture evaluation.

Operational constraints of Noma deployments

System-level AI governance must enforce policy where the data lives, not at a vendor-mediated checkpoint outside your perimeter. The core architectural question in any AI governance evaluation is whether enforcement logic runs inside your infrastructure or outside it. Noma Security offers a hybrid model: an agent or Kong Gateway plugin runs inside the customer's environment, but policy decisions and telemetry route to Noma's SaaS backend for evaluation. This distinction matters in every regulated environment where the AIUC-1 Data and Privacy pillar, ISO/IEC 42001 third-party controls, or EU AI Act data handling requirements apply.

A policy that exists in a vendor's external dashboard but runs its enforcement logic outside your perimeter does not qualify as system-level control. It is a vendor-mediated checkpoint. That difference becomes visible the moment an examiner asks you to produce an architecture diagram showing the exact path your AI inputs take before a governance verdict is returned.

Mandatory cloud connectivity requirements

Noma's runtime enforcement capability operates through a Kong Gateway plugin. Noma's Kong Gateway plugin documentation confirms that Kong Gateway nodes must have outbound HTTPS access on port 443 to api.noma.security. Kong's documentation identifies https://api.noma.security as the endpoint for all policy decisions. In blocking mode (synchronous enforcement), the plugin must wait for a verdict from Noma's external infrastructure before a request can proceed.

This is not a configurable option or an edge-case integration path. It is the documented architecture for Noma's runtime enforcement. Every agent interaction that passes through the Kong Gateway plugin depends on a successful outbound connection to an external vendor endpoint before that interaction is allowed, blocked, or modified. For enterprises with strict data perimeter requirements, governed AI traffic does not stay inside the perimeter during the enforcement phase. It leaves, receives a verdict, and returns.

The AIUC-1 standard's Data and Privacy pillar covers customer data policies, access controls, and safeguards against data leakage. Routing AI inputs to an external endpoint during policy evaluation raises direct questions under those controls, and an AIUC-1 assessor will ask about that flow during a conformity review.

Infrastructure gaps in air-gapped sites

For defense-adjacent, federal, and manufacturing workloads handling controlled unclassified information or sensitive IP, air-gapped deployment is often a hard requirement. Organizations deploying in zero-egress environments should evaluate whether an architecture that requires outbound HTTPS to an external server for enforcement decisions is compatible with their network security requirements and zero-egress policies.

Noma's public documentation references support for self-hosted deployments, but the Kong Gateway plugin architecture creates an outbound dependency that is structurally incompatible with zero-egress environments. A hybrid model where one component runs locally but depends on an external API handshake for enforcement decisions does not meet the standard for a true air-gapped deployment.

We deploy the entire control plane, including all governance logic, policy evaluation, and factual consistency checking, inside your infrastructure with no outbound connectivity requirement.

Assessing Noma deployment latency

The latency cost of external round-trips compounds across multi-call agentic workflows. In synchronous blocking mode, Noma's Kong Gateway plugin must wait for a verdict from api.noma.security before a request can proceed. Each governed interaction carries the overhead of an external network round-trip, plus any variance introduced by geographic distance between your infrastructure and Noma's SaaS backend. For real-time applications, manufacturing line monitoring, pre-hospital decision support, and financial transaction evaluation, that overhead is material.

Local enforcement eliminates the round-trip entirely. All policy evaluation runs inside your environment. The Practical AI podcast episode, co-hosted by Prediction Guard founder Daniel Whitenack, covers where enforcement logic runs and why vendor-mediated checkpoints break the trust boundary that regulated data depends on.

Resolving Noma Security data residency bottlenecks

Defensible data residency requires that AI inputs, governance logic, and enforcement verdicts remain inside the organization's defined perimeter during every phase of a transaction. Hybrid architectures create a category of compliance risk that does not appear in vendor dashboards: the moment AI inputs leave the customer's network perimeter, even briefly and even over an encrypted channel, the organization's ability to assert uninterrupted data sovereignty over those inputs becomes legally ambiguous under multiple frameworks.

Locating your sensitive AI data

When an agent call passes through Noma's Kong Gateway plugin in synchronous blocking mode, the input, which includes prompts, retrieved documents, database results, and tool call outputs, must transit to api.noma.security:443 for a policy verdict. That transit happens before the model processes the request. Organizations handling Controlled Unclassified Information (CUI), ITAR-controlled data, non-public personal financial information under GLBA, or regulated health information should evaluate whether this routing pattern is compatible with their applicable data handling obligations before deployment.

The practical problem is not whether the connection is encrypted. The customer no longer controls the data's location exclusively during the enforcement phase. Any third-party incident affecting Noma's infrastructure during that transit, including an outage, a security event, or a change in Noma's data handling terms, directly affects the customer's risk and compliance posture for interactions in flight at that moment.

Our self-hosted vs. cloud AI deployment guide covers this distinction in architectural terms: when regulated data is in scope, a compliance team cannot defensibly audit a trail that depends on a vendor's external infrastructure. That principle applies to governance tools, not just the models themselves.

Managing cross-border data transfer risks

For enterprises with EU operations, customers, or supply chains, the EU AI Act's requirements on data handling and auditability create specific obligations around where AI governance evidence resides and who can access it. An outbound telemetry dependency to a SaaS backend raises architecture questions that risk and compliance teams should evaluate against applicable framework requirements during conformity assessments. Organizations with EU-based workloads should confirm the jurisdictional location of Noma's infrastructure to determine whether AI inputs processed during policy evaluation may be subject to cross-border data transfer requirements.

Regional U.S. legislation adds further complexity for organizations with multi-state operations. California's TFAIA introduces transparency and risk management provisions relevant to developers of frontier AI models, while Colorado's AI Act introduces reasonable care obligations for developers and deployers of high-risk AI systems. For organizations subject to either law, demonstrating that governance operates exclusively within defined data boundaries becomes harder when enforcement logic requires an external handshake for every governed interaction.

Addressing multi-region audit risks

When an AIUC-1 assessor, an ISO/IEC 42001 third-party conformity assessor, or a CMMC third-party assessment organization (C3PAO) asks for the architecture diagram showing the exact path AI inputs take during a policy evaluation, that diagram needs to show the path accurately. If the accurate diagram includes an outbound connection to api.noma.security:443, that is a finding, not a detail.

ISO/IEC 42001 Annex A controls on third-party and customer relationships require organizations to clearly define responsibilities and appropriately share risks when AI systems involve partners, suppliers, or customers. An external policy evaluation endpoint is a supplier relationship for every AI interaction your system processes. Documenting, assessing, and continuously monitoring that relationship is a control obligation. Our NIST AI RMF implementation playbook covers how to structure those mapping tables for auditable evidence packages.

Automating policy enforcement for AI audit readiness

Audit-ready governance requires logs generated by enforcement logic running inside your perimeter, immediately available to your SIEM without transiting vendor infrastructure, and producible to an examiner without depending on a vendor portal's availability. The structural requirement for regulated enterprises is not just that a governance log exists, but that the customer controls where it is generated, where it is stored, and who can access it.

Configuring log retention periods

We do not store audit logs. The control plane generates structured, SIEM-ready audit log output locally within your infrastructure during each enforcement decision. Your SIEM (Splunk, Datadog, or generic syslog targets) consumes that output immediately. Your own infrastructure handles storage, retention, and search entirely, under your own access controls and retention schedules. The evidence trail never leaves your environment.

Data residency and export constraints

When a governance log is stored in a vendor portal, extracting it during an unscheduled audit requires the vendor's export tools, API access, and availability. Historical audit logs stored in a vendor's SaaS platform depend on the vendor's export tooling and data retention policies for retrieval. During an unscheduled examiner inquiry, your ability to produce evidence on the examiner's timeline depends entirely on the vendor's API availability.

Our scaling agentic AI blog post addresses this directly in the context of audit readiness at enterprise scale. Governance documentation that lives in a vendor portal is not the same as governance documentation that lives in your SIEM, indexed, searchable, and retrievable under your team's own access controls.

SIEM ingestion and schema constraints

Our SIEM integration does not require you to hand over SIEM credentials, API keys, or HEC tokens. The integration configures how the control plane formats its audit log output to match the native field structure that each target SIEM expects. The Admin Console flow works as follows:

1. Open the Monitor page in the Prediction Guard Admin Console.
2. Click Configure under the target integration (Splunk, Datadog, CrowdStrike, or syslog).
3. Confirm to make the integration live.
4. The control plane formats audit log output using the field structure the SIEM expects natively once the integration is live.

We never hold SIEM API keys, HEC tokens, or endpoint credentials. Your existing ingestion pipeline handles delivery under your own controls. This matters to a security operations team because the governance tool itself is not a credential store and cannot be compromised to access SIEM infrastructure. Our real-time monitoring blog post covers what to track and alert on within this architecture.

Evidence collection during vendor incidents

When a governance tool's audit trail depends on a SaaS platform's availability, your ability to produce AI governance evidence during an examiner inquiry depends on the vendor's operational status. SaaS platforms experience outages, security incidents, and maintenance windows, any of which can block audit evidence retrieval at the moment it is needed most.

Because we generate audit logs locally and forward them to your SIEM at the moment of enforcement, your evidence package is available through your own systems, independent of our operational availability.

Vendor access and third-party risk in Noma deployments

Any vendor whose product maintains an outbound connection to an external endpoint creates a third-party access relationship that the customer must assess, document, and continuously monitor under ISO/IEC 42001 Annex A. That assessment is a control obligation, not a courtesy.

Vendor access and support boundaries

The Kong Gateway plugin requires configuration and technical account management. Noma's documentation requires customers to contact their Noma Technical Account Manager to obtain the plugin file, client credentials, and schema configuration. This creates a support relationship where Noma personnel have knowledge of and access to the configuration of your enforcement infrastructure.

Debugging a hybrid enforcement architecture that spans customer infrastructure and a vendor's SaaS backend requires the vendor to have visibility into configuration data, request patterns, and in some cases the content of failing requests. That data exposure pathway is difficult to bound precisely in a contract or support agreement, and harder to document accurately for an audit. In a defense-adjacent environment handling CUI, or a financial services environment subject to GLBA examination, documenting and controlling that vendor relationship is a control requirement under ISO/IEC 42001's third-party provisions.

Supply chain dependencies in Noma deployments

The Kong Gateway plugin is a software component that includes Lua handler and schema configuration files standard to Kong's plugin architecture, and obtaining the plugin file, client credentials, and schema configuration requires coordination through a Noma Technical Account Manager. Each component represents a potential entry point for supply chain exposure if compromised, tampered with, or shipped with a known vulnerability. A governance tool that sits in the enforcement path for every AI interaction inherits this supply chain risk for every governed transaction.

The OWASP Top 10 for Agentic Applications 2026 identifies risks relevant to governance tools that introduce external endpoint dependencies and plugin components into the agentic enforcement path.

Solving integration gaps for air-gapped workloads

Enterprises that attempt to operate Noma's hybrid architecture in a restricted network environment face a fundamental tension: the enforcement architecture requires external connectivity, but the environment prohibits it. The result is a choice between disabling enforcement (accepting ungoverned agent interactions) or creating a complex proxy configuration to allow outbound traffic, which expands the attack surface the governance tool was intended to reduce.

Noma firewall deployment constraints

Allowing outbound HTTPS to api.noma.security:443 from a restricted environment requires firewall rule changes that introduce an approved external endpoint into the organization's network policy. In classified or highly restricted environments, each approved external endpoint is a documented exception subject to review, approval, and continuous monitoring, adding time and documentation obligations to what vendor marketing presents as a simple integration.

Managing Noma Security certificate constraints

Environments that implement SSL/TLS inspection on outbound traffic must either exempt the outbound HTTPS call to api.noma.security:443 from inspection (creating a visibility gap) or subject it to certificate management workflows that introduce operational overhead on every certificate rotation cycle. Neither option resolves the underlying data residency question about what content transits the connection.

Infrastructure gaps in private clouds

Private cloud environments that restrict external internet access implement those restrictions deliberately, typically to satisfy CMMC, ITAR, or internal data classification requirements. A hybrid enforcement architecture that requires outbound connectivity to function in full enforcement mode is structurally incompatible with that design intent. Workarounds (proxy servers, allow-listed endpoints, outbound tunnel configurations) add complexity without eliminating the underlying exposure.

Solving data residency conflicts

We resolve this conflict by architecture, not by workaround. The entire control plane, including all policy evaluation, factual consistency checking, and audit log generation, runs inside your environment. Governance logic executes locally, the enforcement decision happens locally, and your SIEM receives the audit log locally. There is no outbound connectivity requirement for any enforcement function. Our AI engineers page covers the infrastructure requirements for self-hosted deployment across VPC, self-hosted, and air-gapped topologies.

Evaluating Noma Security vendor lock-in

Long-term governance program design requires evaluating not just how a tool performs at deployment but how portable the governance configuration is if the organization changes infrastructure, changes vendors, or needs to transition. Governance policies tied to a proprietary SaaS backend are not portable in the same way as policies enforced by a self-hosted control plane deployed under the customer's own infrastructure controls.

Policy portability across deployment environments

When governance policies live in a vendor's SaaS console and depend on a vendor's SaaS backend for evaluation, migrating those policies to a different environment means rebuilding them from scratch. The vendor's proprietary format and proprietary evaluation engine create direct lock-in to the vendor's continued operation, pricing, and policy.

Our governance configuration lives on the Govern page of the Admin Console and the control plane enforces it inside your own Kubernetes environment, VPC, or self-hosted infrastructure. The configuration does not depend on connectivity to a specific external backend. Hardware and infrastructure agnosticism is a design principle, not a marketing claim.

Exporting logs for compliance audits

Historical audit logs stored in a vendor's SaaS platform depend on the vendor's export tooling and data retention policies for retrieval. During an unscheduled audit, your ability to produce evidence on the examiner's timeline depends entirely on the vendor's API availability and export throughput.

Because we generate logs locally and route them to your SIEM at the moment of enforcement, historical governance evidence is indexed and searchable in your own security infrastructure. Producing 90 days of AI governance evidence is a SIEM query, not a vendor API call.

Assessing Noma deployment exit barriers

Decommissioning a hybrid enforcement agent requires removing the Kong Gateway plugin from every Kong Gateway node and rebuilding policy enforcement logic in a replacement system. Policy configuration defined in Noma's proprietary console and evaluated by Noma's SaaS backend does not migrate automatically. The engineering team starts from scratch.

For Prediction Guard, the developer integration is a base_url repoint in existing OpenAI- or Anthropic-compatible SDK calls. Removing the control plane from the deployment path requires reverting that configuration change. No Kong plugins to uninstall, no proprietary schema files to migrate, no vendor Technical Account Manager involvement required.

Architectural comparison

If your architecture evaluation needs to produce a defensible answer to "where does our AI governance data go before an enforcement decision is returned?", the answer for a hybrid SaaS enforcement model is: outside your perimeter, to a vendor's external endpoint, on every governed interaction. That answer creates a finding in every framework that demands data sovereignty, and it is not a configuration option. It is the documented architecture.

For organizations in manufacturing, financial services, and defense-adjacent workloads, that finding does not require a workaround. It requires a different architecture. Book a deployment scoping call to assess whether a fully self-hosted deployment fits your infrastructure and compliance requirements.

FAQs

Does Noma Security support fully air-gapped deployments?

Noma's hybrid architecture requires outbound HTTPS connectivity to api.noma.security:443 for telemetry and policy execution via its Kong Gateway plugin. Organizations deploying in zero-egress air-gapped environments should evaluate whether this outbound dependency is compatible with their network security requirements.

Where are Prediction Guard's audit logs stored?

We do not store or retain audit logs. The control plane generates structured, SIEM-ready logs locally within your infrastructure during each enforcement decision, and your Splunk, Datadog, or syslog instance consumes them directly under your own access controls.

Does Prediction Guard require developers to rewrite their code?

No. Developers repoint base_url in their existing OpenAI- or Anthropic-compatible SDK calls to the Prediction Guard endpoint. Governance enforcement is transparent and requires no other code changes.

What AIUC-1 pillars are most relevant to hybrid SaaS telemetry?

The Data and Privacy pillar is most directly relevant because it covers customer data policies, access controls, and safeguards against data leakage. Organizations should evaluate how hybrid architectures affect their specific compliance requirements when enforcement logic and audit logs involve third-party infrastructure. Organizations should also review how their deployment model aligns with the Security and Accountability pillars' obligations, particularly where enforcement logic and audit logs involve third-party infrastructure outside the customer's direct control.

How does Prediction Guard handle SIEM integration without holding credentials?

We configure audit log output formatting natively for Splunk, Datadog, CrowdStrike, and syslog targets through the Monitor page in the Admin Console. Your existing ingestion pipeline handles delivery. We never store, manage, or test SIEM API keys, HEC tokens, or endpoint credentials.

Can Prediction Guard run in a private cloud that restricts external internet access?

Yes. The entire control plane, including policy enforcement, factual consistency checking, and audit log generation, runs inside your infrastructure with no outbound connectivity requirement for any enforcement function.

Key terms glossary

Sovereign AI control plane: An internal software infrastructure deployed entirely within an organization's security perimeter to compose, secure, and govern AI systems across disparate models, tools, and MCP servers, with no requirement for outbound vendor connectivity during enforcement.

Active runtime enforcement: The real-time evaluation and modification of AI inputs and outputs at the API level before a transaction completes. The control plane executes enforcement locally within the customer's infrastructure rather than routing to an external verdict endpoint.

AIUC-1: A cross-framework standard built on six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, and Society) used to assess and certify AI system conformity. Its crosswalk maps to NIST AI RMF, ISO/IEC 42001, and other frameworks.

Hybrid SaaS enforcement: A deployment model where a governance agent or plugin runs inside the customer's Kubernetes cluster but routes policy decisions and telemetry to an external SaaS backend for evaluation, creating an outbound dependency on vendor infrastructure during each governed interaction.

Zero-egress architecture: A deployment topology in which no component of the governance infrastructure attempts outbound network connections. All telemetry, policy evaluation, and log generation occur locally within the customer's defined perimeter.