Skip to main content

AxonFlow for Energy & Utilities

Energy and utilities companies are deploying AI agents for grid operations, critical-infrastructure maintenance, energy trading, and safety analysis. Some of these workflows can affect operational resilience, market exposure, or safety. AxonFlow provides runtime policy checks, approval gates, a kill-switch control for governed paths, and decision evidence that can support internal and regulatory review.

This page maps AxonFlow capabilities to concrete energy workflows, regulatory requirements, and deployment patterns. Everything described here is shipped and available today.

The energy AI governance challenge​

Energy is different from other industries in one fundamental way: the consequences of failure are physical. When an AI agent in banking makes a bad decision, the result is a financial loss that can be reversed. When an AI agent controlling grid operations makes a bad decision, the result can be a blackout affecting millions of people, equipment destruction that takes months to repair, or a safety incident that injures workers. The margin for error is zero.

This physical-consequence reality drives three requirements that most AI governance tools are not built for:

  1. Emergency halt capability. Grid controllers and plant managers need a way to stop subsequent governed AI decisions. AxonFlow's circuit breaker and kill switch can reject new requests in scope. They do not cancel model or tool calls already dispatched, so applications must also define downstream cancellation and safe-state behavior.

  2. Air-gapped and network-isolated deployment. Operational technology (OT) networks in power plants, substations, and pipeline control centres are often air-gapped or heavily segmented from IT networks. A cloud-only AI governance solution that requires internet connectivity to enforce policies is architecturally incompatible with those environments. The governance layer must be able to run inside the isolated network, on infrastructure the energy company controls.

  3. Deterministic human oversight on safety-critical decisions. NERC CIP-010 addresses configuration change management for applicable BES Cyber Systems, while IEC 62443 supports industrial control-system security processes. Neither framework creates a universal AxonFlow-specific approval rule. Organizations can translate their change-authorization procedures into deterministic approval policies on the integrated workflow steps.

Generic LLM proxies and cloud-hosted governance services often fail on these requirements. A proxy cannot halt an agent that has already dispatched a tool call. A cloud service cannot enforce policies inside an isolated OT network if policy checks depend on outbound connectivity. A logging layer that captures requests after the fact cannot prevent a safety-critical action from executing without human review.

AxonFlow is purpose-built for this environment. It runs self-hosted inside your network perimeter, enforces policies at every governed boundary before actions execute, provides a circuit breaker and kill switch for emergency halt, and gates safety-critical decisions through human-in-the-loop approval queues.

Use cases​

1. Grid monitoring copilot​

What the agent does: An AI copilot assists grid controllers by analysing real-time SCADA telemetry, forecasting load patterns, recommending switching operations, and drafting dispatch instructions.

What could go wrong: The copilot recommends a switching operation that would overload a transmission line. Or it generates dispatch instructions during an abnormal grid condition without human review. Or the LLM provider experiences a latency spike during a grid emergency, and the copilot stalls instead of failing safe.

How AxonFlow can help:

  • HITL approval gates pause any switching recommendation before it reaches the dispatch system. The require_approval policy action routes the recommendation to a human approval queue where a grid controller reviews the recommendation against current grid state, then approves or rejects via the API. Unanswered requests auto-expire after a configurable TTL (Enterprise).
  • Circuit breaker and kill switch (Enterprise) provide immediate halt of all AI operations when grid conditions are abnormal. The circuit breaker trips automatically on configurable failure thresholds. The kill switch provides manual override for control room staff. See Choosing a Mode.
  • Audit logging records governed policy checks and approval identity when supplied. Telemetry lineage, model output, and final dispatch state must also be retained by the grid and operations systems. See Audit Logging.

2. Predictive maintenance scheduling agent​

What the agent does: An AI agent analyses sensor data from turbines, transformers, and other equipment to predict failures, prioritise maintenance work orders, and schedule outages. It queries asset management databases via MCP connectors, cross-references manufacturer specifications, and generates maintenance plans.

What could go wrong: The agent schedules overlapping outages that reduce grid redundancy below safe margins. Or it includes equipment serial numbers and location data in LLM prompts, exposing critical infrastructure details. Or the maintenance plan changes a safety-instrumented system without the mandatory human review required by IEC 62443.

How AxonFlow can help:

  • HITL approval gates on maintenance plans that affect safety-instrumented systems or reduce redundancy below configurable thresholds. No maintenance outage proceeds without explicit human sign-off.
  • PII detection catches SSNs (format-validated), email addresses, phone numbers, and dates of birth in personnel data before they reach external LLMs. The action is configurable per path: block, redact, warn, or log. See PII Detection.
  • MCP connector governance applies three-phase policy evaluation to asset-management calls routed through the governed MCP path.
  • Governance profiles provide stricter defaults, while path and action configuration determine final enforcement behavior. See Compliance Overview.
