Skip to main content

AxonFlow for Government & Public Sector

Federal agencies and public sector organizations are deploying AI for citizen services, regulatory analysis, defense logistics, and scientific research. These workloads require governance that runs inside government networks, produces audit evidence for Inspector General and GAO review, and provides deterministic human oversight on consequential decisions. An AI agent that processes citizen SSNs, drafts regulatory findings, or optimizes defense supply chains cannot send data to a third-party SaaS for policy evaluation -- the governance layer must run where the data lives.

AxonFlow provides the runtime governance layer that sits between AI agents and the actions they take -- enforcing policies, detecting PII before it reaches LLM providers, gating high-risk decisions for human review, and producing the structured audit trail that oversight bodies require. This page maps AxonFlow capabilities to government workflows, regulatory requirements, and deployment patterns. Everything described here is shipped and available today.

The government AI governance challenge​

NIST AI RMF requires Map, Measure, Manage, Govern​

The NIST AI Risk Management Framework (AI RMF 1.0) defines four core functions for AI governance: Map (understand the AI system's context and risks), Measure (assess and track identified risks), Manage (mitigate risks through controls), and Govern (establish accountability structures). Federal agencies adopting the AI RMF need technical controls that map directly to these functions -- not a governance whitepaper, but an enforcement layer that produces auditable evidence of risk management in real time. AxonFlow's policy enforcement, HITL approval gates, PII detection, and structured audit logging provide the Manage and Govern functions. The structured decision records with decision_id, verdict, evaluated policies, and timestamp provide the Measure function's evidence trail.

OMB M-25-21 and M-25-22 define the current federal direction​

OMB M-25-21 replaced M-24-10 in April 2025. It directs agencies to govern high-impact AI, maintain AI use-case inventories, monitor deployed systems, and establish processes for discontinuing systems that cannot meet required safeguards. OMB M-25-22 addresses AI acquisition, including data and intellectual-property rights, interoperability, vendor lock-in, performance, and post-award monitoring. AxonFlow can enforce customer-defined runtime policies and produce decision evidence that supports these processes; it does not complete an agency's inventory, impact assessment, acquisition review, or authorization obligations by itself.

FISMA and authorization boundaries shape deployment​

Federal agencies determine FISMA categorization, NIST SP 800-53 controls, authorization boundaries, and FedRAMP applicability from the system architecture and deployment model. A governance component inside a federal information system must be assessed within that authorization process. A self-hosted deployment can avoid introducing a separate AxonFlow-hosted SaaS data path, but it does not automatically inherit an existing Authority to Operate or remove assessment requirements.

AxonFlow supports this deployment path. AxonFlow can run self-hosted inside an agency-controlled environment. Governed traffic and audit records can remain there when model, connector, telemetry, and update paths are configured for the same boundary. The deployment can then be assessed as part of the agency's system authorization work. Source-available under BSL 1.1, AxonFlow can be inspected and built by the agency's security team.

Air-gapped and classified environments​

Defense and intelligence agencies operate networks that may have no connectivity to the public internet. AI governance tools that require cloud connectivity, license phone-home, or SaaS API calls are non-starters in these environments. AxonFlow's self-hosted deployment can run within the local network when model, connector, telemetry, and update paths are configured for that boundary. The BSL 1.1 source-available license allows your security team to review the codebase, build from source, and deploy on air-gapped infrastructure. Core governance capabilities -- PII detection, policy enforcement, HITL approval gates, audit logging, and circuit breaker -- do not require AxonFlow SaaS calls at runtime.

Use cases​

1. Public health analysis copilot​

What the agent does: A public health analysis copilot assists epidemiologists in analyzing disease surveillance data, identifying outbreak patterns, and drafting situation reports. It queries surveillance databases and case management systems via MCP connectors, and uses LLMs to summarize trends and draft communications.

What could go wrong: The copilot includes patient identifiers (SSNs, dates of birth, addresses) from case-level surveillance data in a prompt to an LLM. Or it drafts a public health recommendation without epidemiologist review. Or the surveillance database connector returns individual-level data that the copilot forwards to an unauthorized downstream tool.

How AxonFlow can help:

  • PII detection catches SSNs (area/group/serial validated), dates of birth, email addresses, phone numbers, and passport numbers before they reach an LLM. The action is configurable per path: block, redact, warn, or log. See PII Detection.
  • HITL approval gates pause public health recommendations for epidemiologist review. The require_approval policy action routes the step to a human approval queue where a qualified reviewer approves or rejects. Unanswered requests auto-expire after 24 hours in Evaluation tier.
  • MCP connector governance applies three-phase policy evaluation to connector calls routed through the governed MCP path: request phase, response phase, and exfiltration phase. Configured policies can block or redact disallowed transfers before the client proceeds.
  • Audit logging records policy evaluations and outcomes on governed steps, helping show which controls ran when the analysis was performed. See Audit Logging.

2. Regulatory document review agent​

What the agent does: A regulatory review agent ingests proposed rules, public comments, and existing regulations, then drafts analysis summaries, identifies conflicts with existing rules, and produces findings reports. It queries document management systems and legal databases via MCP connectors.

What could go wrong: The agent includes commenter PII (names, email addresses, addresses) from public comment submissions in an LLM prompt for summarization. Or the agent produces regulatory findings without subject-matter expert review. Or a prompt-injection attack embedded in a public comment manipulates the agent's analysis.

How AxonFlow can help:

  • PII detection catches email addresses (RFC 5322 validated), phone numbers, and other personal identifiers in public comment data before they reach an LLM. See PII Detection.
  • SQL injection scanning detects injection payloads in public comment text that could manipulate agent behavior. See SQL Injection Scanning.
  • HITL approval gates require subject-matter expert review on every regulatory finding before it is finalized. The approval queue integrates with existing review workflows.
  • Evidence export (Evaluation and Enterprise) produces audit packages suitable for IG review and GAO audit. See Evidence Export.
  • Audit logging records governed policy checks and reviewer identity when supplied. Document provenance and analytical lineage remain the responsibility of the regulatory-analysis system. See Audit Logging.
# Policy: require SME approval on all regulatory findings
name: regulatory-findings-approval
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.step_type
    operator: eq
    value: regulatory_finding

3. Citizen service agent​

What the agent does: A citizen service agent handles constituent inquiries across multiple channels: benefits eligibility questions, application status checks, appointment scheduling, and document submission assistance. It queries case management systems and benefits databases via MCP connectors.

What could go wrong: A citizen provides their SSN, date of birth, or bank account number in a service interaction and the agent includes it in an LLM prompt. Or the agent provides benefits eligibility guidance without human review, creating reliance liability. Or the citizen's personal data from one inquiry leaks to an unrelated downstream system.

How AxonFlow can help:

  • PII detection catches supported identifier types on configured governed paths. The action is configurable: block, redact, warn, or log. See PII Detection.
  • MCP connector governance applies three-phase policy evaluation to case-management and benefits calls routed through the governed MCP path. Configured exfiltration policies can block disallowed transfers before the client proceeds.
  • HITL approval gates can pause configured eligibility and case-disposition steps for caseworker review. The case system must enforce the approval result before communicating a determination. See HITL Approval Gates.
  • Privacy request support comes from audit trails, PII controls, and customer-owned deletion workflows in the authoritative case systems. AxonFlow's built-in tenant erasure flow is specific to Community SaaS/plugin tenant records, not citizen case-record deletion. See Trust Overview.
# Decision Mode: check a citizen service interaction before it reaches the LLM
curl -s -X POST http://localhost:8080/api/v1/decide \
  -H "Content-Type: application/json" \
  -d '{
    "stage": "llm",
    "caller_identity": {
      "gateway_id": "citizen-services-gw",
      "tenant_id": "benefits-division"
    },
    "target": {
      "type": "llm",
      "model": "llama-3",
      "provider": "self-hosted"
    },
    "query": "Check eligibility for applicant John Doe, SSN 078-05-1120, DOB 03/15/1975"
  }' | jq .
{
  "verdict": "deny",
  "decision_id": "d5a8c3b1-7e2f-4b9a-a1d3-8c5f2e7b4a6d",
  "trace_id": "4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b",
  "stage": "llm",
  "reasons": [
    "PII detected: SSN (area/group/serial validated)",
    "PII detected: date of birth pattern"
  ],
  "obligations": [],
  "evaluated_policies": ["sys_pii_ssn", "sys_pii_dob"],
  "expires_at": "2026-05-26T14:30:00Z"
}

