Enterprise Audit & Compliance

Sovereign Foundry - Audit & Compliance Capabilities

How the Foundry operates as a first-class auditable workload - layering onto your Microsoft compliance estate so every human action, AI decision, approval, deployment, and data movement is attributable, explainable, and available for enterprise investigation, retention, and compliance reporting.

Executive Overview

For a large enterprise deployment of Sovereign Foundry, audit is not a simple application log. It is a first-class governance and assurance capability that integrates with the customer's existing enterprise compliance estate.

The recommended position is that the Foundry operates as an auditable workload where every human action, AI action, agent action, approval, deployment, data access event, and administrative change is attributable to a named identity and available for enterprise investigation, retention, and compliance reporting.

The enterprise integration targets

Foundry audit aligns with the Microsoft compliance services your organisation already runs: Microsoft Entra ID for identity attribution, Microsoft Purview Audit & Records Management for enterprise audit visibility and retention, Microsoft Sentinel for security operations and incident correlation, and Azure Monitor / Log Analytics for operational logging, KQL querying, and dashboarding.

What This Page Covers

The audit questions every enterprise must be able to answer quickly and defensibly
A five-layer audit architecture that layers onto your Microsoft estate
The Foundry native audit event taxonomy and Purview correlation model
The AI explainability ledger, audit event schema, retention, evidence packs, and roadmap (in the following sections)

Target Audit Outcomes

The audit design lets a large organisation answer the following questions quickly and defensibly. The source column shows which audit layer provides the evidence for each answer.

Audit Question	Required Capability	Evidence Source
Who performed the action?	Named Entra user, service principal, or managed identity attribution.	Entra ID
What did they do?	Structured Foundry audit event taxonomy.	Foundry
When did it happen?	Immutable UTC timestamp and time-normalised reporting.	Foundry
Where did it occur?	Tenant, workspace, project, app, agent, and environment context.	Foundry
What data was involved?	Document, record, source system, classification, and sensitivity metadata.	Foundry
Was AI involved?	Agent ID, model ID, prompt hash, retrieval events, and output trace.	Foundry
Was it approved?	Human approval workflow with approver, outcome, and timestamp.	Foundry
Was the action successful?	Result status, exception details, and correlation ID.	Foundry
Can it be investigated centrally?	Integration with Sentinel, Purview, and Log Analytics.	Sentinel
Can it be retained and exported?	Retention labels, immutable storage, and exportable evidence packs.	Purview

Layered Microsoft Audit Architecture

Foundry audit is designed as a layered capability. Each layer answers a distinct audit question and feeds the next, so identity, business action, operational query, security investigation, and enterprise compliance alignment stack into a single coherent audit trail.

Microsoft Entra ID Identity Attribution

Microsoft Entra ID

The authoritative identity layer.

Entra ID is the authoritative identity layer for the Foundry. Every Foundry audit event carries the Entra identifiers of the actor, so identity attribution never depends solely on application-side claims. Entra ID exposes three native log streams - audit logs (directory and configuration changes), sign-in logs (interactive, service-principal, and managed-identity authentication), and provisioning logs - all routable to Log Analytics and Sentinel through diagnostic settings.

Captures

User interactive and non-interactive sign-ins
Service principal and managed identity sign-ins
Privileged role activations and assignments (Entra PIM)
Conditional Access policy outcomes and grant/session enforcement
Failed authentication and risky sign-in attempts
Workload identity and Microsoft Graph activity logs

Key Microsoft facts

Entra Conditional Access evaluates users, workload identities, and (in preview) AI agents against grant and session controls - including MFA, authentication strength, compliant device, and sign-in frequency.
Entra Privileged Identity Management provides just-in-time, time-bound, approval-gated role activation with its own activation audit history.
Entra diagnostic settings stream audit, sign-in, and provisioning logs into Log Analytics and Sentinel for central correlation.

Answers

Who was the authenticated actor?

Foundry Native Audit Service

Sovereign Foundry

Immutable business and AI-level audit events.

The Foundry native audit service writes immutable business-level audit events for actions that Microsoft 365 and Azure platform logs cannot interpret on their own - prompt submissions, agent decisions, generated outputs, skill changes, and approval outcomes. Every event carries a stable schema version and a correlation ID so the full human + AI chain can be reconstructed end to end.

