How to migrate from Noma Security to Prediction Guard: step-by-step migration guide

Updated July 17, 2026

TL;DR: Migrating from Noma Security to Prediction Guard transitions your organization from an external, gateway-based security model to a fully self-hosted sovereign AI control plane. Noma's Kong Gateway plugin requires outbound HTTPS to api.noma.security:443, routing telemetry outside your perimeter. Prediction Guard runs entirely within your secure environment, keeping all AI governance policy enforcement, model interactions, and audit logs inside your infrastructure. This guide provides a phased migration approach that helps security teams map policies, export historical audit logs, and execute a controlled cutover while producing evidence that supports your AIUC-1 crosswalk obligations and NIST AI 600-1 requirements.

If your AI security tool requires an outbound connection to a vendor's API to enforce policies, you haven't secured your perimeter. You've moved the boundary. For CISOs in regulated industries, that distinction matters in every Federal Financial Institutions Examination Council (FFIEC) examination, DCSA assessor review, and board-level risk discussion.

Noma Security provides broad posture management and runtime AI governance policy enforcement, but its SaaS-integrated architecture routes telemetry outside the customer's perimeter. Prediction Guard's self-hosted architecture keeps all AI governance policy enforcement, model interactions, and audit logs inside your infrastructure.

This guide is a technically precise playbook for migrating from Noma Security to Prediction Guard's self-hosted AI governance infrastructure without interrupting production AI workflows. By following the four phases defined in this guide (Discovery and Inventory, Policy Translation, Parallel Run, and Full Cutover), your security team can execute a controlled migration that preserves audit log continuity and validates enforcement parity before shifting production traffic.

Assessing current AI risk and control gaps

Before touching a single configuration file, your security team needs a complete picture of what you're migrating. Missing a AI governance policy or a model endpoint during this phase means a governance gap after cutover.

Inventory active Noma security controls

Document every active runtime AI governance policy in your Noma deployment: prompt injection filters, PII masking rules, toxicity thresholds, and any custom detection policies. Export AI governance policy definitions as JSON where Noma's API supports it, and document threshold values, affected model endpoints, and the business requirement each AI governance policy satisfies. This inventory becomes your AI governance policy translation source in Phase 2.

Catalog existing governance policies and AI inventory

Map each Noma control to the organizational requirement it satisfies and the target framework alignment:

Alongside this mapping, review every model, tool, Model Context Protocol (MCP) server, and AI-integrated application currently registered in Noma. Capture the model name and version, the hosting endpoint, the team owner, the data classification tag, and the governance AI governance policy applied to each asset. This is what your team recreates inside Prediction Guard's AI System registration workflow.

Map SIEM and logging integrations

Document every active SIEM forwarding path from Noma: the target SIEM (Splunk, Datadog, CrowdStrike, or syslog), the field schema currently in use, and any parsing rules your security operations team relies on. Your team uses this documentation to configure Prediction Guard's Monitor page integration and validate log parity during the parallel run.

Managing downtime risks during your migration

The migration design targets zero downtime by keeping Noma enforcing AI governance policy on live traffic throughout the parallel run. You run both systems simultaneously until you've confirmed enforcement parity, then shift traffic.

Minimize operational impact during cutover

Deploy Prediction Guard's self-hosted control plane in parallel with Noma before touching any production traffic. Route duplicate traffic through Prediction Guard for validation while Noma continues enforcing AI governance policy on live production calls. This gives your security operations team representative enforcement data before any production risk is introduced. The Episode 360 of Practical AI, co-hosted by Prediction Guard CEO Daniel Whitenack with Chris Benson, covers why parallel validation is especially critical for autonomous agent deployments, where a single missed AI governance policy gap can propagate across multi-step tool chains.

Identify critical failure triggers

Define rollback thresholds before the parallel run begins. Document your team's acceptable bounds for 99th percentile (P99) latency increase above the baseline established during the parallel run, HTTP 5xx error rates, AI governance policy enforcement divergence from Noma's baseline on identical test payloads, and SIEM ingestion timing. Establish these thresholds in writing before Phase 3. An undocumented rollback trigger is an assumption, not a control.

Align cross-functional stakeholders

