Microsoft shifts AI governance from policy document to runtime enforcement

InfoQ reported on 24 August 2026, based on the EU AI Act Newsroom, that Microsoft is shifting its AI governance from documented policy to runtime enforcement. Rather than treating policy as a static document, Microsoft models governance as four living functions: policy, control, visibility and evidence. These are enforced while AI agents, models and tools run in production. In practice this means the core question shifts from whether you have an AI policy to what is actually constrained, logged and made demonstrable during execution.

For organisations handling confidential information, governance therefore revolves around which agents exist, what rights and tool access they have, and what evidence about their behaviour is available. Microsoft underpins this with concrete technical building blocks such as identity-bound agents, a policy engine that intercepts actions, and governance in Windows execution containers.

What exactly did Microsoft announce according to InfoQ?

According to the InfoQ report on Microsoft's shift to runtime enforcement, Microsoft describes a governance architecture that ties AI policy to enforced, observable controls while systems run. InfoQ summarises this as a movement from documented policy to runtime enforcement, continuous evaluation, observability and audit evidence.

The architecture has four functions and nine domains. The four functions are:

• Policy: the rules that apply to what AI is allowed to do.
• Control: the enforcement of those rules at the moment of execution.
• Visibility: being able to see what agents, models and tools actually do.
• Evidence: recording in an auditable way what happened, under which authority and what changed.

InfoQ emphasises that the controls extend across users, agents, models, tools, APIs and business systems, and links this to transparency and evidence expectations under the EU AI Act. In our assessment the core here is not yet another set of principles, but the shift that policy only counts once it is enforced and observable during execution.

What does runtime governance look like in code and platform?

Microsoft has described the approach not only at a conceptual level, but also translated it into concrete artefacts. In the official security blog Least privilege for AI agents, Microsoft states that teams should treat every agent as a first-class principal, with a lifecycle identity, task-oriented roles and controlled tool access, plus end-to-end auditability to answer quickly what happened and under which authority.

The open-source Agent Governance Toolkit, announced by Microsoft on 2 April 2026, goes further with a policy engine that intercepts every agent action before execution and tests it against a configurable rule set. According to Microsoft, the toolkit covers all ten OWASP risks for agentic AI, and a compliance module collects evidence linked to, among others, the EU AI Act, HIPAA and SOC 2. An independent technical analysis of the same toolkit describes that a minimal configuration amounts to a YAML policy file and a decorator or callback, thereby linking policy-as-code directly to enforcement-during-execution.

Microsoft extends this line to the operating system. In the Windows Developer Blog, Microsoft introduces the Microsoft Execution Containers (MXC) SDK as a policy-driven execution layer for agents, with session isolation, unique local IDs and controlled local access, managed via Entra and Intune. Those who want to know more about the why of recording will find context in our piece on from logging obligation to reconstruction obligation for AI agents and on a governance framework that separates can from may.

What does this mean for teams working with confidential information?

For professionals in law, finance, healthcare or public services the practical question shifts. In our assessment, governance in this model is no longer about the existence of a policy document, but about which runtime constraints, logs and evidence actually surround your agents. Concretely, you can test this against the following points:

1. Which agents exist and does each have its own, bounded identity?
2. Which roles and tool access are granted, and are they task-oriented rather than broad?
3. Which actions are intercepted before execution and tested against policy?
4. Which evidence is collected automatically and to which frameworks is it linked?
5. Where do the remaining gaps sit between policy and enforced behaviour?

This shift ties into broader arrangements you can set out contractually, as discussed in our article on audit rights and evidence obligations in AI contracts. For the broader context of policy, oversight and accountability, we refer you to our topic hub on AI governance and oversight.

What role do verification consoles such as Vera retain in a runtime model?

If governance shifts to runtime enforcement, the role of a verification console also changes. In our assessment, such a console can only remain credible if it makes the runtime controls and evidence trails visible per workflow, rather than sitting alongside static policy documents. A console is then a viewing layer over the controls, not a new source of policy.

In this light, Vera is a privacy-focused verification layer for professionals working with confidential or high-trust information. Vera is not a chatbot and not its own language model. Vera can route a task through selected, independent AI models and make verification steps, corrections, disagreements and sources visible for inspection. This supports review and gives more insight into AI behaviour, but it does not verify correctness on its own and does not remove the need to check for hallucinations.

On confidentiality, Vera is designed so that pre-processing and anonymisation take place on EU infrastructure, where the Semantic Privacy Shield can replace sensitive values with synthetic, session-only equivalents before AI processing. The workflow is fail-closed: if the privacy verification fails, the document is not sent onward. The professional final judgement remains with the user. In a Microsoft-heavy environment, the value in our view lies in professionals being able to check which agents exist, which runtime controls apply and which evidence is collected, so that the architecture becomes readable rather than a black box.

Sources: The article draws on the InfoQ report via the EU AI Act Newsroom and on official Microsoft publications about least privilege for AI agents, the Agent Governance Toolkit and Windows Execution Containers, supplemented by an independent technical analysis.

← All articles in this topic ← All articles