4. Defense logistics optimization agent​

What the agent does: A logistics optimization agent analyzes supply chain data, predicts equipment maintenance needs, optimizes inventory distribution across bases, and generates procurement recommendations. It queries logistics databases and maintenance systems, and uses LLMs for demand forecasting and route optimization analysis.

What could go wrong: The agent fails silently when the LLM provider is unavailable, leaving supply chain decisions unmonitored during a critical period. Or the agent auto-executes a procurement action without the required authorization chain. Or a prompt containing classified logistics data is sent to an unauthorized LLM endpoint.

How AxonFlow can help:

  • Circuit breaker and kill switch (Enterprise) can block subsequent governed decision requests after a configured failure threshold. They do not cancel provider or tool work already dispatched. See Circuit Breaker.
  • HITL approval gates can require authorization on procurement recommendations and logistics decisions above configured thresholds before the integrating client proceeds. See HITL Approval Gates.
  • Self-hosted deployment keeps the governance layer inside the defense network. Logistics data remains within that boundary only when the selected model, connector, telemetry, and update paths are configured accordingly.
  • Audit logging records governed logistics decisions with policy outcomes and approver identity where those fields are supplied. See Audit Logging.

5. Environmental monitoring agent​

What the agent does: An environmental monitoring agent processes sensor data, satellite imagery analysis, and regulatory reports to track compliance with environmental regulations, identify potential violations, and generate inspection reports. It queries environmental databases and GIS systems via MCP connectors.