Legal, GRC, and Engineering need alignment on the migration timeline before Phase 1 begins. Engineering needs to know that no code rewrites are required, as only the API endpoint configuration changes at cutover. GRC needs confirmation that audit log continuity is maintained throughout. Legal needs the data-flow documentation showing that no production data transits Prediction Guard's systems during or after migration. The Prediction Guard AI engineers overview provides a reference architecture you can adapt for that stakeholder document.

Deploying Prediction Guard in your self-hosted environment

This phase prepares your infrastructure for the parallel validation run so your infrastructure team can deploy and validate the control plane while your security team completes the Noma inventory.

Resource prerequisites for migration

Prediction Guard's control plane runs on CPU only. Models can run on GPU or CPU depending on workload. Supported deployment targets include:

• Kubernetes cluster (cloud VPC or self-hosted data center)
• Air-gapped environments with no external connectivity
• AWS VPC deployment

For regulated environments where external connectivity is restricted, ensure your deployment target supports air-gapped operation with no external connectivity requirements.

Hardening your network perimeter

After deployment, verify that all control plane traffic stays inside your perimeter. Prediction Guard enforces policy on every model call before the call completes, and generates structured audit logs that your existing SIEM ingestion pipeline consumes. No governance data transits Prediction Guard's systems.

This is the architectural contrast with Noma's SaaS-integrated model: Noma's Kong Gateway plugin requires outbound HTTPS to api.noma.security:443, routing telemetry outside your environment. Prediction Guard's self-hosted architecture keeps governance logic and audit logs within your infrastructure. For regulated environments handling Controlled Unclassified Information (CUI) or data subject to International Traffic in Arms Regulations (ITAR), that distinction determines whether your AI governance evidence package survives a Defense Counterintelligence and Security Agency (DCSA) assessor's data-flow inquiry or an AIUC-1 assessor's controls review.

Mapping AI audit logs to your SIEM

Configure SIEM formatting on the Monitor page of the Prediction Guard Admin Console using this four-step flow:

1. Open the Monitor page in the Admin Console.
2. Click Configure under your chosen integration (Splunk, Datadog, CrowdStrike, or generic syslog).
3. Confirm to activate the integration.
4. The live integration signals Prediction Guard to format audit log output using the field structure your SIEM expects natively.

Prediction Guard does not hold SIEM credentials, store API keys or HEC tokens, or test the SIEM connection. The control plane formats output only. Your existing ingestion pipeline, whether a Splunk HEC endpoint, Datadog agent, or syslog collector, handles delivery under your own controls.

Extracting Noma Security data for migration

This phase covers everything your team needs to pull from Noma before decommissioning it: AI inventory records, AI governance policy definitions, and historical audit logs. Nothing should be lost at the point of cutover.

Extracting Noma AI inventory and AI governance policy data

Your team should export registered models, tools, and agent configurations from Noma's Admin Console. Where Noma's API supports bulk export, pull the full inventory in JSON format. Capture at minimum: model name and version, associated endpoint, team owner, active governance policies, and data classification. Your GRC team should also export Noma's runtime AI governance policy definitions as JSON, documenting the control category, threshold or rule definition, affected endpoints, and the framework requirement each AI governance policy maps to.

Export Noma audit logs for SIEM

Your security operations team must extract historical audit logs from Noma and ingest them into your SIEM before decommissioning Noma's gateway. This preserves audit log continuity for any examination spanning the migration date:

1. Your team should export historical audit logs from Noma's SaaS backend in your SIEM's native format.
2. Ingest the exported logs with a clear source label indicating they originate from Noma's pre-migration enforcement period.
3. Verify that ingested historical logs are searchable and parseable alongside Prediction Guard's live log output.
4. Archive raw exported files in a separate immutable storage location as a secondary record.

Prediction Guard generates structured audit logs that your SIEM stores and retains. Prediction Guard does not store or retain logs. Storage is a SIEM responsibility, not a control plane responsibility.

Mapping security rules to Prediction Guard

Use this control-to-requirement mapping table to guide AI governance policy translation from Noma to Prediction Guard's native controls:

Automating AI governance policy enforcement for AI workflows

This is where you move from inventory documentation to active, system-level runtime enforcement. Policies configured on the Govern page of the Admin Console are enforced on every model call before the call completes, not flagged after the fact.

Map Noma policies to NIST AI 600-1 functions

NIST AI 600-1, released in July 2024, maps generative AI risk to the four core NIST AI RMF 1.0 functions. Organize translated policies by the function they satisfy:

