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.

Executive Order 14110 and OMB M-24-10 set the timeline​

Executive Order 14110 (October 2023) directed federal agencies to establish AI governance structures, and OMB Memorandum M-24-10 (March 2024) set specific requirements: agencies must implement safeguards for AI that impacts rights and safety, designate Chief AI Officers, conduct AI impact assessments, and report AI use cases to OMB. These are not aspirational guidelines -- they come with reporting deadlines and audit expectations. AI systems that lack deterministic governance controls, human oversight mechanisms, and structured audit trails cannot satisfy the M-24-10 compliance inventory. AxonFlow provides the runtime enforcement layer that produces the evidence these requirements demand.

FISMA applies to every federal information system​

Any AI system operating within a federal information system boundary falls under FISMA requirements. The continuous monitoring, access control, and audit requirements in NIST SP 800-53 apply to AI governance tools just as they apply to any other system component. This creates a practical problem: SaaS-based governance tools require their own Authority to Operate (ATO), which typically takes 12-18 months to obtain through the FedRAMP authorization process. Most agencies cannot wait that long to deploy AI governance.

AxonFlow sidesteps this entirely. AxonFlow is self-hosted -- it runs inside your agency's existing ATO boundary on infrastructure you already control. No data leaves the government network. No additional ATO is required because the governance layer inherits the authorization of the environment it runs in. This is not a workaround; it is the correct deployment model for government AI governance. Source-available under BSL 1.1, AxonFlow can be inspected, audited, and deployed by your agency's security team without dependency on a vendor's authorization timeline.

Air-gapped and classified environments​

Defense and intelligence agencies operate networks that 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 runs entirely within the local network. The BSL 1.1 source-available license allows your security team to review the codebase, build from source, and deploy on air-gapped infrastructure. All governance capabilities -- PII detection, policy enforcement, HITL approval gates, audit logging, and circuit breaker -- function without any external network connectivity.

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 prevents it:

  • 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 on every connector call: request-phase (before the query to the surveillance database), response-phase (on the returned case data), and exfiltration-phase (if case data flows to another tool or LLM). This prevents individual-level health data from leaking across connector boundaries.
  • Audit logging produces a complete decision chain across every step, establishing that governance was active 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 prevents it:

  • 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 the full decision chain: document sources queried, policies evaluated, AI analysis steps, and human reviewer sign-off. 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 prevents it:

  • PII detection catches SSNs (area/group/serial validated), dates of birth, bank account numbers (ABA checksum), email addresses, phone numbers, and passport numbers in every governed interaction. The action is configurable: block, redact, warn, or log. See PII Detection.
  • MCP connector governance applies three-phase policy evaluation on every call to case management and benefits systems. Exfiltration-phase scanning prevents citizen data returned by one system from flowing to an unauthorized tool.
  • HITL approval gates on eligibility determinations and case disposition decisions ensure a qualified caseworker reviews before the determination is communicated to the citizen. See HITL Approval Gates.
  • GDPR erasure via POST /api/v1/gdpr/delete supports citizen data deletion requests. 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 prevents it:

  • Circuit breaker and kill switch (Enterprise) provide deterministic fallback when LLM providers are unavailable. The logistics pipeline fails loud rather than failing silent, ensuring supply chain monitoring does not silently stop. See Circuit Breaker.
  • HITL approval gates require authorization on procurement recommendations and logistics decisions above configurable thresholds. The require_approval action ensures no significant logistics decision executes without human sign-off. See HITL Approval Gates.
  • Self-hosted deployment ensures the governance layer runs inside the defense network. No logistics data, procurement data, or supply chain analysis leaves the controlled environment. All LLM calls can be routed to self-hosted models within the same network boundary.
  • Audit logging produces structured records of every logistics decision: inputs, policies evaluated, verdict, approver identity. 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 prevents it:

  • 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 enforce budget limits per tenant with configurable actions: warn when approaching the limit, downgrade to a cheaper model, or block when the budget is exhausted. This prevents sensor-data processing loops from consuming unbounded LLM spend. See Cost Management.
  • Evidence export (Evaluation and Enterprise) produces audit packages suitable for regulatory proceedings and IG review. See Evidence Export.
  • Audit logging records the full decision chain: data sources queried, analysis steps performed, policies evaluated, and human reviewer sign-off. 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
AI governance structures and safeguardsEO 14110, OMB M-24-10Policy enforcement at every governed boundary, HITL gates on rights-impacting decisions, structured audit trail for compliance inventory reportingCompliance Overview
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: AxonFlow does not hold FedRAMP authorization. This is by design. As a self-hosted, source-available governance layer, AxonFlow runs inside your agency's existing ATO boundary on infrastructure you control. No citizen data, decision records, or policy configurations leave your network. The governance layer inherits your agency's authorization -- no separate FedRAMP ATO is required.

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 runs inside the agency's ATO boundary. LLM providers are self-hosted (Llama, Mistral, or GovCloud services). No data leaves the government network at any point in the governance pipeline. Every interaction between an agent and an LLM passes through the Orchestrator for policy evaluation and PII detection. Every interaction with an agency data source passes through the MCP Gateway for three-phase policy evaluation. High-risk decisions route to the HITL queue. All decisions produce structured audit records.

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 your agency's infrastructure, inside your ATO boundary, with no external dependencies.

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure. Source-available under BSL 1.1. Full source audit by your security team. No data leaves your network. Works on air-gapped networks.Federal agencies, defense, intelligence, any agency with data-residency or classification requirements
In-VPCAxonFlow runs inside your AWS GovCloud VPC. No data leaves your VPC boundary. Managed by AxonFlow with your infrastructure controls.Agencies on AWS GovCloud that want managed operations without data leaving their VPC
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 most federal use cases, Self-Hosted is the recommended deployment mode. It requires no additional ATO because the governance layer runs inside your existing authorization boundary. Your security team can review the source code, build from source, and deploy on infrastructure they fully control -- including air-gapped and classified networks.

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 you need enterprise features, direct rollout support, or deployment assistance for classified environments, apply for the Design Partner Program.

Last updated on