DW Sovereign Agent Platform

Technical Azure architecture

A production reference architecture for identity-aware agents, governed model access, private enterprise data and controlled tool execution inside a customer-owned Australian Azure environment.

Request the reference architecture View the platform layers

Reference architecture

One control plane across models, data and actions

The architecture separates the probabilistic agent from deterministic enterprise controls. Models can reason and plan; the surrounding platform decides what data can be retrieved, what model can process it and what actions are allowed.

DW Sovereign Agent Platform - Azure reference architecture

DW Data reference pattern
Customer Australian Azure Environment
Australia East / SoutheastPrivate networkRestricted egressCustomer-owned subscription

User & Experience

Web applicationsTeamsEnterprise appsAPIsCustom apps

Identity & Access

Entra IDConditional AccessRBACManaged Identity

Agent Platform

Microsoft FoundryOrchestrationPlanningMemoryWorkflowEvaluation

DW AI Control Plane

Model GatewayAgent Security GatewayPolicy EngineClassificationGuardrailsHuman approvalAudit

Models, Knowledge & Tools

Azure modelsApproved external modelsFabric / OneLakeAI SearchSQL / ADLSSharePointERP / CRM / APIs
A logical reference architecture. Final service selection, deployment regions, data flows and control mapping depend on the customer workload, information classification and accreditation pathway.

Platform decomposition

Eight architectural layers

Each layer has a clear responsibility, boundary and evidence trail. Service choices are adapted to the customer's existing Azure landing zone and risk profile.

Azure foundation

  • Customer-owned tenant and subscriptions
  • Australia East and Australia Southeast where appropriate
  • Azure Policy, Defender for Cloud and deployment guardrails
  • Bicep or Terraform infrastructure as code

Network boundary

  • Hub-and-spoke or Virtual WAN integration
  • Private endpoints and private DNS
  • Azure Firewall and restricted outbound access
  • Application ingress through approved gateways

Identity and access

  • Microsoft Entra ID and Conditional Access
  • Managed identities for workloads
  • Agent-specific RBAC and user delegation
  • Privileged access and separation of duties

Agent runtime

  • Microsoft Foundry Agent Service where suitable
  • Container Apps, App Service, Functions or AKS by workload
  • Durable workflows and bounded execution
  • Isolated tool runtimes for higher-risk operations

Retrieval and memory

  • Azure AI Search and governed RAG
  • Security trimming and source-level permissions
  • Citations, provenance and document trust
  • Explicit memory scope, retention and deletion

Tools and integration

  • API Management and schema-controlled APIs
  • MCP servers where the risk model permits
  • Fabric, SharePoint, ERP, CRM and line-of-business services
  • Idempotency, transaction limits and compensating actions

Model layer

  • Azure regional models where available
  • Customer-approved Foundry model catalogue
  • Explicitly permitted external frontier models
  • Routing by classification, capability, cost and latency

Operations and evidence

  • Azure Monitor, Application Insights and Log Analytics
  • Prompt, retrieval, model, tool and approval traces
  • Microsoft Sentinel integration and incident response
  • Evaluation, token, cost and service-level monitoring

Execution boundary

Tool calls are security decisions

The DW Agent Security Gateway mediates every meaningful enterprise action. The model proposes structured intent; deterministic services validate identity, policy, parameters and approvals before a tool is invoked.

DW Agent Security Gateway

DW Data reference pattern

User or system

Authenticated request and user context

Enterprise agent

Defined objective and bounded role

DW Agent Security Gateway

Identity-aware policy and execution layer

Identity validation
Agent identity
User delegation
Tool allow-list
Operation allow-list
Parameter validation
Data classification
Contextual policy
Injection detection
Content validation
Transaction limits
Human approval
Rate limiting
Immutable audit
Anomaly detection
Kill switch

Fabric / SQL

SharePoint

ERP / CRM

APIs / LOB apps

Agents receive exactly the capabilities they need - not broad access to enterprise systems. Sensitive actions can be attributed to a user, agent, model, tool and approval decision.

Policy enforcement point

Centralise allow-lists, data classification, transaction limits and approval requirements instead of scattering them across prompts.

Typed tool contracts

Use OpenAPI, JSON Schema or equivalent contracts so parameters can be validated and unsafe model-generated calls rejected.

Credential isolation

Keep secrets and workload credentials outside model context. Prefer managed identity and retrieve secrets only within controlled execution services.