• Govern: Governance activities such as AI governance policy definitions, access controls, and ownership assignments.
• Map: AI System registration, data classification tags, and AIBOM export documenting which assets are in scope.
• Measure: Factual consistency checking, prompt injection detection rates, and PII redaction confirmation, all logged per interaction.
• Manage: Real-time block and rewrite actions logged as SIEM-forwarded enforcement events, providing the evidence package that satisfies the Manage function's incident-response documentation requirements.

The NIST AI RMF implementation playbook maps specific control plane capabilities to each RMF function with evidence-package guidance for audit preparation.

Operationalizing AI governance policies

Configure translated policies on the Govern page of the Admin Console:

• PII detection and masking rules with the appropriate redaction mode (mask, filter, block, or replace) per data classification.
• Toxicity thresholds calibrated to match or exceed your Noma baseline.
• Factual consistency checking, which evaluates model-generated outputs against trusted reference data to detect hallucinations before they reach downstream systems. This is a probabilistic verification process, not deterministic enforcement.
• Prompt injection defenses covering direct injection vectors aligned with OWASP LLM01.

For agentic workflows, indirect injection vector coverage is governed by the OWASP Top 10 for Agentic Applications 2026 controls applied as system-level agent behavior controls within the control plane.

AIBOM import and model inventory setup

With your Noma inventory exported, your team now recreates that asset record inside Prediction Guard's AI System registry and generates a CycloneDX AIBOM as the post-migration compliance baseline.

Importing AIBOM data to Prediction Guard

For each model, MCP server, and dataset extracted from Noma's inventory, create an AI System registration in Prediction Guard. The registration captures model name and version, hosting endpoint, team owner, data classification, and known limitations. The AIBOM in CycloneDX format is the exportable byproduct of this registration.

Use this reconciliation checklist to confirm complete inventory coverage:

• Every model endpoint active in Noma is registered in Prediction Guard's AI System registry.
• Every MCP server or external tool integrated with agentic workflows is registered and tagged with its data classification.
• Every dataset used in RAG or factual consistency checking is documented with its classification and access controls.
• AIBOM export in CycloneDX format is generated and validated for schema completeness.

Mapping agentic behavior for audits

For agentic workloads, register every MCP tool and agent workflow as a component inside the relevant AI System. The OWASP Top 10 for Agentic Applications 2026 identifies agentic supply chain risks, where agents discover and integrate components at runtime including MCP servers, tools, and external APIs, as a primary attack surface. Registering these components ensures that every agentic interaction is covered by the AI governance policy applied to that system, and that the AIBOM reflects the complete dependency graph for assessor review.

Ensuring continuous audit readiness during migration

Migration readiness self-assessment for your security team:

Run comparative AI governance policy enforcement tests

Before shifting live traffic, your team should send a standardized test payload suite through both Noma and Prediction Guard simultaneously. Test payloads must cover direct prompt injection attempts, PII patterns matching your masking rules, toxic output triggers at and below your configured thresholds, and benign requests that should pass all policies without modification. Compare block rates, rewrite rates, and pass rates across both systems. Significant divergence in any AI governance policy category requires threshold adjustment before proceeding to full cutover.

Verify log format and SIEM ingestion

During the parallel run, your security operations team should verify that Prediction Guard's generated audit logs are correctly parsed by your SIEM. Verify:

• Field names and types match what your SIEM expects from the Monitor page integration configuration.
• Timestamp formats align with your existing SIEM retention and search policies.
• AI governance Policy violation events appear with the correct severity classification in your SIEM's alerting queue.
• Benign-pass events are logged alongside enforcement events, providing a complete per-interaction audit record.

Cutover execution and post-migration validation

This section walks through each cutover phase in sequence, the developer-facing configuration change, and the compliance artifact generation steps your team completes immediately after full cutover.

The phased cutover checklist

Phase 1: Discovery and inventory

• Export active model inventory from Noma.
• Document all active runtime policies and thresholds.
• Map existing SIEM forwarding paths and field schemas.
• Export historical audit logs from Noma to your SIEM with a pre-migration source label.

Phase 2: AI governance Policy translation

• Map each Noma policy to Prediction Guard's native controls using the mapping table above.
• Configure PII, toxicity, and factual consistency checking rules on the Govern page.
• Set up SIEM formatting on the Monitor page for your target SIEM.