Captures

Authentication, workspace, and project governance events
Security role, permission, and policy override events
AI activity: prompts, retrieval, model invocations, and generated outputs
Agent actions: emails drafted, documents created, workflows executed
Human approvals: requested, approved, rejected, escalated, expired
Data access, data movement, administration, deployment, and compliance events

Key Microsoft facts

Foundry is the only layer that understands AI-specific events - prompts, retrieval traces, skill applications, and approval chains.
Events are emitted as structured JSON with a schema version and correlation ID so the full chain can be reconstructed.
The audit taxonomy below is the canonical category set used across all Foundry events.

Answers

What business and AI action occurred?

Azure Monitor & Log Analytics

Azure Monitor / Log Analytics

The operational logging and query store.

All Foundry audit events flow into Azure Monitor / Log Analytics as the operational logging store. Structured JSON audit records are ingested through the Logs Ingestion API (governed by a Data Collection Rule and an optional KQL transformation) into a dedicated custom table, giving auditors KQL query access, dashboards, alert rules, configurable retention, and export to storage accounts or event hubs.

Captures

Structured JSON audit records with a stable schema version
Tenant, workspace, project, environment, and app identifiers on every event
A correlation ID propagated across app, AI, workflow, and log events
Workspace-level separation for regulated customers
Formal audit records kept distinct from diagnostic telemetry

Key Microsoft facts

The Logs Ingestion API accepts JSON into custom or built-in tables via a Data Collection Rule; TLS 1.2+ is enforced from March 2026.
Log Analytics offers table-level retention tiers - interactive (up to 90 days), archive (up to 12 years), and low-cost auxiliary tables for high-volume verbose logs.
Workspace data export and diagnostic settings continuously stream selected tables to a Storage Account or Event Hubs for long-term retention or downstream GRC tooling.

Answers

How is it queried, retained, and exported?

Microsoft Sentinel Integration

Microsoft Sentinel

Security investigation and cross-signal correlation.

Microsoft Sentinel is the cloud-native SIEM where Foundry audit events are correlated with the wider Microsoft security estate. Because Foundry events already live in Log Analytics, Sentinel analytics rules, hunting queries, and workbooks can join them with Entra sign-in logs, Defender alerts, Purview DLP matches, and Microsoft 365 audit activity to build a single coherent incident timeline.

Captures

Entra ID sign-in and audit logs
Defender for Cloud and Defender for Endpoint alerts
Microsoft Purview DLP events
SharePoint, OneDrive, Teams, and Exchange audit activity
Azure activity and platform logs

Key Microsoft facts

Sentinel remains a standalone SIEM, now operational in both the Azure portal and the unified Microsoft Defender portal (Azure portal support ends 31 March 2027).
Content hub ships built-in workbooks, scheduled and NRT analytics rules, Fusion multistage detection, and MITRE ATT&CK-mapped hunting queries.
100+ out-of-box data connectors plus custom connectors via the Logs Ingestion API let Foundry appear as a first-class auditable workload.

Answers

How is it investigated and correlated?

Microsoft Purview Compliance Alignment

Microsoft Purview

The enterprise compliance and audit lens.

Microsoft Purview is the customer’s enterprise compliance and audit lens. The design objective is that Foundry activity is discoverable and correlatable alongside Microsoft 365 activity. Two practical integration patterns are supported: a Purview Correlation Model (Option A) where Foundry events store the identifiers needed to join against the Purview unified audit log, and a longer-term Custom Enterprise Audit Workload Model (Option B) where significant Foundry events are emitted into the enterprise audit ecosystem.

Captures

Correlation identifiers that join Foundry events to Purview, SharePoint, Teams, Exchange, and DLP records
Sensitivity and retention label capture on audited resources
Foundry events mapped to enterprise audit interpretations (Option B)
Retention, legal hold, and disposition alignment through Purview Records Management

Key Microsoft facts

Purview Audit (Standard) provides the unified audit log with 180-day retention; Audit (Premium) adds longer retention and access to crucial mailbox-events auditing.
Purview Records Management governs retention labels, auto-apply policies, event-based disposition, legal hold, and disposition review.
Purview DLP detects sensitive data across Microsoft 365 services and endpoints, producing policy-match events Sentinel can correlate with Foundry activity.