Identity plane

Workload identity with user context

An agent receives its own Entra workload identity. Where a task acts on behalf of a person, the design can carry delegated user context and apply both user and agent policy before a tool is called.

Every agent gets an identity

DW Data reference pattern

Employee

User context

Entra ID

Authentication and Conditional Access

Agent identity

Separate workload identity

Managed identity

Delegated or workload access

Policy

RBAC, scope and duration

Approved tools

Allow-listed operations

Enterprise systems

Audited resources

Shared service accounts obscure responsibility. Separate workload identities, delegated authority and narrow RBAC scopes preserve user context and support traceable access decisions.

Model plane

A replaceable, policy-routed model layer

The application integrates with the DW Model Gateway. Model endpoints and routing decisions can change without rewriting the agent or weakening the security boundary.

DW Model Gateway

DW Data reference pattern

Agent

Workload and context

DW Model Gateway

Classification, use case, cost, latency, capability and sovereignty

AU regional model

Sovereignty

Approved APAC model

Availability

Frontier model

Capability

Specialist model

Task fit

Coding model

Engineering

Embedding model

Retrieval

Sensitive / high-control

AU regional approved model

Internal corporate

Approved model catalogue

Public information

Frontier model where policy allows

The exact catalogue and deployment regions depend on current service availability and customer policy. Applications integrate with a stable gateway rather than hard-coding a single model endpoint.

RAG and enterprise knowledge

Retrieval must preserve source permissions

A strong RAG design does more than vector search. It controls document ingestion, chunk provenance, classification, security trimming, query-time permissions, citations and evaluation.

Azure AI Search, Fabric, SQL, SharePoint and ADLS can all contribute knowledge. The right retrieval path depends on whether the agent needs unstructured evidence, semantic analytics, live operational data or a controlled API.

01

Ingest and classify

Record source, owner, classification, permissions, retention and content trust before indexing.

02

Retrieve with context

Filter by user, agent, purpose and source permissions before relevant content enters the prompt.

03

Ground and cite

Return evidence with stable source references, confidence signals and current-version metadata.

04

Evaluate and monitor

Test retrieval precision, answer groundedness, leakage paths and malicious document content continuously.

Sovereignty architecture

Regional when required, controlled when frontier access is permitted

DW Data documents the location of data at rest, inference processing, stateful agent data, telemetry and external tool calls. Deployment type and feature selection are assessed individually.

Sovereign-controlled frontier AI flow

DW Data reference pattern

Australian enterprise data

Data classification

Policy gateway

Redaction / minimisation

Approved frontier model

Validation

Australian application environment

A policy-controlled path for workloads where a customer explicitly permits a model outside an Australian regional deployment. Classification, minimisation and validation remain part of the application architecture.

For models sold by Azure, regional deployments process prompts and responses in the deployment region; Global and DataZone deployments use different processing boundaries. Preview features may have different conditions. Current Microsoft documentation and selected service terms are reviewed during design.

DevSecOps and AgentOps

Version the whole agent, not just the code

A release is a coordinated set of source, infrastructure, model policy, instructions, tools, evaluations and operating controls.

Source

GitHub or Azure DevOps repositories, protected branches and reviewed changes

Build

Dependency pinning, software composition analysis, tests and signed artefacts

Infrastructure

Reviewed Bicep or Terraform with policy checks and environment separation

Agent

Versioned instructions, tools, model policy, Agent Card and evaluation dataset

Release

Promotion gates, security evidence, approval and rollback plan

Operate

Health, quality, cost, access and security monitoring with incident ownership

Technology stack

Preferred Azure building blocks

Selected according to workload, availability, accreditation scope and operational fit.
Microsoft FoundryAzure OpenAIFoundry Agent ServiceAzure AI SearchAPI ManagementContainer AppsApp Service / AKSAzure FunctionsAzure SQLMicrosoft FabricOneLake / ADLSMicrosoft PurviewEntra IDManaged IdentitiesKey VaultPrivate LinkAzure FirewallAzure PolicyDefender for CloudMicrosoft SentinelAzure MonitorApplication InsightsGitHub / Azure DevOpsBicep / Terraform
From concept to controlled production

Request the reference architecture

Bring the use case, system context and information classification. DW Data can adapt the reference pattern to your Azure environment and assurance pathway.

Talk to an AI Architect Book an Assessment