Azure API Management Policy Revision History: What It Can and Cannot Prove About AI Policy

Configuration provenance is not enforcement evidence

Auditors and regulators tend to ask a narrow question: which AI policy governed this request, at this time, and what was the outcome? Teams routing AI traffic through Azure API Management often reach for revision history, change logs and exported policy definitions. Those artifacts record configuration state and change events at the service level. That is useful, and it is a necessary part of the answer.

But two different evidence classes are involved. Configuration provenance describes what was configured, who changed it and when. Enforcement evidence describes what was applied to a specific request: which policy revision, which identity, which action. A revision list can tell you that a policy existed. It does not, by itself, tell you that a given request passed through it, or that the request was allowed, redacted or blocked.

The gap matters most when the question is asked months later, after revisions have been added, reverted or retired.

Mapping each artifact to the audit question it can answer

Test every candidate artifact against the same question: can it be tied to one request, one identity and one outcome? The table states what each artifact class is generally suited to and where it needs support. Confirm the specific behavior, retention and immutability of each against current Microsoft documentation for your service tier.

• Revision history and the current-revision designation: Can establish: which policy configuration existed and which revision was designated current. Cannot establish alone: that a specific request was processed under that revision, or the enforcement outcome.
• Exported policy definitions: Can establish: the exact policy logic at export time. Cannot establish alone: when it was active, or that the exported copy matches what ran for a past request.
• Azure Activity Log and change events: Can establish: that a configuration change occurred, by whom and when. Cannot establish alone: which requests were affected by the change.
• Gateway and diagnostic logs: Can establish: request-level records, within what is configured to be emitted. Cannot establish alone: the governing policy revision, unless a revision identifier is deliberately recorded with each request.
• Git-based configuration: Can establish: a reviewable, attributable history of intended configuration. Cannot establish alone: what was deployed and running at a given moment, without a link between commits and deployments.
• AI gateway policy definitions: Can establish: which controls were configured for AI traffic. Cannot establish alone: whether each control fired on a given request, and with what result.

The reconstruction problem

Without a per-request link, the usual workaround is inference. The team takes the request timestamp, finds the revision that was current at that time, and concludes that this policy applied. This is a reasonable engineering argument, but it is not evidence. It depends on accurate clocks, on a complete change record, and on the assumption that nothing else altered behavior between configuration and execution.

Consider a revision that was changed or reverted between the request and the audit. The inference now rests on reassembling history from several systems, each with its own retention period and access rules. If any one of them has aged out, or can be edited by the same administrators whose actions are under review, the answer weakens.

Two further questions follow from this. Who can alter or delete each artifact, and how would tampering be detected? Native logging can be valuable here, but its durability depends on how retention, access control and export are configured, not simply on the logging being switched on.

Where the regulatory and standards material points

The EU AI Act text refers to keeping records and making technical documentation available. That documentation must contain the information needed to assess an AI system's compliance and to facilitate post-market monitoring. The provisions are general, so map specific articles and obligations to your system's role and risk class using the full regulation. As of November 2026, the Commission's Digital Omnibus on AI, proposed on 19 November 2025, would set fixed deadlines of 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for those embedded in products.

The AI Act also treats pre-determined changes documented at the initial conformity assessment differently from substantial modifications. That supports keeping a documented record of intended configuration, which is exactly what revision history provides.

On the runtime side, NIST IR 8621, a workshop document on incident management, lists minimum evidence for investigating AI attacks. Items include prompts and completions where permissible, agent actions, identities and API keys used, data stores accessed, retrieved content metadata, model and data version information, and tool calls. Configuration history covers almost none of these. Capturing prompts and completions needs privacy and data-protection review first.

A practical test: pick a past AI request and try to prove the governing policy and the enforcement outcome from retained artifacts alone. The gaps in that exercise are your evidence requirements.

Complementing configuration history with runtime enforcement evidence

Runtime enforcement evidence is needed when the audit question is about a specific request or tool call, when the answer must hold after revisions change, or when native records cannot carry a revision identifier, outcome and identity together. Where the question is only about how a policy was governed and changed over time, configuration history may be sufficient.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact and block. Because policy is enforced at runtime, not reviewed after the fact, each enforced decision on an individual interaction or tool call produces audit-ready evidence, mapped to frameworks including the EU AI Act, NIST, HIPAA, NAIC and NYDFS. It is self-managed in the customer cloud, with configurable retention and data residency.

This complements configuration history and does not replace it. Revision history still answers who changed a policy and when. Enforcement evidence answers what was applied to this request.