Why AI Agents Introduce a Different Risk Category Than Existing OT Controls
Municipal water districts are introducing AI agents for tasks such as predictive maintenance analysis, water quality monitoring, billing automation, and customer service. These agents differ from the automation already present in most OT environments because they interpret data, generate outputs, and in some cases invoke functions or API calls dynamically rather than following a fixed, pre-programmed sequence. Existing OT security models, built around network segmentation, fixed control logic, and human operator oversight, were not designed to account for a system that decides at runtime which action to take or which data source to query. This does not make AI agents inherently unsafe, but it does mean governance has to operate at a different layer: not just which network segment an agent can reach, but which specific actions it is permitted to take once it is there. For water districts, where treatment and distribution processes have direct public health and safety implications, this distinction matters more than it does in many other sectors.
Agent Identity and Permission Scope Are Foundational Decisions
Before an AI agent is deployed near any water utility system, it needs its own identity, separate from the human operator it may act on behalf of, the scheduled process that triggers it, or the service account it might otherwise be bundled with. Shared or generic credentials make it difficult to attribute an action to a specific agent during an incident review, and they make revocation harder when a use case is decommissioned or a vulnerability is discovered. Alongside identity, permission scope should be defined per use case rather than granted broadly. A predictive maintenance agent and a billing automation agent have no operational reason to share the same access footprint, and treating them as interchangeable increases the blast radius if either is compromised or misconfigured. This is a design decision that has to be made deliberately, since default configurations in many agent platforms tend toward broader access rather than narrower access.
Sequencing Deployment for Resource-Constrained Security Teams
Tradeoffs and Evaluation Criteria
There is a genuine tradeoff between deployment speed and governance rigor. Granting an agent broad access at the outset reduces integration effort but increases the scope of what needs to be reviewed if the agent behaves unexpectedly or is compromised. Narrow, use-case-specific permissioning takes more upfront design work but keeps that review scope contained. Water districts evaluating a governance approach should confirm whether it can enforce least privilege separately for OT-adjacent and IT-only agents, how agent identities are created and revoked, what visibility exists into individual tool calls including denied actions, and whether enforcement can be deployed without requiring direct changes to SCADA network architecture. These questions apply regardless of which specific platform or internal process a district ultimately selects, and they should be answered before any agent is given access near systems that affect treatment or distribution.