Answers

How does it align with enterprise compliance?

Foundry Audit Event Taxonomy

The Foundry native audit service emits events across the canonical categories below. This taxonomy captures actions that Microsoft 365 and Azure platform logs cannot interpret on their own - especially AI activity, agent actions, and human approvals.

Category	Example Events
Authentication	User logged in, user logged out, session expired
Workspace Governance	Workspace created, archived, deleted, or restored
Project Governance	Project created, changed, published, or decommissioned
Security	Role assigned, permission changed, policy overridden
AI Activity	Prompt submitted, retrieval performed, model invoked, response generated
Agent Actions	Email drafted, document created, workflow executed, connector called
Human Approvals	Approval requested, approved, rejected, escalated, or expired
Data Access	Document opened, record viewed, file exported, source queried
Data Movement	Export generated, package downloaded, integration sync performed
Administration	Skill modified, policy changed, connector configured
Deployment	Release promoted, environment changed, infrastructure updated
Compliance	Retention label applied, hold triggered, evidence pack generated

Purview Correlation & Workload Models

Option A - Purview Correlation Model

The most realistic starting point. Foundry events store the identifiers below so investigators can join Foundry activity against Purview, SharePoint, Teams, Exchange, and DLP audit results without bespoke integration.

Correlation Identifier	Joins To
Entra user ID	Entra ID audit and sign-in logs
User principal name	Purview unified audit log actor
SharePoint site ID	SharePoint site activity
SharePoint list or drive item ID	SharePoint file and list activity
Document ID	SharePoint / OneDrive document events
Teams message ID	Teams audit activity
Exchange message ID	Exchange mail audit activity
Sensitivity label ID	Purview Information Protection events
Retention label ID	Purview Records Management events
Correlation ID	Foundry, Log Analytics, and Sentinel event chains

Option B - Custom Enterprise Audit Workload Model

The longer-term enterprise design. Foundry emits significant audit events into the customer's enterprise audit ecosystem so Foundry appears as a recognised auditable workload. This lets an auditor ask “show everything this user did yesterday across Microsoft 365, Azure, and Foundry” and receive a coherent audit trail.

Foundry Event	Enterprise Audit Interpretation
Prompt submitted	AI activity event
Retrieval performed	Data access event
Agent invoked	Automated processing event
Human approval granted	Governance approval event
Skill modified	AI governance configuration change
Policy overridden	Compliance control exception
Document generated	Record creation event
Export performed	Data movement event
Deployment promoted	Change control event
Connector configured	Integration administration event

Cross-Signal Investigation Scenario

The value of layering onto Sentinel is cross-signal correlation. A single sensitive-data export becomes one incident that joins Foundry, Purview, and Defender evidence:

1A user exports sensitive records from Foundry.
2Foundry records a DataExported audit event, attributed to the Entra actor.
3Purview records a DLP policy match on the exported content.
4Defender for Endpoint records endpoint file movement.
5Sentinel correlates the Foundry, Purview, and Defender signals into a single incident.

Enterprise audit maturity

This is the level of audit maturity that government, regulated industry, and large corporates expect - a single incident timeline that spans the AI platform and the wider Microsoft security estate.

Key Design Principles

The audit capability is built on the principles below. They keep Foundry audit defensible, customer-controlled, and aligned to enterprise assurance practice.

Principle	Recommendation
Audit by design	Every material action emits an audit event.
Identity first	Every event links to an Entra identity or managed identity.
Explainable AI	AI actions are reconstructable and attributable.
Customer controlled	Audit data stays in the customer-controlled environment.
SIEM ready	Events are queryable in Sentinel and Log Analytics.
Purview aligned	Events correlate with Microsoft 365 compliance activity.
Retention aware	Audit data supports enterprise retention and hold requirements.
Immutable where required	Security and regulated audit events cannot be altered by normal admins.
Least privilege	Audit access is role controlled and itself audited.
Evidence ready	Foundry generates audit evidence packs for assurance processes.

AI Explainability Audit Ledger

The AI explainability audit ledger is a major Foundry differentiator. For every AI-assisted action, Foundry records an explainability chain that lets an auditor reconstruct exactly what the AI did, what it relied on, and how the outcome was approved and acted upon.

