What Each Tool Actually Does
AWS Audit Manager and Microsoft Purview Compliance Manager solve a similar problem from different cloud vantage points. Both automate the collection of compliance evidence from resource configurations and account activity, then map that evidence to control frameworks so audit teams spend less time manually assembling documentation.
AWS Audit Manager continuously collects evidence from AWS Config, AWS CloudTrail, and AWS Security Hub, then organizes it against prebuilt or custom frameworks. Its evidence is fundamentally configuration and log based: encryption settings, IAM policies, logging enablement, and account activity trails.
Purview Compliance Manager takes a comparable approach inside the Microsoft ecosystem. It assigns a compliance score and runs control assessments against templates for standards such as ISO 27001, NIST, and GDPR, generating recommended improvement actions. Its signals come primarily from Microsoft 365 and Azure service configuration state rather than direct observation of AI model or agent execution.
Both tools function as audit accelerators for infrastructure and access-control evidence. Neither was built to observe, and neither claims to observe, what an AI model or agent actually does during a live session.
Core Differences at a Glance
| Aspect | Details |
|---|---|
| Primary scope | AWS Audit Manager covers AWS accounts and resources; Purview Compliance Manager covers Microsoft 365 tenants and Azure resources. |
| Evidence source | Both draw from configuration and activity logs (AWS Config, CloudTrail, Security Hub; Microsoft Graph, Azure Policy), not runtime telemetry. |
| AI framework coverage | AWS offers a prebuilt Generative AI Best Practices Framework; Purview extends templates toward emerging AI regulation. |
| Runtime and agent coverage | Neither platform natively captures AI agent permissions, tool-call activity, or in-session policy enforcement. |
AI-Specific Coverage: Frameworks and Templates
AWS Audit Manager includes a prebuilt Generative AI Best Practices Framework intended to help assess AI workloads, including those built on Amazon Bedrock and SageMaker, against responsible-AI-oriented control areas such as accuracy, fairness, privacy, and resilience. Where prebuilt controls do not cover a specific SageMaker or Bedrock configuration, Audit Manager's custom framework and custom control features allow governance teams to define additional mappings, though this requires manual authoring of what the control should verify.
Purview Compliance Manager's assessment templates draw primarily on Microsoft 365 and Azure service configuration signals. Microsoft has separately published a Responsible AI Standard and associated impact assessment guidance intended to inform governance of AI systems, but this sits apart from the core Compliance Manager control assessment engine rather than being fully integrated into automated evidence collection.
In both cases, the AI-specific coverage available today is framework and template level: it structures what should be checked, but the underlying evidence remains resource configuration and account activity, not observed model or agent behavior.
The Shared Gap: Runtime Behavior and Agent Activity
Neither platform natively ingests AI-specific telemetry such as prompt and response logs, tool-call sequences, or agent permission scopes as first-class audit evidence types. Evidence produced by both tools is snapshot and configuration oriented, reflecting a point-in-time state of resources and logging settings rather than continuous observation of what an AI agent does between assessment cycles.
This is not a gap unique to one vendor. AWS documentation describes Audit Manager evidence as tied to resource configuration and account activity logs, not to model output content, agent reasoning, or tool-call sequences. Purview's assessment model is similarly built around control-to-evidence mapping sourced from configuration signals rather than runtime behavior.
Both AWS and Microsoft publish shared-responsibility guidance clarifying that customers remain responsible for governance of workload-level logic, including AI application behavior, on top of provider-managed infrastructure controls. In practice, this means an enterprise can pass a compliance assessment in either tool while still having no automated record of whether an AI agent exceeded its intended permissions or called an unapproved tool during a session.
Where Native Compliance Tooling Ends and Runtime Governance Begins
Audit evidence exported from AWS Audit Manager or Purview Compliance Manager should be treated as a compliance-configuration record, not as proof of safe or compliant AI runtime behavior, when presented to auditors or regulators. Relying on prebuilt frameworks alone can create a false sense of complete AI compliance coverage if governance teams do not separately validate what happens once an AI agent is running.
The practical implication for AI governance leaders is that infrastructure-level compliance tooling and AI agent runtime governance are complementary, not interchangeable. Infrastructure evidence confirms that resources are configured correctly and logging is enabled. It does not confirm that an agent operated within its intended permissions, that a tool call was approved, or that a policy was enforced during a live session.
Trussed AI addresses this specific layer, focused on runtime governance and security for enterprise AI agents, including agent identity, agent permissions, least privilege enforcement, tool approval workflows, and audit logging of actual agent and tool-call activity. This is intended to sit alongside AWS Audit Manager or Purview Compliance Manager, not replace the infrastructure evidence they already generate.