Agentic AI Governance for Substation Protection Workflows

The phrase “agentic AI for substations” can describe anything from a read-only report assistant to a system that is allowed to call tools on an OT network. That range is too broad for procurement or a security review. The first governance decision is to state what the product can do, what it cannot do, where it runs, and who is accountable for the output.

A defensible default architecture

For relay testing and protection evidence, the safest default is:

• operational and deterministic engineering stays inside the customer’s boundary;
• the assistant receives only the approved context for a requested operation;
• the assistant has no ability to issue trips, write relay settings, publish GOOSE, change SCL, or operate equipment;
• tools are allow-listed and scoped to the selected asset and task;
• every draft is source-linked and marked as draft until a qualified engineer approves it;
• model, context, tool calls, errors, abstentions, reviewer changes, and final disposition are recorded.

This is not a blanket security certification. NIST SP 800-82 emphasizes that OT systems monitor or directly affect the physical environment and therefore require architecture-specific controls. A local desktop process may still have risky file, network, or credential permissions; a hosted service may still be acceptable for a narrowly approved context. The diagram and the actual implementation matter more than the slogan.

Govern the use case before the model

The NIST AI Risk Management Framework organizes work around Govern, Map, Measure, and Manage. Applied to relay testing:

Govern

Name the business owner, engineering owner, security owner, and final approval role. Define the intended use, prohibited actions, data retention, model/provider, change control, incident path, and review frequency.

Map

Describe the asset, test stage, procedure, stakeholders, source data, failure modes, operational impact, and environment. A plan-review assistant and a live control agent are different use cases and must not share an informal risk category.

Measure

Test accuracy, abstention, source attribution, false flags, missed gaps, robustness to stale or malformed files, prompt injection in manuals, and reviewer workload. Compare the system with a documented baseline.

Manage

Set thresholds for deployment, human escalation, rollback, update approval, evidence retention, and decommissioning. Track what changed when a model, parser, relay firmware, or procedure changed.

Human approval is a control, not a button

“Human in the loop” is too vague. An approval gate should identify:

• what the AI saw;
• what it proposed;
• what evidence supports the proposal;
• what it did not know or could not validate;
• what action, if any, is requested;
• who reviewed it and under which role;
• what was changed, rejected, or escalated.

If a reviewer cannot inspect the source record, the gate is ceremonial. If the workflow pressures the reviewer to approve a fluent summary rather than open the raw evidence, it creates automation bias. Research on explainable AI in energy systems warns that explanations can be incomplete or induce overreliance; source links and explicit limitations are more useful than a confident paragraph labeled “explanation.”

Protect against data and tool failure

The AI layer should be tested against:

• wrong relay model or firmware;
• missing settings group;
• stale or conflicting SCL files;
• malformed COMTRADE metadata;
• unit and phase-order errors;
• prompt injection embedded in a manual or report;
• an unavailable provider or partial network outage;
• duplicate, truncated, or low-quality scans;
• a tool returning a syntactically valid but physically nonsensical result.

Abstention is a required behavior. A system that always produces an answer turns incomplete evidence into false certainty. The correct output may be: “I cannot establish the setting group from the available records; obtain the issued export before proceeding.”

IEC 61850 does not replace security engineering

IEC 61850 describes data models and communications for power-utility automation. Network engineering guidance such as IEC TR 61850-90-4 is relevant to GOOSE, sampled values, redundancy, and topology. Security is a separate concern; a tool that reads SCL or observes GOOSE traffic is not automatically compliant or secure.

AI governance should therefore record what the agent can access: files, APIs, network interfaces, packet captures, credentials, and outbound endpoints. If a product says it is local-first, document the actual egress and the specific context sent to the provider. If it uses a customer API key, document who stores it, how it is protected, and how it is rotated.

What Harvard and MIT research contributes

Harvard’s PowerAgent project and related power-system foundation-model work illustrate the research direction toward models, context protocols, workflows, and domain skills. MIT Energy Initiative work discusses AI’s potential for grid operation, planning, equipment servicing, and energy-system optimization while emphasizing physical constraints and deployment realities. These sources support a research thesis, not a claim that an individual relay-testing product has field validation.

The product claim must stay closer to the implementation: ProtectionAI is a bounded assistant for a protection-testing workbench, with simulator-first and human-reviewed boundaries. It is not an autonomous substation controller, a regulatory certificate, or proof that an operational scheme is safe.

A governance checklist for a utility pilot

Before connecting real evidence, obtain:

1. architecture and data-flow diagram;
2. inventory of models, parsers, tools, and versions;
3. list of allowed and prohibited actions;
4. source, retention, and deletion policy;
5. test set of representative and adversarial records;
6. measurable acceptance criteria;
7. reviewer role and approval workflow;
8. incident, rollback, and provider-outage plan;
9. security and procurement review;
10. post-deployment monitoring and change-control plan.

The first pilot should be read-only plan review, evidence completeness, or simulator training. It should produce useful evidence even when the AI provider is unavailable.

References

• Harvard John A. Paulson School of Engineering and Applied Sciences. (n.d.). PowerAgent. Retrieved August 1, 2026, from https://poweragent.seas.harvard.edu/
• International Electrotechnical Commission. (2020). Communication networks and systems for power utility automation—Part 90-4: Network engineering guidelines (IEC TR 61850-90-4:2020). https://webstore.iec.ch/en/publication/64801
• Machlev, R., Heistrene, L., Perl, M., Levy, K. Y., Belikov, J., Mannor, S., & Levron, Y. (2022). Explainable artificial intelligence techniques for energy and power systems. Energy and AI, 9, 100169. https://doi.org/10.1016/j.egyai.2022.100169
• National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1
• Stouffer, K., et al. (2023). Guide to operational technology (OT) security (NIST SP 800-82 Rev. 3). https://doi.org/10.6028/NIST.SP.800-82r3
• Massachusetts Institute of Technology Energy Initiative. (2025, October 31). How artificial intelligence can help achieve a clean-energy future. https://energy.mit.edu/news/how-artificial-intelligence-can-help-achieve-a-clean-energy-future/