Phase 3: Parallel run

• Deploy Prediction Guard self-hosted control plane in Kubernetes or cloud VPC.
• Route duplicate production traffic to Prediction Guard for parallel validation.
• Run comparative enforcement tests across all AI governance policy categories.
• Verify log formatting and SIEM ingestion integrity over sufficient representative traffic.
• Verify all rollback thresholds are defined and documented before proceeding.

Phase 4: Full cutover

• Update developer environment variables (base_url) to point to the Prediction Guard endpoint.
• Confirm active runtime enforcement on live production traffic in SIEM.
• Decommission Noma gateway plugins and API integrations.
• Archive Noma historical logs with a pre-migration date label.
• Export CycloneDX AIBOM as the post-migration governance and compliance baseline.

Executing the developer cutover

Developers do not rewrite application code. Existing OpenAI-compatible and Anthropic-compatible SDK calls work unchanged, as only the base_url changes to point at your Prediction Guard control plane endpoint. Governance is enforced transparently by the control plane on every call.

OpenAI SDK cutover:

import os from openai import OpenAI  # Change only this line client = OpenAI(     base_url="https://your-prediction-guard-endpoint.internal/v1",     api_key=os.environ["PG_API_KEY"] )  response = client.chat.completions.create(     model="your-registered-model",     messages=[{"role": "user", "content": "Summarize this report."}] ) 

Anthropic SDK cutover:

from anthropic import Anthropic import os  # Change only this line client = Anthropic(     base_url="https://your-prediction-guard-endpoint.internal",     api_key=os.environ["PG_API_KEY"] )  response = client.messages.create(     model="your-registered-model",     max_tokens=1024,     messages=[{"role": "user", "content": "Summarize this report."}] ) 

The control plane compatibility operates at the API spec level. Nothing routes through OpenAI or Anthropic servers. The Episode 312 of Practical AI covers the Model Context Protocol and its role in agentic AI workflows.

Verifying risk and compliance evidence packages

After full cutover, generate your post-migration risk and compliance artifacts:

1. Export the CycloneDX AIBOM from the AI System registry as the authoritative post-migration asset inventory.
2. Pull a SIEM log extract covering the cutover period to confirm the audit log is continuous from the cutover timestamp.
3. Run your comparative test payload suite one final time to confirm enforcement behavior matches the parallel-run baseline.
4. Produce an evidence package containing the AIBOM, the SIEM log extract, and the enforcement test results. This is the artifact you present to an AIUC-1 assessor or enterprise procurement reviewer to demonstrate that AI governance is active and sovereign within your perimeter.

The Prediction Guard product comparisons page provides cross-framework comparison context you can use to document why the architectural transition satisfies your AIUC-1 and NIST AI 600-1 obligations in ways that an external gateway model cannot.

Migration troubleshooting and best practices

This section covers the most common decision points your team will encounter during migration: whether to run in parallel or cut over directly, how to handle a rollback, and how to preserve a continuous audit log across both enforcement systems.

Parallel runs vs. direct cutovers

A direct cutover, where Noma is decommissioned before Prediction Guard is validated on live traffic, creates a governance gap between decommission and validation. A phased parallel run reduces that gap by providing quantifiable enforcement evidence before any production risk is introduced. Because Prediction Guard runs alongside Noma during Phase 3, with Noma enforcing AI governance policy on live traffic while Prediction Guard validates against duplicate traffic, the Phase 4 cutover requires only API endpoint configuration changes per application.

Handling rollbacks

If any critical failure threshold is breached during the parallel run or immediately post-cutover, revert the base_url environment variable to your Noma endpoint:

# Revert OpenAI SDK export OPENAI_BASE_URL="https://your-noma-endpoint.com/v1"  # Revert Anthropic SDK export ANTHROPIC_BASE_URL="https://your-noma-endpoint.com" 

After reverting, confirm that API calls are returning to the Noma endpoint and that your SIEM continues receiving audit events. If Noma remained active during validation, reverting the endpoint configuration restores the previous enforcement path.

Preserving historical audit logs

Archive Noma's exported logs in your SIEM with a consistent source label before decommissioning Noma's gateway. This ensures that any FFIEC examiner, DCSA assessor, or AIUC-1 reviewer requesting logs spanning the migration date sees a continuous record across both enforcement systems. Prediction Guard's live SIEM logs begin when the cutover completes. Everything before that timestamp is covered by the archived Noma export.

