Cybersecurity briefing
/
AI Agents Need Permission for the Next Step
Microsoft's Project Perception shows agent permissions must change mid-task. How to test action sequences before expanding AI access.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
Microsoft's October 19 expansion of Project Perception puts a harder question at the center of enterprise AI security: what should an agent still be allowed to do after its circumstances change? The company announced Dynamic Permissions, Dynamic Agent Risk and Dynamic Conditional Access for agents, describing controls that can narrow authority as work progresses. For businesses connecting AI to everyday applications, the challenge is moving beyond an initial approval to decisions about the next action.
Two allowed actions can create a forbidden outcome
Consider a hypothetical procurement assistant preparing for a supplier negotiation. It can read internal documents and send messages to external contacts. Both capabilities serve legitimate business purposes. Together, they also create a route for confidential information to leave the organization.
The assistant retrieves an internal pricing analysis, then drafts an email to the supplier. The document system can correctly authorize the read, and the mail system can correctly authorize the send. Neither decision, considered alone, establishes that the proposed message is appropriate after the assistant has seen the analysis.
No attacker has to steal a password for this sequence to become risky. An overly helpful agent might include internal negotiating limits in its draft. An instruction embedded in retrieved material could also steer it toward an unrelated recipient. Those are different causes, but both reach the same operational question: does the next action remain within the assignment?
A policy can answer conservatively by restricting external sends after a sensitive read. That can also interrupt legitimate work. The organization must decide whether to require review, produce a separate approved summary or use a different workflow. The control needs an explicit business rule, not an expectation that the model will infer every confidentiality boundary.
A login does not define the whole assignment
Identity controls establish who is acting and which resources that identity may reach. An agent also needs a bounded assignment: the purpose of its work, permitted actions and conditions under which those actions should stop. Giving it an employee's full access can collapse those separate decisions into one broad delegation.
Microsoft's announcement describes task-scoped, time-bound authority and graduated restrictions, including preserving reads while blocking writes. An agent preparing an analysis may still be useful after its ability to send, approve or modify something has been removed.
AI-agent policy gateways provide another place to apply decisions to individual tool calls. Dtwo, a security control plane for agents, sits between an agent and its connected tools and applies allow, deny or redaction policies. Its session-aware controls can use an earlier sensitive read to restrict a later email action. The relevant capability is remembering the governed sequence, rather than judging each request as an isolated event.
That enforcement complements source permissions. It does not replace the identity provider or make an otherwise unauthorized document available. For Microsoft 365, the company's configuration documentation describes a community MCP server running alongside the gateway, with OAuth against the organization's Entra tenant. That is a specific access path, not evidence that every Microsoft 365 interaction automatically receives the same controls.
The route around the control matters
Model Context Protocol, or MCP, gives agents a standard way to invoke tools. A gateway can govern calls routed through it, but an agent may also have a browser, a direct API connection or a separate messaging tool. Blocking one mail tool leaves a gap if another available route can perform the same transfer.
Deployment reviews therefore need to follow the complete workflow. Identify where sensitive information enters, where the agent holds it and every available destination. Remove unnecessary routes or apply equivalent controls. A diagram showing the gateway between two systems is incomplete if the agent retains credentials for a direct connection around it.
Restrictions need a defined session boundary. Teams should test whether restrictions persist across a reconnect, a new conversation, another gateway or concurrent tool calls. They should establish who can clear a restriction and why. A reset that merely removes a marker does not erase information already read or recall a message already sent.
Test the sequence before expanding access
A useful pilot can start with synthetic documents and a harmless external destination. Run the ordinary task, introduce a sensitive read and attempt the restricted follow-on action. Confirm both that the gateway denies it and that the destination receives nothing. Then repeat through alternate tools and session changes.
The evidence should connect the user, agent, session, relevant read, attempted action, policy version and decision. Keep payload collection proportionate: a security log can become another sensitive repository if it retains entire documents unnecessarily.
Successful containment also needs a usable route forward. Employees should understand why an action stopped and how an authorized reviewer can resolve it without handing the agent permanent additional access.
The practical starting point is one valuable workflow with a clear boundary. Define what the agent needs now, which events change that authority and how the restriction will be verified. Enterprise AI can remain productive while its permissions contract. The next step should depend on the work and evidence at hand, not simply on the access granted when the agent started.
