Microsoft announced an expansion of Project Perception on October 19 to govern agents working inside enterprises. Cortist’s assessment: permission boundaries and demonstrable containment deserve as much attention as model capability.
Source checked Oct 20, 2026 · Analysis by Cortist- The announcement concerns internally deployed agents, not just external attackers.
- Microsoft describes authority that changes with a task and its risk.
- The announcement is not an independent demonstration of effectiveness.
The Signal
What Microsoft announced
Microsoft’s October 19 announcement extends Project Perception to enterprise agents. It describes Dynamic Permissions tied to an approved task and duration, Dynamic Agent Risk informed by operational signals, and Dynamic Conditional Access that can narrow access or stop execution. Project Perception and Agent 365 share a registry and context. These are Microsoft’s descriptions of the system, not Cortist test results. [1]
Why Microsoft calls agents insiders
In its companion announcement, Microsoft frames an agent as a combination of model, orchestration, tools and runtime. Its concern is the authority organizations already grant these systems. It advocates controls outside the model and human-defined policy, with Guardian Agents helping supervise activity. The argument concerns operational trust; it does not establish that every agent behaves maliciously. [2]
That distinction changes the useful question for buyers. Asking whether an assistant usually gives sensible answers is insufficient when it can change a repository, update records or initiate a business process. A company also needs a defensible account of who delegated the action, which resources were included and when that delegation ends.
The Shift
A successful answer and an authorized action are different tests
Consider a hypothetical support agent asked to investigate a delayed delivery. Producing a helpful explanation could require reading an order and its shipment status. Issuing a refund or exporting the customer database would be a different class of action. A fluent explanation for taking those steps should not itself grant permission to take them. Product teams can use this distinction to separate assistance from execution before a pilot expands.
This also changes the unit of accountability. A shared account makes it difficult to distinguish a person’s work from several automated jobs acting concurrently. Our recommendation is to define a record for each delegated job: business owner, approved objective, accessible resources, expiry and escalation route. The record should remain useful to someone investigating an incident after the original conversation has disappeared.
Containment has a business cost that must be measured
A control that blocks everything can appear reassuring while making the product unusable. A control that merely produces an alert after an irreversible action offers a different, weaker promise. An evaluation therefore needs two outcomes: how often the system prevents an unauthorized action and how much legitimate work it interrupts. Teams should decide which actions require immediate enforcement and which can tolerate delayed review.
The point is not to maximize approvals. It is to place them at meaningful boundaries. Reading a public document, editing a private draft and changing a production record need different treatment. Requiring the same confirmation for every step can turn review into a reflex. A useful approval should show the exact change, its destination, the authority being used and a clear way to reject it.
The Cortist Lens
Start the pilot with a permission map
Cortist would begin with one bounded workflow rather than an organization-wide autonomy target. List each tool the agent can call, each operation that tool exposes and the data it can reach. Then mark the operations the workflow actually needs. Any remaining permission is a question for the project owner, not an automatic entitlement inherited from the person who installed the agent.
Next, build a small set of representative tasks and controlled failure cases. Include a request that exceeds the approved scope, a stale authorization, a dependency that becomes unavailable and a misleading instruction inside an input document. Run them in an isolated environment using synthetic or approved test data, with a documented expected outcome for every case.
Test the stop path as carefully as the happy path
For a consequential workflow, ask the team to demonstrate what happens after access is withdrawn. Does the next operation fail? Are already queued actions cancelled? Can the process resume with old credentials? The precise answer depends on the implementation. Requiring a recorded demonstration avoids treating a dashboard status as evidence that every execution path has been contained.
Recovery matters too. A partially completed job may leave a draft, a pending transaction or a record in an intermediate state. Assign responsibility for reconciling that state before enabling the workflow. Otherwise the organization may prevent one unsafe action while creating an operational problem that someone must quietly repair later.
Separate architectural intent from procurement evidence
The launch material is a useful statement of direction, but it is not a complete procurement dossier. For the particular components a team plans to use, verify availability, licensing, supported runtimes, enforcement coverage and integration prerequisites directly. Request evidence for the actual workflow, including false blocks and missed events. Cortist has not performed a product evaluation or verified an end-to-end deployment.
A practical AI-agent security evaluation
Cortist’s proposed acceptance criteria. These are questions to test, not claims about measured Microsoft performance.
| Decision | Evidence to request |
|---|---|
| Can we attribute an action? | A task record linking the agent, business owner, approval and resulting change. |
| Can we limit authority? | A demonstration that an out-of-scope operation is refused while permitted work continues. |
| Can we revoke and recover? | A timed revocation test, an inventory of in-flight work and a documented recovery owner. |
| Can the team operate this? | Measured interruption rates, investigation effort and a clear escalation path. |
Questions that matter
Is this a replacement for evaluating the AI model?
No. Output quality and execution authority answer different questions. A capable model can still be given the wrong access, while a tightly restricted agent can still produce a poor answer. A useful pilot checks task quality, permissions and recovery separately before combining them into a deployment decision.
Should every agent action require human approval?
Cortist recommends matching review to consequence. Define a small, explicit set of actions that require a person to inspect the proposed change. Routine operations can remain automated when their scope is clear and enforced. Measure whether reviewers understand the decision rather than merely counting approval clicks.
What evidence is still missing from this analysis?
We have not independently tested the announced controls. A buying decision needs current component-level availability and results from the organization’s own environment. The most useful evidence would show both successful containment and the effect on legitimate tasks, including failures that require human recovery.
Watch for documented availability of the specific controls, reproducible containment demonstrations and customer measurements that include interruption rates. A polished security interface matters less than proof that a prohibited operation cannot pass through an overlooked tool or runtime.
The next useful AI milestone is accountable delegation: a system can do meaningful work, and the organization can demonstrate the boundaries of that work. Project Perception puts that problem on the agenda. Operational evidence will determine how much of the promise holds.
Source & editorial note
Cortist is an early-stage, AI-assisted editorial project. This analysis draws on the primary sources below. The Signal attributes the reporting; The Shift, The Cortist Lens and the practical frameworks contain our interpretation. Company measurements and planned actions remain claims or intentions, not independently verified experimental results.
[1] Microsoft Security · Nadim AbdoAgents are your newest insiders. Security must move at their speed. · Oct 19, 2026[2] Official Microsoft Blog · Hayete GallotSecuring the agentic insider · Oct 19, 2026