Microsoft: authorize agents at runtime

# Microsoft says AI agents need permission checks at the moment they act Microsoft is warning companies not to treat an autonomous artificial intelligence agent like a normal app with a long-lived badge. In a new security post, the company argues that identity and OAuth permissions are no longer enough once software can plan, choose tools, and take actions on its own. (techcommunity.microsoft.com) That warning points to a simple problem. If an agent gets a token at 9:00 a.m. and still holds it at 3:00 p.m., the token says what the app was allowed to do, but not whether this specific action should happen now, for this user, in this situation. (learn.microsoft.com) Microsoft’s answer is “runtime authorization.” The idea is to make a fresh, deterministic decision each time an agent tries to do something sensitive, instead of assuming that a valid identity and a previously granted permission are enough. (techcommunity.microsoft.com) To see why that matters, it helps to separate two ideas that often get blurred together. Authentication is proving who you are, while authorization is deciding what you are allowed to do. (learn.microsoft.com) Traditional software usually follows a familiar pattern. A person signs in, the app gets a token, and that token carries delegated permissions that let the app call an application programming interface on the user’s behalf. (learn.microsoft.com) That model works reasonably well when the software is predictable. A calendar app reads mail, a file app opens documents, and a workflow tool runs a fixed sequence of steps that engineers already defined. (learn.microsoft.com) An autonomous agent changes the shape of the risk. It can read a message, infer a goal, choose a tool, chain several actions together, and keep going without a human approving every step. (cheatsheetseries.owasp.org) That means a permission that looked safe on paper can become dangerous in practice. An agent with access to email, files, or internal systems may combine those powers in ways the original consent screen never really captured. (cheatsheetseries.owasp.org) The security community has been converging on that point. The Open Worldwide Application Security Project says agent systems face risks such as tool abuse, privilege escalation, data exfiltration, memory poisoning, and excessive autonomy that go beyond the older prompt-injection framing. (cheatsheetseries.owasp.org) Microsoft’s own earlier guidance made the same distinction in plainer terms. Large language models can interpret intent, but they do not enforce policy, which is why the company says authorization must sit outside the model rather than inside a prompt. (techcommunity.microsoft.com) In practice, runtime authorization works like a guard at every doorway instead of one guard at the building entrance. When an agent tries to send an email, delete a file, trigger a workflow, or call a protected application programming interface, a separate policy system checks the user, the tool, the target, and the context before the action runs. (opensource.microsoft.com) Microsoft says this check should be deterministic, not conversational. A policy engine should return a clear allow or deny answer based on rules, identity data, and environment signals, rather than asking the model to “be careful” with a natural-language instruction. (opensource.microsoft.com; techcommunity.microsoft.com) The company has been building that argument across several posts, and on April 2, 2026, it released an open-source Agent Governance Toolkit under the MIT license. Microsoft says the toolkit is designed to intercept each agent action before execution and enforce policies with sub-millisecond latency. (opensource.microsoft.com; github.com) Microsoft frames the toolkit as infrastructure, not a chatbot safety layer. The GitHub repository describes it as runtime governance with policy enforcement, zero-trust identity, execution sandboxing, and reliability controls for autonomous agents. (github.com) The timing is not accidental. Microsoft notes that the Open Worldwide Application Security Project published its Top 10 for Agentic Applications for 2026 in December 2025, and the company says the new toolkit is built to cover all 10 categories of risk. (opensource.microsoft.com) The regulatory backdrop is tightening too. Microsoft points to the European Union Artificial Intelligence Act’s high-risk obligations taking effect in August 2026 and the Colorado Artificial Intelligence Act becoming enforceable in June 2026. (opensource.microsoft.com) For companies already deploying agents inside Microsoft environments, the immediate lesson is narrower than “buy a new tool.” Microsoft’s core recommendation is architectural: the agent should never be the component that decides whether it is allowed to act. (techcommunity.microsoft.com) That changes how developers should think about delegated permissions. Microsoft’s identity platform still supports delegated access, where both the client app and the signed-in user must be authorized separately, but that is only the starting point for an agent that can make its own intermediate decisions. (learn.microsoft.com) The old assumption was that least privilege at setup time would contain the risk. Microsoft is saying setup-time permissions need a second layer that evaluates each live action against current context, because the same credential can be harmless in one moment and dangerous in the next. (learn.microsoft.com; techcommunity.microsoft.com) That is the heart of the story. Artificial intelligence agents are being treated less like passive software and more like junior operators, and Microsoft is arguing that junior operators need a supervisor at the moment they touch something important, not just a badge issued earlier in the day. (opensource.microsoft.com; techcommunity.microsoft.com)