Minimum Explainability Fields

Field	Description
User Prompt Hash	Hash of the submitted prompt, with configurable storage of the full prompt where permitted.
Prompt Classification	Sensitivity or business classification of the prompt.
Retrieved Sources	Documents, records, APIs, or knowledge stores used to ground the response.
Retrieval Query	Search or vector query metadata, stored where permitted.
Skill Files Applied	Governance, instruction, or transformation skills used for the action.
Policies Applied	Safety, privacy, security, or customer-specific controls applied.
Model Provider	Azure OpenAI, local model, or other configured provider.
Model Name and Version	Specific model used for generation, with version.
Runtime Parameters	Temperature, top-p, or other relevant generation configuration.
Agent ID	Agent or application responsible for the action.
Output Hash	Hash of the generated response or artefact.
Human Review	Whether human approval was required for the action.
Approval Outcome	Approved, rejected, escalated, or modified.
Final Action	Whether the output was saved, sent, published, exported, or discarded.

Why this matters

Auditors will increasingly ask “Why did the AI produce this output and what information did it rely on?” The explainability ledger lets Foundry answer that question defensibly.

What an Auditor Can Reconstruct

From the explainability chain, Foundry can reconstruct:

1The user intent (the prompt that was submitted).
2The data retrieved to ground the response.
3The skills and policies applied during generation.
4The model used, including provider, name, and version.
5The generated output.
6The human approval chain and outcome.
7The final business action taken on the output.

Where It Matters Most

The explainability ledger is especially important for regulated and high-stakes contexts:

Government decision support
Regulated workflows
Contract generation
Citizen-facing communications
Legal, HR, or financial content
Cybersecurity and compliance actions

Canonical Audit Event Schema

All Foundry audit events use a consistent structured schema. The example below shows a PromptSubmitted event — an AI activity record that carries identity attribution, agent context, resource classification, the explainability payload, and correlation IDs in a single record.

audit-event.json - schema version 1.0

{
  "schemaVersion": "1.0",
  "eventId": "01J123EXAMPLE",
  "eventType": "PromptSubmitted",
  "eventCategory": "AIActivity",
  "timestampUtc": "2026-07-25T06:32:14Z",
  "tenantId": "customer-tenant-id",
  "workspaceId": "workspace-id",
  "projectId": "project-id",
  "environment": "Production",
  "actor": {
    "type": "User",
    "userPrincipalName": "user@example.gov.au",
    "entraObjectId": "00000000-0000-0000-0000-000000000000"
  },
  "agent": {
    "agentId": "agreement-manager-agent",
    "agentName": "Agreement Manager"
  },
  "resource": {
    "resourceType": "Document",
    "resourceId": "document-id",
    "classification": "Protected",
    "sensitivityLabel": "Official Sensitive"
  },
  "action": {
    "name": "SubmitPrompt",
    "result": "Success",
    "reason": null
  },
  "ai": {
    "modelProvider": "Azure OpenAI",
    "modelName": "configured-model-name",
    "promptHash": "sha256-hash",
    "outputHash": "sha256-hash",
    "retrievalPerformed": true,
    "humanApprovalRequired": false
  },
  "correlation": {
    "correlationId": "correlation-id",
    "sessionId": "session-id",
    "requestId": "request-id"
  }
}

Field Groups

The schema is organised into six field groups, each answering a distinct audit question:

Group	Purpose
actor	Identity attribution - the Entra user, service principal, or managed identity behind the event.
agent	The Foundry agent or application responsible for the action, when AI is involved.
resource	The document, record, or resource touched, with classification and sensitivity label.
action	What was done, the result status, and any failure reason.
ai	The explainability payload - model, prompt/output hashes, retrieval flag, and approval requirement.
correlation	Correlation, session, and request IDs that chain the event across Log Analytics and Sentinel.

Structured for the enterprise estate

Because every event carries a schema version, a correlation ID, and Entra identity attributes, the same record is queryable in Log Analytics via KQL, joinable in Sentinel against Entra and Defender signals, and correlatable in Purview alongside Microsoft 365 audit activity.

Retention & Records Management