# Policy: require human approval on maintenance affecting safety systems
name: safety-system-maintenance-approval
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.system_type
    operator: in
    value: ["safety_instrumented", "protection_relay", "emergency_shutdown"]
  - field: step_metadata.action_type
    operator: eq
    value: schedule_outage

3. Energy trading assistant​

What the agent does: An energy trading assistant helps traders analyse market conditions, model price scenarios, draft trade strategies, and monitor position limits. It queries market data feeds, internal risk systems, and regulatory reporting databases via MCP connectors.

What could go wrong: The assistant includes trader identities or counterparty details in LLM prompts. Or it generates a trade strategy without human review, and the strategy violates position limits or market manipulation rules. Or a prompt injection attack through market data extracts proprietary trading algorithms.

How AxonFlow can help:

  • PII detection catches email addresses, phone numbers, credit card numbers (Luhn-validated), and bank account numbers (ABA routing checksum) before they reach external LLMs. See PII Detection.
  • SQL injection scanning evaluates configured input or MCP response paths and can block, warn, or log detected patterns. It does not inspect every database query automatically. See SQL Injection Scanning.
  • HITL approval gates can pause configured trade-strategy steps for human review before the integrating platform executes them.
  • Cost controls can limit spend on governed analysis paths when configured thresholds are reached. See Cost Management.
# Decision Mode: check a trading query 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": "trading-assistant-gw",
      "tenant_id": "energy-trading-us"
    },
    "target": {
      "type": "llm",
      "model": "gpt-4o",
      "provider": "openai"
    },
    "query": "Model price scenario for trader [email protected] on account 4532-0151-1283-0366"
  }' | jq .
{
  "verdict": "deny",
  "decision_id": "b7e2f1a3-4c8d-4b2e-a9f1-3e6d7c8b9a0e",
  "trace_id": "2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e",
  "stage": "llm",
  "reasons": ["Email address detected in prompt", "Credit card number detected (Luhn-validated)"],
  "obligations": [],
  "evaluated_policies": ["sys_pii_email", "sys_pii_credit_card"],
  "expires_at": "2026-05-23T10:35:00Z"
}

4. Safety incident analysis agent​

What the agent does: After a safety incident (equipment failure, near-miss, environmental release), an AI agent analyses incident reports, cross-references similar historical events, identifies root causes, and drafts corrective action plans. It queries incident databases, equipment logs, and regulatory filing systems via MCP connectors.

What could go wrong: The agent includes worker names, injury details, or facility location data in LLM prompts. Or it generates a root cause analysis without human review, and the analysis contains inaccurate conclusions that become part of the regulatory filing. Or it queries a regulatory database with a malformed query that triggers unintended data exposure.

How AxonFlow can help:

  • PII detection catches SSNs (format-validated), email addresses, phone numbers, and dates of birth before they reach external LLMs. Configured per path via PII_ACTION, GATEWAY_PII_ACTION, and MCP_PII_ACTION.
  • HITL approval gates can pause configured root-cause and corrective-action drafts for safety-engineer review before the integration submits them.
  • SQL injection scanning can detect configured SQL injection patterns on supported input or MCP response paths. See SQL Injection Scanning.
  • Evidence export (Evaluation and Enterprise) packages AxonFlow governance records for internal review and as supporting material for regulatory response. Source data, analytical results, and incident-system actions require evidence from their authoritative systems. See Evidence Export.

Regulatory mapping​

The table below maps specific regulatory requirements to shipped AxonFlow capabilities. Each requirement links to the relevant documentation for the full analysis.