To discuss deployment scoping for your specific infrastructure and risk and compliance requirements, book a deployment scoping call with the Prediction Guard team.

FAQs

How much downtime is expected during the migration from Noma to Prediction Guard?

The migration design targets zero downtime. The parallel-run architecture keeps Noma enforcing AI governance policy on live production traffic throughout the migration while Prediction Guard validates in parallel, and the final Phase 4 cutover requires only API endpoint configuration changes.

Does Prediction Guard store our historical Noma audit logs after migration?

No. Prediction Guard generates structured, SIEM-ready audit logs in real time but does not store or retain any logs. Historical Noma logs must be exported from Noma's platform, ingested into your SIEM with a pre-migration source label, and retained there under your organization's own data retention policies.

How do we migrate Noma's proprietary AI governance policy configurations to Prediction Guard?

Your GRC team should export Noma's AI governance policy configurations as JSON and manually map them to Prediction Guard's native controls using the control-to-requirement mapping table in this guide. Translated policies are then configured on the Govern page of the Prediction Guard Admin Console.

Do developers need to rewrite their application code after migration?

No. Developers change one environment variable, the base_url in their OpenAI-compatible or Anthropic-compatible SDK configuration, and existing code continues to work unchanged. Prediction Guard enforces governance transparently at the control plane level before every model call completes.

What risk and compliance evidence does the migration produce for an AIUC-1 assessor?

The migration produces three evidence artifacts that directly support AIUC-1 assessment: a CycloneDX AIBOM exported from the AI System registry, a continuous SIEM audit log covering enforcement decisions from the cutover timestamp forward, and the comparative enforcement test results from the parallel-run validation phase. Documentation supporting Legal Policies and Third-party Evaluations may require additional artifacts depending on your organization's risk and compliance scope.

What happens to agentic AI workloads during the parallel run phase?

Agentic workloads continue running through Noma's enforcement layer during Phase 3. Duplicate traffic is routed to Prediction Guard for validation. Registering MCP servers and tool endpoints in Prediction Guard's AI System registry before full cutover ensures every agentic tool call is covered by AI governance policy from the moment the base_url changes.

Key terms glossary

Sovereign AI control plane: A self-hosted software infrastructure that runs entirely within a customer's secure perimeter to compose, secure, and govern AI systems without routing data to external vendor APIs.

Factual consistency checking: A probabilistic verification process that evaluates model-generated outputs against trusted reference data sources to detect hallucinations before they reach downstream systems. This is not deterministic enforcement.

AIBOM (AI Bill of Materials): A structured inventory of AI assets, including models, datasets, tools, and dependencies, exported in CycloneDX format to provide risk and compliance evidence for assessors and examiners.

Runtime policy enforcement: The active evaluation and modification (blocking, allowing, or rewriting) of AI inputs and outputs at the API level in real time, before the model transaction completes.

CycloneDX: An open standard for software and AI/ML bills of materials, with machine-learning support added in version 1.5 (June 2023), capturing model architecture, training setup, dataset references, performance metrics, and bias and safety considerations.

AIUC-1: A cross-framework AI governance specification organized around six pillars (Data and Privacy, Security, Safety, Reliability, Accountability, and Society) with published crosswalks to major standards and regulations at aiuc-1.com/crosswalks.

MCP (Model Context Protocol): A protocol enabling AI systems to interact with external tools, servers, and data sources at runtime, commonly used in agentic workflows to extend agent capabilities beyond their base model.

CUI (Controlled Unclassified Information): U.S. government-designated information that requires safeguarding or dissemination controls pursuant to federal law, regulation, or AI governance policy, but does not meet the standards for classification under Executive Order 13526.

ITAR (International Traffic in Arms Regulations): U.S. regulations controlling the export and import of defense-related articles and services on the United States Munitions List (USML).

FFIEC (Federal Financial Institutions Examination Council): U.S. interagency body that prescribes uniform principles, standards, and report forms for federal examination of financial institutions.

DCSA (Defense Counterintelligence and Security Agency): U.S. federal agency responsible for protecting cleared U.S. defense information, personnel, and facilities from foreign intelligence threats.

GLBA (Gramm-Leach-Bliley Act): U.S. federal law requiring financial institutions to explain information-sharing practices and safeguard sensitive customer data.