The agent inside the company
Microsoft is extending Project Perception to supervise AI agents operating within organisations, according to two company announcements published on 19 October. The focus is software that already has permission to use business tools, rather than only attackers trying to break in.
Hayete Gallot, Microsoft’s executive vice president for security, describes a system that continually reassesses risk and adjusts an agent’s ability to act. Microsoft says teams of Guardian Agents will help supervise activity. The company first introduced Project Perception in July, when it announced an August public-preview date. This is a new application of that initiative, not its first announcement.
Access should be narrower than the employee’s
The accompanying technical announcement describes Dynamic Permissions: authority limited to a task and a period of time. It also introduces Dynamic Agent Risk and Dynamic Conditional Access, intended to change access as the assessed risk changes.
Microsoft’s stated responses include allowing an agent to keep reading while stopping it from making changes, requiring human approval for consequential steps, or isolating and stopping it. These are announced capabilities and design claims, not SIGNAL test results.
In plain English, intelligence and permission answer different questions. A model may work out how to complete a task. A separate control decides whether it is allowed to carry out each proposed action. Asking the model to promise good behaviour does not establish that boundary.
Why this matters outside the security team
Consider a hypothetical assistant preparing a customer report. Reading the relevant records is useful. Deleting those records or sending them to an unrelated recipient is a different kind of authority. A system that grants all three powers together makes a small misunderstanding potentially much more consequential.
The practical lesson is to examine the powers attached to a workflow, not just the quality of its answers. Where can the assistant read? What can it change? Which action requires a person? Can that permission be withdrawn while other safe work continues? These are questions for evaluating a deployment, not a finding about any particular customer’s configuration.
For employees, this could also make responsibility clearer. The person authorising a useful task need not be treated as having authorised every possible action available to the software. That distinction depends on the controls actually enforcing the agreed limits.
What the announcement does not settle
Microsoft is both the source of these announcements and the vendor of the proposed security system. SIGNAL has not tested the new controls, measured missed detections or confirmed customer-specific availability, licensing and coverage. The material reviewed does not establish that every application or every agent can be contained equally well.
The engineering challenge is not merely spotting suspicious behaviour. A control must act before an irreversible change, work across the tools in use, and leave a record that a person can understand. Excessive blocking can also interrupt legitimate work. Independent evaluations should examine both unwanted actions that get through and useful actions incorrectly stopped.
What matters next is evidence of those boundaries working in real deployments. A more transparent model can provide useful clues, but the final permission decision still needs an enforcement mechanism beyond the model’s own assurance.