RequirementRegulationAxonFlow CapabilityDocs
Emergency halt of AI operations affecting bulk electric systemNERC CIP-005/CIP-007Circuit breaker with configurable failure thresholds, kill switch for immediate manual halt (Enterprise)Choosing a Mode
Configuration change authorization supportNERC CIP-010, where applicablerequire_approval action and approval records for customer-defined BES Cyber System change workflowsHITL Approval Gates
Audit trail for electronic access and configuration changesNERC CIP-007/CIP-008Multi-layer audit logging with decision_id, verdict, evaluated policies, timestamp, identityAudit Logging
Network segmentation and access control for OT systemsNERC CIP-005Self-hosted deployment inside the network perimeter; policy enforcement can run without an external SaaS dependencySelf-Hosted Deployment
Security of industrial automation and control systemsIEC 62443MCP connector governance (three-phase policy), SQL injection scanning, governance profilesMCP Policy Enforcement
Customer-defined approval for industrial control changesIEC 62443-aligned security processHITL approval gates on configured safety-critical workflow stepsHITL Approval Gates
AI risk identification and measurement supportNIST AI RMF (Map, Measure)Policy enforcement on integrated paths, structured decision records, and evidence exportCompliance Overview
AI system monitoring and incident responseNIST AI RMF (Manage)Circuit breaker, kill switch, audit logging, cost controls, governance profilesSecurity Overview
Protection of sensitive infrastructure dataCross-regulationPII detection with configurable action (block / redact / warn / log) per path (LLM, gateway, MCP)PII Detection
Explainability and transparency of AI decisionsNIST AI RMF (Govern)Structured decision records with evaluated policies, verdict rationale, W3C traceparent correlationDecision Mode

Reference architecture​

The diagram below shows AxonFlow deployed inside an energy company's network perimeter. The critical architectural point: AxonFlow can run self-hosted within the OT/IT network boundary so governed traffic, policy evaluations, and audit records stay inside the environment you control. LLM providers can be self-hosted models inside the same perimeter for air-gapped operation, or external providers accessed through a controlled gateway for less sensitive workloads.

In this reference pattern, model calls route through the Orchestrator and data-source calls route through the MCP Gateway. Configured safety-critical steps route to HITL. AxonFlow records policy decisions on those integrated paths. Records remain within the intended network only when storage, model, connector, telemetry, and update paths are configured for that boundary.

Decision Mode for energy infrastructure teams​

Large energy companies run complex technology stacks with multiple gateway layers: an agent gateway for AI workloads, an MCP or tool gateway for SCADA and historian access, and an LLM gateway for model routing. Asking these teams to rearchitect their traffic flow through a new proxy is not realistic, especially in environments with strict change-management processes.

Decision Mode solves this. AxonFlow runs as a standalone policy decision service. Each gateway makes one inline POST /api/v1/decide call per request, 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 (Policy Decision Point / Policy Enforcement Point) 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. One audit trail, one policy brain, enforcement at every layer, and zero changes to existing gateway code 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 options for energy​

Energy companies have some of the strictest infrastructure requirements of any industry. OT networks may be air-gapped or heavily segmented. Change management processes can require months of lead time. Regulatory compliance often demands that governance data remain inside a defined network perimeter. AxonFlow supports three deployment modes, with self-hosted being the primary path for sensitive energy workloads:

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure inside your network perimeter. Source-available under BSL 1.1. Full control over data, network, and upgrades. Policy enforcement does not require AxonFlow SaaS.Power plants, grid control centres, pipeline operations, and environments with air-gapped or segmented networks
In-VPCAxonFlow runs inside your AWS VPC and uses your infrastructure controls. Governed traffic can stay within your VPC boundary when paired with in-boundary model and connector paths.Energy companies with cloud-based IT workloads and strict data-residency requirements
SaaSManaged by AxonFlow. Fastest path to production.Energy trading desks, corporate IT workloads, and non-OT use cases without air-gap requirements

All three modes support the same core governance feature set. Self-hosted deployment includes the circuit breaker, kill switch, HITL approval gates, audit logging, and policy enforcement capabilities without relying on AxonFlow SaaS for runtime decisions. External model providers, telemetry, and operational integrations remain deployment choices. See Deployment Mode Matrix for the full comparison and Licensing for tier details.

Getting started​

Step 1: Run locally. Follow the Getting Started guide to run AxonFlow on your machine in under 5 minutes. This validates the core governance loop: policy enforcement, PII detection, and audit logging.

Step 2: Configure strict governance. Set AXONFLOW_PROFILE=strict and configure PII_ACTION=block and SQLI_ACTION=block to enforce the zero-tolerance posture that energy operations require.

Step 3: Test HITL approval gates. Configure a require_approval policy on a safety-critical step and verify the approval flow end-to-end. See HITL Approval Gates for the API reference.

Step 4: Deploy self-hosted. Follow the Self-Hosted Deployment guide to run AxonFlow inside your network perimeter. This is the recommended path for any workload that touches OT systems or safety-critical infrastructure.

Step 5: Map your regulatory requirements. Use the regulatory mapping table above to identify which AxonFlow capabilities address your specific compliance obligations. For the full compliance documentation, see Compliance Overview.

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 energy 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