Microsoft is redesigning its responsible-AI governance around software that can remember information, use tools, access data, and take actions, shifting part of enterprise risk management from checking what a model says towards controlling what an AI system is permitted to do.

Microsoft has re-engineered its Responsible AI Standard so requirements are organised around three parts of the technology stack — models, platform services, and applications — with additional controls applied according to the company’s role and the risks presented by a particular system.

The changes are set out in Microsoft’s 2026 Responsible AI Transparency Report, published on 1 September. Agent identities, tool permissions, action monitoring, and controls applied while software is running are taking a larger role as systems move beyond generating answers and begin interacting with applications, databases, and business processes.

That distinction becomes substantial for organisations deploying agentic software because conventional AI governance has often concentrated on evaluations before release. An agent can behave acceptably during an initial test and later produce a harmful result if its permissions change, a connected tool behaves differently, external data is manipulated, or a sequence of individually reasonable actions produces an unintended outcome.

Microsoft’s revised standard combines baseline requirements with targeted controls that can change as technical capabilities and risks develop. The company says some of its strongest measures are applied to systems with substantial cyber capabilities, while engineers and product managers are being trained in areas including agent threat modelling and prompt-injection defence.

Permissions become part of AI safety

Once an AI system can take action, identity and access management become part of the safety architecture rather than a separate enterprise-security concern. An agent that can read documents, send messages, modify records, run code, or trigger financial workflows needs an identity that can be authenticated, permissions that can be constrained, and an audit trail showing what it attempted to do.

Microsoft’s report consequently moves beyond evaluating the output of an individual model. It describes governance across interactions between models, agents, applications, tools, data, and people, where risk can emerge from connections between components that may each be legitimate in isolation.

The approach resembles established security principles such as least privilege and separation of duties. Employees usually receive only the system access needed for a role; autonomous software needs comparable limits if it is being given the ability to operate on an employee’s or organisation’s behalf.

The difference is speed and reach. An agent can potentially work across several systems in seconds, amplifying the effect of an over-broad permission or malicious instruction. Prompt injection becomes more serious when manipulated content does not merely change an answer but causes software to retrieve confidential data or invoke a connected tool.

Governance moves into the runtime

Microsoft has built several tools around that operating model. ASSERT and its Agent Control Specification are intended to let developers evaluate agents against organisational policies, insert controls at particular stages in a workflow, and monitor behaviour while applications are operating.

The company has also introduced an AI Red Teaming Agent intended to accelerate adversarial testing, alongside evaluators covering safety, quality, and performance. Another system, RAMPART, converts findings from red-team work into repeatable tests so previously discovered weaknesses can be checked again as software changes.

Those mechanisms reflect a familiar software-engineering problem: a security assessment performed on one release provides limited assurance after the product, dependencies, configuration, or operating environment changes. Agentic applications add further volatility because behaviour may depend on tools and external data that evolve independently of the underlying model.

Microsoft says “governance needs to become more operational”, placing enforcement closer to engineering and system administration. That is a different proposition from publishing a set of responsible-AI principles that engineers interpret manually because policy has to be represented inside identities, permissions, tests, monitoring systems, and deployment processes.

Responsibility also does not remain with the model supplier. An organisation connecting an agent to its customer database, finance system, code repository, or HR platform determines much of the environment in which the system operates, including the permissions granted and the consequences of an erroneous action.

Agentic AI becomes a systems problem

That shared responsibility complicates procurement because buyers evaluating an AI assistant can compare model performance and contractual terms, whereas an agentic deployment also requires examination of authentication, logging, tool access, isolation, override mechanisms, data retention, monitoring, and failure handling.

Those controls cross several organisational boundaries. AI governance, cybersecurity, engineering, data management, compliance, and application ownership can each govern different parts of one workflow, allowing a system to pass a model assessment while remaining poorly controlled at application level.

Microsoft’s decision to organise its standard around models, platforms, and applications recognises that separation. A foundation-model provider has different responsibilities from a platform exposing models through developer tools, while the organisation building the final application controls the use case, connected data, permissions, and business process.

The company is also attempting to turn parts of its internal assurance work into standards and tooling that travel beyond Microsoft, citing work with organisations including OpenTelemetry, MLCommons, the Frontier Model Forum, and national AI safety and security bodies.

Microsoft says it holds ISO 42001 certification across a portfolio that includes Microsoft 365 Copilot, Foundry, and GitHub Copilot. Certification can demonstrate that an AI management system exists and is applied consistently, although it cannot establish that every customer deployment is safely designed or correctly configured.

Regulation is moving in the same direction

The technical changes arrive while regulators seek more evidence about how AI is governed after it leaves development environments. European rules increasingly require organisations to document risk controls, logging, human oversight, robustness, and cybersecurity around systems falling within defined regulatory categories.

Agentic applications make those expectations harder to reduce to a single compliance exercise because behaviour can depend on a changing environment. Organisations may need to demonstrate not only that a model was evaluated but that permissions, monitoring, and controls continue to function as the application acquires new capabilities or connections.

Microsoft’s revised framework is therefore more useful as an indication of where technical governance is heading than as another statement of responsible-AI principles. Identity, permissions, runtime enforcement, repeated testing, and observability are becoming ordinary parts of the stack as AI acquires the authority to perform work rather than merely recommend it.

The commercial attraction of agents rests heavily on that authority because software saves more labour when it can finish a process rather than prepare instructions for a person to complete. Every additional action, however, creates another point at which governance has to be executable, observable, and capable of stopping the system when its behaviour departs from what the organisation intended.