AI Agent Governance for Municipal Water Quality Monitoring

Defining AI Agent Governance for Water Quality Monitoring

Agent Identity and Least-Privilege Access Controls

The first governance requirement is that an AI agent operate under a distinct, attributable machine identity rather than a shared or generic service account. This aligns with the continuous verification and least-privilege authorization principles defined in NIST SP 800-207 Zero Trust Architecture guidance, which requires every access request to be evaluated on its own merits regardless of network location. A shared credential makes it impossible to trace a specific action back to a specific agent instance, which undermines the accountability chain required for Safe Drinking Water Act reporting.

Least-privilege scoping should follow the access control principles in NIST SP 800-53 Rev. 5, which apply to automated and non-human accounts as well as human users. In practice, an agent's default access should be limited to read-only sensor data unless a separate, explicitly governed permission grants control-action capability, and that permission should require a distinct approval path rather than being bundled into the same credential used for monitoring tasks. America's Water Infrastructure Act risk and resilience assessments, required for community water systems serving more than 3,300 people, should be updated to treat AI agent access as a distinct threat vector alongside existing cybersecurity risks.

Operational Risks When Agents Have Sensor or SCADA Access

Baseline Questions to Evaluate an Agent Deployment

Before an AI agent is granted access to sensor data or control-system functions, the following questions establish whether the deployment meets a defensible governance baseline.

• Does the agent operate under a unique, non-human identity with scoped credentials rather than a shared service account?
• Is there an enforced allow-list of specific SCADA or reporting functions the agent may invoke, validated at runtime?
• Can every agent action be reconstructed from audit logs showing identity, input data, decision logic, and outcome?
• Is a human approval step required before any agent-triggered regulatory alert or control-system action executes?
• Does the governance framework map to existing AWIA risk assessments and SDWA reporting obligations?
• Are network paths between the agent and OT/SCADA systems segmented consistent with CISA guidance?

MCP Adoption and Tool-Call Governance Gaps

Runtime Policy Enforcement Between Agents and SCADA Systems

Identity verification and least-privilege scoping establish what an agent is allowed to do in principle. A runtime policy enforcement point confirms, at the moment of each action, whether a specific tool call is permitted given the agent's current authorization state and the nature of the requested action. This enforcement point should sit logically between the agent and any OT or SCADA interface, validating each request rather than relying solely on upfront authentication.