AI 代理治理與評測
Microsoft Restructures AI Standards Around Models, Platforms, and Applications as Agent Governance Shifts to Runtime Intervention
Microsoft has reorganized its Responsible AI Standard to apply core and contextual requirements according to the technology stack and the company’s role. Supporting tools use executable evaluations, stateless policy decisions, and workflow intervention points to extend agent governance from predeployment documentation to continuous control.

In its 2026 Responsible AI Transparency Report, Microsoft disclosed that it has redesigned its internal Responsible AI Standard. Rather than treating an AI system solely as a single product, the new version distinguishes among three layers—models, platform services, and applications—and considers whether Microsoft acts as a developer or deployer at each layer. It then combines permanently applicable core requirements with contextual requirements that can be updated as capabilities, use cases, and regulations evolve. A [Microsoft announcement](https://blogs.microsoft.com/on-the-issues/2026/09/01/responsible-ai-in-2026-how-we-are-adapting-for-whats-ahead/) specifically identifies systems with advanced cyberattack capabilities, as well as agents that can retain memory, use tools, access data, and act on users’ behalf, as targets for enhanced oversight.
For engineering teams, the key change is that controls are expanding from model outputs to the entire agent execution chain: agent identity, tool permissions, action monitoring, and human escalation are all becoming governance objects. Microsoft also identifies ASSERT, RAMPART, and the Agent Control Specification (ACS) as implementation tools. RAMPART converts red-team findings into repeatable security regression tests written for pytest. At each intervention point, ACS receives a complete JSON state snapshot and uses a stateless, deterministic, fail-closed policy engine to return `allow`, `warn`, `deny`, `escalate`, or `transform`. The [ACS 0.3.1-beta specification](https://github.com/microsoft/agent-governance-toolkit/blob/main/policy-engine/spec/SPECIFICATION.md) also requires validation of transformed actions, rather than merely recording policy declarations.
This design enables the same policy to run across different agent frameworks and turns prompt injection, unauthorized tool calls, and unapproved data access into CI tests and runtime decisions. The report also states that Microsoft is working with MLCommons to expand AILuminate. The current benchmark quantifies safety degradation under attack using harm categories, jailbreak attacks, and the “Resilience Gap.” [MLCommons documentation](https://mlcommons.org/ailuminate/jailbreak/) shows that none of the 39 models tested achieved a jailbreak score matching its original safety rating.
The limitations are equally clear: the transparency report is primarily Microsoft’s own disclosure and does not publish pass rates for each internal standard or an incident baseline. ACS remains a draft, and its API and manifest may change before the final release. Some AILuminate evaluations still focus on single-turn interactions, a limited set of languages, and content safety, so they cannot fully represent long-horizon agents. As a next step, deployers should verify the default behavior when the policy engine is unavailable, determine whether snapshots omit external state, and ensure that `transform` operations and human escalation remain consistent across retries and concurrent tool calls.