Foundry supports configurable audit retention tiers so different classes of audit data are retained according to their assurance and compliance requirements — from short-lived operational telemetry to immutable legal-hold material.

Audit Retention Tiers

Audit Class	Example Content	Retention Approach
Operational Telemetry	Performance, health, non-sensitive diagnostics	Short-term operational retention
Security Audit	Login, permission, admin, and data access events	Longer security retention
AI Explainability Ledger	Prompt, retrieval, model, output, and approval trace	Customer-defined compliance retention
Regulated Records	Evidence packs, approvals, formal outputs	Retention label and records management alignment
Legal Hold Material	Events subject to investigation or preservation	Hold-capable immutable storage

Government-Grade Records Management

For government and regulated customers, the platform supports the records management capabilities below — aligned with Microsoft Purview Records Management for retention labels, legal hold, and disposition:

Immutable audit storage
Customer-managed retention policies
Exportable audit evidence packs
Legal hold alignment
Disposition workflows
Segregation by tenant, workspace, and environment

Alignment with Purview Records Management

Purview Records Management governs retention labels, auto-apply policies, event-based disposition, legal hold, and disposition review. Foundry retention tiers map onto those labels so audit records are managed under the same compliance framework as the rest of the Microsoft 365 estate.

One-Click Evidence Packs

Foundry can generate a one-click evidence pack for any audit scope — a self-contained, exportable bundle that gives an auditor or investigator everything they need to understand and defend an action without further manual assembly.

What an Evidence Pack Contains

Component	Description
Audit event timeline	Ordered sequence of every audit event in the scope of the pack.
User identity details	Entra-attributed identity, role, and session context for each actor.
AI explainability chain	Prompt, retrieval, model, output hashes, skills, policies, and approval outcome.
Source documents used	Documents, records, and knowledge stores retrieved during the action.
Approval records	Human approval requests, outcomes, approvers, and timestamps.
Generated artefacts	Drafts, documents, or outputs produced by the agent.
Export history	Data movement and export events associated with the action.
Policy decisions	Safety, privacy, and security controls applied and their outcomes.
Exception records	Policy overrides, escalations, and compliance control exceptions.
Correlation IDs	Identifiers for joining the pack into Purview and Sentinel investigations.

Use Cases

Evidence packs serve the assurance, investigation, and regulatory response scenarios that regulated organisations face regularly:

Internal audit review

Cybersecurity investigation

Procurement governance review

AI assurance assessment

FOI or records discovery support

Contract generation traceability

Regulator response

Correlation-ready by design

Every evidence pack includes the correlation IDs needed to join the pack into Purview and Sentinel investigations, so a pack is not an isolated artefact — it plugs straight into the enterprise audit ecosystem.

Foundry Audit Explorer

The Foundry Audit Explorer is the in-product investigation interface for platform administrators and authorised auditors. Instead of leaving investigators to write raw KQL or dig through Log Analytics, the explorer provides a structured search experience that maps onto the audit taxonomy and correlation model — so an auditor can answer a precise question in seconds and drill into the underlying events.

Search Filters

Every filter below maps directly onto a field in the canonical audit event schema, so the explorer is not a simplified view — it is a guided query over the same structured records Sentinel and Log Analytics see.

Filter	Description
User	Filter by Entra user principal or object ID.
Workspace	Restrict results to a specific tenant workspace.
Project	Filter by Foundry project or application.
Agent	Show only events from a specific agent or application.
Event type	Filter by audit event category (AI Activity, Data Access, etc.).
Date range	Time-box the investigation window.
Sensitivity label	Filter by Purview sensitivity label on the resource.
Data source	Filter by source system or knowledge store accessed.
Customer system	Filter by the external or line-of-business system involved.
Result status	Filter by success, failure, or exception outcomes.
Approval outcome	Filter by approved, rejected, escalated, or expired approvals.
Model used	Filter by AI model provider, name, or version.
Correlation ID	Trace a single chain across app, AI, workflow, and log events.

Example Searches

The explorer accepts plain-language queries. These illustrative examples show the kinds of investigative questions an auditor can run directly:

Show all prompts submitted by a user in the last 30 days.

Show all exports from the Agreement Manager project.

Show all agent actions that required approval but were rejected.

Show all generated documents that used Protected-classified source material.