What could go wrong: The agent sends facility owner PII (names, addresses, contact information) from inspection records to an external LLM. Or it generates an inspection report without analyst review, creating an official record based solely on AI analysis. Or runaway analysis loops consume excessive LLM budget when processing large sensor datasets.

How AxonFlow can help:

  • PII detection catches email addresses, phone numbers, and other personal identifiers in facility and compliance records before they reach an LLM. See PII Detection.
  • HITL approval gates require environmental analyst review on every inspection finding and compliance determination before it becomes an official record. See HITL Approval Gates.
  • Cost controls can limit governed sensor-processing spend with configurable warn, downgrade, and block actions. See Cost Management.
  • Evidence export (Evaluation and Enterprise) packages AxonFlow governance records for internal review and as supporting material for oversight response. See Evidence Export.
  • Audit logging records governed policy checks and reviewer identity when supplied. Data-source and analysis lineage must come from the environmental data platform. See Audit Logging.
# Policy: cap LLM spend per environmental analysis session
name: environmental-analysis-cost-limit
category: cost-management
action: downgrade
conditions:
  - field: session_metadata.token_count
    operator: gt
    value: 100000
  - field: session_metadata.agent_type
    operator: eq
    value: environmental_monitoring

Regulatory mapping​

The table below maps specific regulatory requirements to shipped AxonFlow capabilities. Government AI systems must satisfy multiple overlapping frameworks simultaneously. AxonFlow provides the technical controls -- your agency's policies, procedures, and administrative safeguards complete the compliance picture.

RequirementRegulation / GuidanceAxonFlow CapabilityDocs
Map: understand AI system context and risksNIST AI RMF (Map function)Policy configuration per agent, per stage, and per tenant; governance profiles (AXONFLOW_PROFILE=strict) define enforcement postureGovernance Profiles
Measure: assess and track identified risksNIST AI RMF (Measure function)Structured decision records with decision_id, verdict, evaluated policies, timestamp; evidence export for risk reportingAudit Logging, Evidence Export
Manage: mitigate risks through controlsNIST AI RMF (Manage function)PII detection (SSN, DOB, email, phone, bank account, passport -- all checksum/format validated), SQL injection scanning, cost controls, HITL approval gatesPII Detection, HITL Approval Gates
Govern: establish accountability structuresNIST AI RMF (Govern function)Multi-layer audit logging, HITL approval queue with reviewer identity, tenant-scoped policy enforcement, evidence exportAudit Logging
High-impact AI governance and monitoringOMB M-25-21Policy enforcement on integrated paths, HITL gates on configured consequential actions, and structured decision evidence that can support agency monitoring and reportingCompliance Overview
AI acquisition and post-award monitoringOMB M-25-22Provider routing, policy enforcement, and evidence records that can support customer-defined interoperability and performance controlsProvider Routing
Continuous monitoring and audit controlsFISMA / NIST SP 800-53 (AU family)Multi-layer audit logging (Agent, Orchestrator, MCP, Workflow, Plan) with decision_id, verdict, evaluated policies, timestamp, caller identityAudit Logging
Access controlFISMA / NIST SP 800-53 (AC family)Tenant-scoped policy enforcement, caller identity on every decision, self-hosted deployment within agency ATO boundaryDeployment Mode Matrix
System integrity and availabilityFISMA / NIST SP 800-53 (SI/CP families)Circuit breaker with configurable failure thresholds, kill switch (Enterprise) for deterministic system shutdownCircuit Breaker
AccessibilitySection 508AxonFlow is an API-first governance layer; Section 508 obligations apply to the agency's user-facing applications that integrate with AxonFlow, not to the governance API itself--
Human oversight for high-risk AIEU AI Act Art. 14 (agencies with EU jurisdiction)require_approval action, HITL approval queue, API-driven approve/rejectHITL Approval Gates

