Skip to main content

AxonFlow for Energy & Utilities

Energy and utilities companies are deploying AI agents that monitor grid operations, schedule maintenance on critical infrastructure, assist energy trading desks, and analyse safety incidents. Every one of those workflows runs in a safety-critical environment where an incorrect AI action can cascade into equipment damage, grid instability, or loss of life. AxonFlow provides the runtime governance layer that enforces policies, gates high-risk decisions for human review, provides an emergency kill switch, and produces the audit trail that NERC auditors and safety inspectors will ask for.

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 deterministic kill switch that halts all AI operations at the governance layer. Not a gradual wind-down, not a "please stop" request to an LLM provider -- an unconditional stop that prevents any new AI actions from executing. AxonFlow's circuit breaker blocks new requests immediately; in-flight LLM inference calls complete but their results are discarded by the governance layer.

  2. Air-gapped and network-isolated deployment. Operational technology (OT) networks in power plants, substations, and pipeline control centres are 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 how energy infrastructure operates. The governance layer must run inside the isolated network, on infrastructure the energy company controls.

  3. Deterministic human oversight on safety-critical decisions. NERC CIP requires human authorisation before changes to bulk electric system configurations. IEC 62443 mandates human approval for safety-instrumented system modifications. These are not suggestions -- they are auditable requirements with enforcement actions for non-compliance. The governance layer must provide a deterministic gate, not a probabilistic recommendation.

Generic LLM proxies and cloud-hosted governance services fail on all three counts. A proxy cannot halt an agent that has already dispatched a tool call. A cloud service cannot enforce policies inside an air-gapped OT network. 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 prevents it:

  • 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 produces a complete decision chain for every copilot interaction: the telemetry context provided, the LLM call, the recommendation generated, the policies evaluated, the human approval decision, and the final dispatch action. 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 prevents it:

  • 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 on every connector call to asset management systems: request-phase (before the query), response-phase (on the returned data), and exfiltration-phase (if data flows to another tool or LLM).
  • Governance profiles enforce a strict posture. Setting AXONFLOW_PROFILE=strict ensures all detections trigger enforcement actions, not just logging. 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 prevents it:

  • 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 on all queries prevents injection attacks that attempt to extract data from risk or trading systems. See SQL Injection Scanning.
  • HITL approval gates on trade strategy generation ensure a human trader reviews and approves every strategy before execution. The approval queue API integrates with existing trading platforms.
  • Cost controls prevent runaway analysis loops from consuming excessive LLM budget. Budget limits are configurable per tenant. 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 prevents it:

  • 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 on root cause analysis and corrective action drafts ensure a safety engineer reviews every output before it enters the incident management system.
  • SQL injection scanning on queries to incident and regulatory databases prevents injection attacks. See SQL Injection Scanning.
  • Evidence export (Evaluation and Enterprise) produces audit packages documenting the full analysis chain -- every LLM call, connector query, policy evaluation, and human approval decision. These packages are suitable for regulatory filing. 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
Human authorisation before BES configuration changesNERC CIP-010require_approval action, HITL approval queue, configurable TTL (Enterprise)HITL 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 network perimeter, no external dependencies for policy enforcementSelf-Hosted Deployment
Security of industrial automation and control systemsIEC 62443MCP connector governance (three-phase policy), SQL injection scanning, governance profilesMCP Policy Enforcement
Human approval for safety-instrumented system changesIEC 62443 (SIL requirements)HITL approval gates on safety-critical steps, deterministic gate (not probabilistic)HITL Approval Gates
AI risk identification and measurementNIST AI RMF (Map, Measure)Policy enforcement at every governed boundary, structured decision records, 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 runs self-hosted within the OT/IT network boundary. No governance data, policy evaluations, or audit records leave the network. LLM providers can be self-hosted models inside the same perimeter for fully air-gapped operation, or external providers accessed through a controlled gateway for less sensitive workloads.

Every interaction between an AI agent and an LLM provider passes through the Orchestrator, where policies are evaluated and PII detection runs. Every interaction between an agent and a data source passes through the MCP Gateway, where three-phase policy evaluation applies. Safety-critical steps route to the HITL queue for human approval. All decisions produce structured audit records that stay within your network. The circuit breaker and kill switch provide emergency halt capability at the governance layer.

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 the strictest infrastructure requirements of any industry. OT networks are air-gapped. Change management processes require months of lead time. Regulatory compliance demands that governance data never leave the network perimeter. AxonFlow supports three deployment modes, with self-hosted being the primary path for energy:

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. No external dependencies for policy enforcement.Power plants, grid control centres, pipeline operations, and any environment with air-gapped or segmented networks
In-VPCAxonFlow runs inside your AWS VPC. No data leaves your network boundary. Managed by AxonFlow with your infrastructure controls.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 feature set. Self-hosted deployment includes the circuit breaker, kill switch, HITL approval gates, full audit logging, and all policy enforcement capabilities -- nothing is cloud-dependent. 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 you need enterprise features (circuit breaker, kill switch, configurable TTL), direct rollout support, or managed In-VPC deployment, apply for the Design Partner Program.

Last updated on