A water-utility assessment charter forbids scanning OT controllers. How should AI workflows that contextualize vulnerabilities be constrained?
Select an answer to reveal the explanation.
Short Explanation
If the charter says don’t poke the OT controllers, the AI doesn’t get a hall pass either. Stick contextualization to approved IT jump-box scan data. Water safety beats model confidence every time.
Full Explanation
Civic OT boundaries must constrain both scanners and AI workflows that interpret vulnerability data. When a water-utility assessment charter forbids scanning OT controllers, AI contextualization should be limited to approved IT jump-box scan data and must exclude OT controller targeting—model confidence does not override ROE or safety. Keeping AI subordinate to the charter protects water operations while still allowing Domain 7-style assistance on authorized IT jump-box findings.
Allowing AI agents to recommend active probes against PLC firmware whenever confidence is high fails because confidence is not authorization and PLC probing can be unsafe. Ignoring the charter if the AI claims OT scanning is low risk fails governance; charters outrank model claims. Uploading full OT network diagrams to public chatbots fails OPSEC and can expose critical water infrastructure detail.
Exam caveat: AI-plus-scan integration remains explicitly subordinate to municipal safety and authorization. Choose the option that preserves OT exclusion.
Operational check for water-utility assessors: configure agent workflows to ingest only approved IT jump-box results, deny tools/actions that target PLCs or OT networks, prohibit exporting OT diagrams to public models, escalate any agent suggestion that violates the charter, and document human approval before remediation on in-scope IT systems only.