Utilities should assign each AI agent a unique identity, narrow its permissions to the exact operational task, and enforce access at the infrastructure layer where requests already pass through. Shared service accounts create broad blast radius and weak accountability. The goal is to prevent agents from touching SCADA-adjacent systems, billing tools, or customer workflows outside their approved scope.
Why This Matters for Security Teams
Utilities are adopting AI agents in environments where reliability, safety, and accountability matter more than convenience. Once an agent can open tickets, query operational data, or trigger workflows, identity becomes the control plane that determines whether the system behaves as a bounded assistant or an untracked operator. That is why identity-aware governance has to start with unique identities, explicit approval paths, and policy enforcement that is visible to security and operations teams.
The common failure is not a sophisticated model exploit. It is over-permissioned access, reused credentials, and weak separation between test and production. Guidance in the NIST AI Risk Management Framework is useful here because it ties model behaviour to governance, measurement, and accountability rather than treating AI as a purely application-layer issue. For utilities, that means every agent needs a defined owner, a recorded purpose, and a control boundary that survives incident response and audit review. In practice, many security teams encounter agent misuse only after a workflow has already reached a sensitive system, rather than through intentional governance design.
How It Works in Practice
Identity-aware governance for AI agents and models should be implemented as a set of controls that follow the request path, not as a policy document that sits outside it. The practical objective is to bind each agent to a specific identity, constrain what it can call, and ensure every action is attributable to a named system owner and a managed privilege set. For utilities, that typically means using dedicated service identities, workload-level attestation where available, and policy enforcement at API gateways, service meshes, or privileged access layers.
Current best practice is evolving, but most mature patterns include the same elements:
- Unique identity for each agent, model, or orchestration workflow, with no shared service accounts.
- Least privilege scoped to the operational task, such as read-only telemetry access or narrowly approved ticket creation.
- Policy checks before tool use, especially for actions that touch billing, customer records, or OT-adjacent platforms.
- Logging that preserves agent identity, tool invocation, and decision context for review and incident response.
- Separation of training, testing, and production identities so experimental models cannot inherit live access.
For threat modeling, the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix help teams think beyond authentication to prompt injection, tool abuse, and adversarial manipulation of agent behaviour. That matters because identity alone does not neutralize model risk. A well-authenticated agent can still be coerced into unsafe action if the surrounding controls do not validate intent, context, and output. These controls tend to break down when utilities expose agent toolchains directly to legacy operational systems because older platforms rarely support fine-grained, identity-aware authorization.
Common Variations and Edge Cases
Tighter identity governance often increases operational overhead, requiring utilities to balance resilience and auditability against deployment speed and integration complexity. That tradeoff is especially visible where agents need temporary access during outages, maintenance windows, or vendor-supported remediation. There is no universal standard for this yet, so current guidance suggests using time-bound elevation, explicit approval, and post-action review rather than standing privilege.
Edge cases usually appear in hybrid environments. A customer service agent may only need billing data, but a remediation agent might require access to asset inventories, patch orchestration, and ticketing systems at the same time. Those use cases should not share an identity just because they are part of the same product. Utilities should also treat model endpoints differently from agents: a model may be a shared inference service, while the agent is the identity-bearing actor that requests tool access. The CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 both reinforce the need for governance, detection, and recovery, not just access assignment. The boundary becomes hardest to maintain where utilities rely on shared automation stacks, unmanaged secrets, or opaque vendor integrations that bypass central identity controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity-aware governance needs asset and identity accountability across AI production workflows. |
| NIST AI RMF | AI RMF governs model risk, accountability, and operational controls for production AI. | |
| OWASP Agentic AI Top 10 | Agentic AI threats include tool misuse, prompt injection, and over-privileged workflows. | |
| MITRE ATLAS | ATLAS maps adversarial techniques against AI systems and orchestration layers. | |
| CSA MAESTRO | MAESTRO addresses agentic AI threat modeling and control placement. |
Map each agent and model to an accountable owner, then enforce traceable access and continuous monitoring.
