Microsoft Rewrites AI Governance Around Agents, Permissions and Memory

Microsoft published its third annual Responsible AI Transparency Report on September 1, 2026, outlining a re-engineered internal standard for AI systems that can retain context, use tools, access data and act for users. In its September 1 announcement, the company identified agent identities, tool permissions, action monitoring and lifecycle evaluation as priorities.

The operational change is a shift from reviewing an isolated model or application toward governing the complete agent system before and after release. The official interactive report treats access, permissions, memory and use over time as variables that can alter risk, while an independent assessment by Kaleido Field characterizes the disclosure as a control inventory rather than independent assurance. All control details below are company-reported and have not been independently tested.

The standard now follows agents across the technology stack

The revised Responsible AI Standard divides requirements according to models, platform services and applications instead of treating AI as a single technical layer. It also adds separate developer and deployer chapters, distinguishing responsibility for building an AI component from responsibility for introducing an application into a working environment.

That distinction matters for agents because their behavior depends on assembled systems. A model may generate a plan, a platform may provide orchestration and an application may connect the agent to tools, data and external actions. The governance boundary therefore extends across the configuration that determines what the agent can see, remember and do.

Core requirements continue to apply broadly, while scenario-specific rules add safeguards where a use presents greater potential risk. Previously separate policies are more closely aligned with Microsoft’s Security Development Lifecycle. The company’s six responsible-AI principles remain in place; the change concerns how requirements are assigned across technical layers, deployment roles and stages of operation.

The disclosed controls form a lifecycle inventory

The operational inventory combines established review stages with controls introduced, expanded or strengthened during 2025–2026. It does not present every mechanism as new, and no single item is positioned as sufficient governance for an agent.

• Pre-release review: a central oversight process checks whether identified risks have been addressed before an AI technology is made available. This remains part of the established Govern, Map, Measure and Manage framework.
• Threat mapping: new agentic-AI threat-modeling practices extend risk analysis to interconnected models, tools, services and applications. Related work includes expanded prompt-injection defenses and safety-classifier coverage.
• Identity and permissions: an agent identity establishes the acting principal, while scoped tool permissions constrain available resources and actions. These boundaries become material when one agent connects multiple systems during a multi-step task.
• Memory and changing behavior: retained context is treated as a risk factor because accumulated state can influence later decisions. The disclosure does not define a universal memory-control architecture for every Microsoft agent.
• Evaluation and red teaming: the inventory includes agent evaluators for quality, safety and performance, an AI Red Teaming Agent, and RAMPART, which converts red-team findings into repeatable tests.
• Runtime control: ASSERT and Agent Control Specification are intended to evaluate agents against policy, place controls at consequential workflow points and observe behavior during operation.
• Post-release response: performance signals, user feedback and incidents feed into detection and corrective action after launch, rather than ending governance at the release decision.

This inventory reaches beyond an enterprise IT control plane for agents. Discovery and centralized administration can establish which agents exist, but responsible-AI assurance also requires evidence connecting identity and access boundaries to threat models, evaluations, runtime enforcement and incident response.

Permissions and memory change what reviewers must examine

A bounded model evaluation can test outputs against specified criteria under controlled conditions. An agent introduces additional variables: whose authority it exercises, which tools are connected, what data those tools expose, what prior interactions it retains and which external actions it can complete. A satisfactory test response therefore does not establish that every subsequent tool call will remain within policy.

The revised framework moves the review object toward the full deployment configuration. Permission scope must be assessed against the intended task, controls must operate where consequential actions occur, and retained state must be considered when evaluating behavior over time. It does not establish that every Microsoft agent uses the same permission system, memory design or runtime-control mechanism.

Copilot Cowork is the concrete agentic example in the disclosure. The Microsoft 365 workplace agent combines user approvals, permission-based access, safety guardrails and phased deployment. That case illustrates the intended layering of controls, but it remains a company case study rather than independent evidence covering every workflow, connector or customer configuration.

Deployment becomes part of the governance loop

The new Deployer Chapter applies the standard to third-party AI applications used internally at Microsoft. Its process covers assessment of provider documentation, deployment-specific risk review, safeguards and oversight, information for users, and continuing detection and response. After launch, monitoring is expected to cover performance, feedback and incidents and support corrective action when issues emerge.

For enterprise assurance, the framework creates a more inspectable proposition than a principles-only commitment. An audit could look for an approved agent identity, documented permissions, a threat model, evaluation records, runtime enforcement points, monitoring signals and an accountable response owner. The presence of those artifacts would not by itself prove that the controls work as intended.

The unresolved issue is performance evidence. Microsoft has disclosed the architecture of the revised program and named supporting practices and tools, but the public material does not provide a complete control-by-control audit, universal mitigation results or a timetable showing when every product will satisfy every revised requirement. Product-level evaluations, documented interventions and post-release findings will determine whether the new framework materially changes agent behavior in practice.

Also read:

• Microsoft’s Autonomous Agents Now Have an IT Control Plane
• Microsoft Launches Web IQ: A “Search Engine for AI Agents” Built on Bing
• Obsidian Security Raises $85M as AI Agents Inherit SaaS Permissions