AI Agent Governance for Utility Wildfire Mitigation Programs

Why wildfire mitigation is a distinct governance problem

AI agents used in utility wildfire mitigation programs differ from typical enterprise AI deployments in one key respect: the systems they touch and the decisions they influence carry direct physical safety consequences. An agent scoring vegetation risk along a transmission corridor, supporting a Public Safety Power Shutoff (PSPS) decision, or flagging anomalies from grid sensors is not simply summarizing text or answering questions. It is interacting with operational technology (OT) data, geographic information system (GIS) platforms, satellite or aerial imagery feeds, and often third-party wildfire risk models, and its outputs can inform or trigger operational actions.

This combination of OT/IT convergence, physical risk, and regulatory oversight means governance cannot be treated as a documentation exercise completed before deployment. It has to include controls that operate while the agent is running: what it is allowed to access, what actions it can take autonomously versus what requires human approval, and what gets recorded when it does either.

What agent identity means in this context

A foundational governance requirement is giving each AI agent a distinct, verifiable identity, separate from the service accounts, API keys, or human credentials it may operate through. Without this, an agent pulling vegetation encroachment data from a GIS system or querying a grid sensor network is effectively indistinguishable from any other automated process using the same credentials.

Distinct agent identity matters for two practical reasons. First, it allows permissions to be assigned to the agent specifically, rather than inherited broadly from a shared account. Second, it makes it possible to attribute a specific action, data access event, or recommendation to a specific agent instance during an audit or incident review. In a wildfire mitigation context, where a delayed or incorrect risk score could factor into a liability review, this attribution is not optional.

Least-privilege access to OT, GIS, and third-party data

Wildfire mitigation agents typically need to interact with several categories of sensitive systems: OT telemetry from grid sensors and reclosers, GIS layers containing asset locations and vegetation data, satellite or drone imagery feeds, and third-party wildfire risk or weather modeling tools. Each of these systems has different sensitivity levels and different consequences if accessed or modified incorrectly.

Least-privilege design means an agent performing vegetation risk scoring should not have write access to grid control systems, and an agent supporting PSPS decision analysis should not have unrestricted query access to unrelated customer or billing data. Permissions should be scoped to the specific data sources, read/write actions, and tool calls the agent's function actually requires, and reviewed as that function changes. This is a departure from broader IT access models where a single elevated credential is often reused across multiple tools.

Runtime policy enforcement for tool calls

Defining permissions at deployment time is necessary but not sufficient. Agents that connect to external tools and data sources, including those using protocols like the Model Context Protocol (MCP) to interface with GIS platforms or third-party models, need enforcement that checks each tool call against policy at the moment it happens.

Runtime policy enforcement addresses scenarios that static permissioning cannot: an agent attempting to call a tool outside its intended scope, a prompt injection or manipulated input attempting to redirect an agent toward an unauthorized data source, or a legitimate agent behaving unexpectedly due to a model or configuration change. In a wildfire mitigation workflow, this could mean blocking an agent from querying a control system it was never authorized to touch, or requiring explicit approval before an agent-recommended action, such as flagging a circuit for inspection, is executed.

Audit logging and accountability requirements

Utility wildfire mitigation programs operate under regulatory scrutiny and potential liability exposure tied to missed or delayed mitigation actions. When an AI agent contributes to a risk score, a PSPS recommendation, or an outage response decision, there needs to be a clear, reviewable record of what data the agent accessed, what it recommended, what action (if any) followed, and whether a human reviewed or approved that action.

This audit trail serves two purposes. Internally, it supports incident review and root-cause analysis when an outcome is questioned. Externally, it supports the utility's ability to demonstrate to regulators that AI-assisted decisions were made with appropriate oversight, rather than through an opaque process. Logging needs to capture agent identity, the specific tool calls and data accessed, and the decision or output produced, not just a summary of the final recommendation.