Note on FedRAMP and ATOs: AxonFlow does not hold FedRAMP authorization. A self-hosted deployment can avoid an AxonFlow-operated SaaS data path, but it does not automatically inherit an agency ATO. The agency and its authorizing officials must determine the applicable boundary, controls, assessment evidence, and FedRAMP requirements for the complete system.

Reference architecture​

The diagram below shows AxonFlow deployed inside a government network boundary. The critical property is that no data flows outside the agency's controlled environment. LLM providers can be self-hosted within the same boundary.

Every component in this reference pattern runs inside the agency-controlled boundary. Governed traffic and audit records stay there when model, connector, telemetry, and update paths are configured accordingly. Integrated model calls route through the Orchestrator, while integrated agency data-source calls route through the MCP Gateway. Configured high-risk decisions route to HITL, and AxonFlow records policy outcomes on those governed paths.

Decision Mode for government API gateway patterns​

Government IT systems typically standardize on API gateways (Kong, Apigee, or agency-built gateways) for traffic management, authentication, and rate limiting. Adding AI governance should not require replacing or bypassing these gateways.

Decision Mode integrates with this pattern. AxonFlow runs as a standalone policy decision service behind the agency's existing API gateway. Each service makes one inline POST /api/v1/decide call per AI interaction, receives a verdict (allow, deny, or require_approval), and enforces it locally. AxonFlow is never on the traffic path -- it is consulted, not traversed. This is the PDP/PEP pattern used across the industry by policy engines like OPA, XACML, and Cedar.

Each gateway passes a stage identifier (llm, tool, or agent) and a caller_identity with its gateway_id and tenant_id. AxonFlow evaluates the same policy hierarchy for all three and returns a verdict with a trace_id that correlates decisions across layers using W3C traceparent headers. The result: one audit trail, one policy engine, enforcement at every layer, and zero changes to your existing gateway infrastructure beyond the HTTP call.

For the full API reference, request/response schemas, and curl examples, see Decision Mode. For guidance on when to use Decision Mode versus Gateway Mode, Proxy Mode, or Workflow Control Plane, see Choosing an Integration Mode.

Deployment for government​

Self-hosted deployment is the primary path for government. AxonFlow runs on agency-controlled infrastructure, inside the boundary your security team assesses, without requiring AxonFlow SaaS for runtime policy decisions.

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure. Source-available under BSL 1.1. Full source audit by your security team. Governed traffic and audit records can stay inside your network boundary. Suitable for air-gapped networks when model, connector, telemetry, and update paths are configured accordingly.Federal agencies, defense, intelligence, any agency with data-residency or classification requirements
In-VPCAxonFlow runs inside your AWS GovCloud VPC. Governed traffic can stay within your VPC boundary when paired with in-boundary model and connector paths. Managed by AxonFlow with your infrastructure controls.Agencies on AWS GovCloud that want managed operations without sending governed traffic to a public SaaS control plane
SaaSManaged by AxonFlow in us-east-1.Generally not applicable for federal systems handling CUI or PII. May suit state/local agencies or non-sensitive research workloads

For many federal use cases, Self-Hosted is the recommended deployment mode. It lets the governance layer run inside the authorization boundary your agency already controls, subject to your own ATO process. Your security team can review the source code, build from source, and deploy on infrastructure they fully control -- including air-gapped and classified networks when the surrounding dependencies are configured for that environment.

See Self-Hosted Deployment for installation and configuration details, Deployment Mode Matrix for the full comparison, and Licensing for tier details.

Getting started​

Step 1: Review the source. AxonFlow is source-available under BSL 1.1. Your security team can review the codebase before any deployment decision. See Licensing for license details.

Step 2: Deploy self-hosted. Follow the Self-Hosted Deployment guide to run AxonFlow on your agency's infrastructure. The Getting Started guide provides the fastest path to a running instance for evaluation.

Step 3: Configure PII detection for government data. Set up SSN detection (area/group/serial validated), passport number detection, date of birth detection, and other identifiers relevant to your agency's data types. See PII Detection.

Step 4: Set up HITL approval gates. Configure require_approval policies on consequential decisions: public health recommendations, regulatory findings, eligibility determinations, procurement actions. See HITL Approval Gates.

Step 5: Map your compliance requirements. Use the compliance pages for your regulatory context:

Step 6: Evaluate with real workloads. Request a free Evaluation License for self-hosted validation with HITL approval gates, evidence export, and higher limits. If a sponsored government workflow must reach scoped production against a dated control requirement, use the paid Production Program.

Assessment Path​

Use this page as a domain map, then validate the runtime with the same rollout path:

Last updated on