Deploying Azure AI Foundry Agents with Sovereign Guardrails for WA Public Sector

Western Australian agencies are moving quickly to evaluate generative AI, and agent based services built on Azure AI Foundry offer a structured way to automate research, drafting, and case handling tasks. Before any such service reaches production, however, decision makers must be confident that the deployment satisfies sovereignty, accountability, and security obligations that apply to public sector information. An agent that can reason over departmental records and act on a user's behalf introduces new risk surfaces, and those surfaces need deliberate controls rather than default settings.

This article sets out a practical configuration approach centred on three pillars: content filtering to constrain model behaviour, network isolation to control how the service is reached, and Australian data boundary controls to keep information within trusted regions. The aim is to describe an auditable deployment pattern that a governance body can review, rather than a rushed pilot that later fails an assessment. Each pillar reinforces the others, and treating them together produces a posture that stands up to scrutiny from internal audit and external assessors alike.

Establishing the sovereignty context

Sovereignty for WA Government workloads begins with where data is stored, processed, and administered, and Azure provides Australian regions including Australia East and Australia Central that support data residency for the underlying storage of many services. When provisioning an Azure AI Foundry project and its associated resources, teams should confirm that the resource region, any linked Azure OpenAI deployment, and dependent storage and search resources are all created in an approved Australian region. This alignment matters because an agent typically orchestrates several services, and a single misconfigured dependency can move data outside the intended boundary.

Accountability is the second dimension of sovereignty, and it depends on being able to demonstrate who configured the environment, what the agent is permitted to do, and how its decisions can be reviewed. Agencies should map the deployment against the Australian Government Information Security Manual and their own data classification, documenting the controls applied to each resource. Recording these decisions before rollout gives an assurance team the evidence it needs and reduces the likelihood of remediation work after go live.

Content filtering and responsible AI guardrails

Azure OpenAI and Azure AI Foundry include configurable content filters that evaluate both prompts and responses across categories such as hate, sexual, violence, and self harm, with adjustable severity thresholds. For public sector agents, teams should review the default filter configuration and, where the risk profile warrants it, apply stricter thresholds or custom blocklists that reflect the agency context. Content filtering should be paired with grounding techniques so that an agent draws on approved data sources rather than generating unsupported assertions that could mislead a citizen or a caseworker.

Beyond the built in filters, a responsible deployment defines the agent's scope through system instructions, tool permissions, and clear boundaries on the actions it may take. Human oversight remains essential for consequential decisions, so agents that touch entitlements, compliance, or personal information should route those outcomes to a person for confirmation. Logging every prompt, response, and tool invocation supports later review and gives the agency a defensible record of how the system behaved in specific cases.

Network isolation and private connectivity

Default public endpoints are rarely appropriate for government workloads, so network isolation should be designed early rather than retrofitted. Azure Private Link and private endpoints allow the Foundry resources and their dependencies to be reached over the agency's virtual network without traversing the public internet, and public network access can be disabled on the relevant resources. This approach keeps traffic within a controlled path and aligns with the principle of exposing the minimum necessary surface to the outside world.

Identity controls complete the isolation picture, because network boundaries alone do not prevent misuse by an over privileged account. Access to the agent and its administration should be governed through Microsoft Entra ID, with role based access control, conditional access policies, and just in time elevation for administrative tasks. Managed identities should be used for service to service authentication so that secrets are not stored in configuration, and diagnostic logs should flow to a monitored workspace for retention and alerting.

Governance, auditability, and rollout readiness

An auditable rollout depends on evidence that spans configuration, monitoring, and change management, and this evidence should be assembled as the environment is built rather than reconstructed afterwards. Teams should capture the region settings, filter thresholds, network topology, and access model in a design record that a governance forum can approve. Continuous monitoring through Azure Monitor and Microsoft Defender for Cloud then provides ongoing assurance that the approved configuration remains in place over time.

Before production, agencies benefit from a staged approach that validates the agent against representative data and realistic scenarios in a non production environment. This period allows the assurance team to test content filters, confirm that private connectivity behaves as intended, and verify that logging captures the detail required for later review. A deployment that passes this validation, with its controls documented and its data kept within Australian regions, gives WA public sector leaders a defensible basis for taking an AI agent to production.

References

• Azure AI Foundry documentation
• Azure OpenAI content filtering
• Australian Government Information Security Manual