A water utility runs Foundry agents for both field operators and a public billing chatbot. What setup best separates those audiences?
Select an answer to reveal the explanation.
Short Explanation
Mixing the public billing bot with the operator agent is like putting the break room and the lobby on the same badge reader. Give operators their own Foundry deployment with internal tools, and keep the resident billing bot on a tightly scoped public deployment. Separate identities and exposure so a curious resident never reaches field controls.
Full Explanation
Separating Foundry agent deployments for field operators and the public billing chatbot enforces distinct tools, identities, and network exposure so each audience only receives the capabilities appropriate to its trust boundary. The setup works because internal operator agents can attach privileged utility tools and private network paths while the public billing bot uses a constrained toolset, resident-facing identity, and internet-exposed entry points without inheriting SCADA-adjacent or operator credentials. For a water utility, that separation is the primary control that prevents a public conversation surface from becoming an accidental bridge into operational systems. Creating separate agent deployments for internal operators and the public billing bot with distinct prompts, identities, and network exposure still fails because without distinct tools both deployments share the same utility tool catalog; distinct prompts do not enforce a trust boundary, so the public surface can invoke operator-only APIs. Creating separate agent deployments for internal operators and the public billing bot with distinct tools, prompts, and network exposure still fails because without distinct identities both deployments share credentials and role assignments; distinct prompts do not isolate privilege, so the public billing bot can act with operator identity despite a separate tool list. Creating separate agent deployments for internal operators and the public billing bot with distinct tools, identities, and content filtering still fails because content filtering does not enforce network separation; without distinct network exposure the internal agent lacks a private operator path, and shared ingress lets internet traffic reach operational paths despite distinct tools and identities. Exam caveat: separate deployments still fail if they share overly broad managed identities, a common unrestricted tool catalog, or identical outbound allowlists. Operational check: inventory tools and identities per deployment, verify the public billing bot cannot call operator-only APIs, confirm network paths differ (public ingress vs private operator network), and run a negative test proving privileged tools return authorization failures from the public agent.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.