Show all policy overrides in production.

A guided path to the same evidence

The explorer sits on top of the same structured audit records that flow into Log Analytics and Sentinel. An investigator can start in the explorer, find the relevant correlation ID, and then pivot into Sentinel for cross-signal correlation — without losing the chain of evidence.

Security & Privacy of Audit Data

Audit records are themselves sensitive data. The design prevents the audit store from becoming an uncontrolled secondary sensitive-data repository by applying the controls below — so auditability and data protection reinforce each other rather than competing.

Control	How It Works
Hash-by-default prompts and outputs	Prompt and output hashes are stored by default; full capture only where the customer explicitly permits it.
Encryption at rest	Audit records are encrypted at rest in the customer environment.
Customer-managed keys	Support for customer-managed encryption keys where required.
Role-based audit search access	Access to audit search is governed by RBAC, not blanket administrator rights.
Auditor / administrator separation	Operational administrators and audit reviewers are separated so admins cannot suppress audit findings.
Audit-of-audit-access	Access to audit logs is itself logged, so any review of sensitive audit data is traceable.
Field-level redaction	Sensitive fields are redacted in lower-privilege views to limit exposure.
Tenant-level data residency	Audit data respects tenant-level data residency requirements.
Deletion protection	Normal administrators cannot delete audit history; only governed disposition workflows can remove records.

Audit-of-audit-access

Access to audit logs is itself logged. Any review of sensitive audit data is traceable, so an investigator cannot examine audit records without leaving their own footprint. This is the control that keeps the audit capability trustworthy over time.

Capability Maturity Roadmap

Foundry audit is delivered as a phased maturity path. The phases below show what is delivered today, what is actively in progress, and what is planned — so enterprise evaluators can see exactly where the capability stands and where it is heading.

Phase 1: Foundation

Delivered

The core audit table and identity attribution that every later capability builds on.

Native Foundry audit table

Standard audit event taxonomy

Entra ID actor attribution

Correlation IDs across requests

Basic admin audit viewer

Export to Log Analytics

Phase 2: Enterprise Operations

Active

Sentinel integration, KQL dashboards, and alerting for security operations teams.

Microsoft Sentinel connector or integration pattern

KQL dashboard pack

Alert rules for high-risk events

Workspace and project-level audit filtering

Exportable CSV/JSON audit records

Audit schema versioning

Phase 3: Purview & Records Alignment

Planned

Correlation identifiers, label capture, evidence packs, and records management alignment.

Purview correlation identifiers

Sensitivity and retention label capture

Evidence pack generation

Records management alignment

Retention tier configuration

Legal hold support pattern

Phase 4: AI Assurance

Planned

The explainability ledger, prompt/output hash chain, and auditor-facing reconstruction.

AI explainability ledger

Prompt/output hash chain

Skill and policy traceability

Model version traceability

Human approval trace

Auditor-facing reconstruction view

Phase 5: Advanced Governance

Planned

The Foundry Audit Explorer, risk scoring, automated compliance reports, and GRC API access.

Foundry Audit Explorer

Risk scoring for audit events

Automated compliance reports

Cross-system investigation views

Customer-configurable audit policies

API access for enterprise GRC platforms

Honest about maturity

This roadmap is presented as a maturity path, not a feature list. Foundry does not claim the full advanced-governance capability is already delivered — the phased model lets an enterprise evaluator assess what is available today and what commitment they are buying into.

Enterprise Positioning

Built for enterprise assurance, Sovereign Foundry provides end-to-end auditability across users, agents, prompts, approvals, data access, generated outputs and deployments. Audit records can be integrated with Microsoft Entra ID, Microsoft Purview, Microsoft Sentinel and Azure Monitor to support investigation, retention, compliance reporting and AI assurance.

This is the differentiator. Foundry is not merely focused on building AI workflows — it is focused on operating those workflows safely inside regulated enterprise environments. The layered audit architecture, AI explainability ledger, and records management alignment exist so that an organisation can adopt governed AI without surrendering its ability to prove what happened and why.

Foundry does not just help organisations build AI-enabled systems. It helps them prove what happened, who did it, what data was used, what the AI produced, who approved it and how the outcome was governed.

Continue exploring:Detailed Design — Monitoring & Identity