Microsoft announced on 19 October 2026 that an agent's permissions will now shrink as a continuously computed risk score rises — write access withdrawn while reads continue, data narrowed, a human put in front of the next step, the runtime stopped. The containment is genuinely better than a standing grant, and it costs you the one artifact every review of an agent incident depends on: a grant is a durable object you can read before anything happens, and a score is only visible after it moves. If you adopt this, the score and its inputs become the thing you have to log alongside every decision, because nothing else in the model records why the agent could write at 14:05 and could not at 14:35.
At a glance
What the launch coverage establishes, and how firmly.
| Feature | What it does | Confidence |
|---|---|---|
| Dynamic Permissions | No standing access; an agent gets what one task needs, for as long as that task runs, capped by the authority of the person it works for | Consistent across outlets |
| Dynamic Agent Risk | A continuously updated per-agent score drawing on identity, data, device, cloud, network and the agent's own actions | Consistent |
| Dynamic Conditional Access | Graduated response as the score climbs: lose write and keep read, lose some data, require human approval, be stopped | Consistent |
| Guardian Agents | Agents that investigate when risk shifts and can recommend or apply containment themselves | Consistent, vendor-stated |
| Local agent discovery | 60 agent types detectable on employee machines, Claude Code, OpenAI Codex and GitHub Copilot among them | Prior figure conflicts: 25 or 35 |
| Packaging | Bundled into Microsoft 365 E7 at $99 per user per month | Single-outlet detail |
| How the score is computed | Six named signal domains; no published weighting, threshold or replay mechanism | Unestablished |
Everything below is read off launch coverage and Microsoft's own security blog post of the same date, not from hands-on use. That matters most for the bottom row: every outlet names the six signal domains and none describes how the score is weighted, where the bands sit, or whether a score from last Tuesday can be recovered.
A grant is an object; a score is an event
Standing access is bad for blast radius and good for evidence, and the industry has spent two years correctly attacking the first half of that sentence. A grant in a directory is a row: it exists before the agent acts, it can be read by somebody who is not the agent, it produces the same answer on Tuesday as on Thursday, and when an incident review asks what the agent was allowed to do, the answer is a lookup. That reviewability is not a nice property of grants; it is the entire basis of the access review, which is why reviewing agent credentials is a tractable exercise at all.
Replace the grant with a score and all four properties invert. The authority exists only while a task runs, so there is no row to read in advance. It is computed, not declared, so the only party that can state it is the scorer. It is not stable, so two identical requests legitimately get different answers. And the question an incident review actually asks — not "what was this agent allowed to do" but "why was this specific action allowed" — now has an answer that was never written down, because the deciding input was a number that existed for a few seconds inside somebody else's control plane.
This is not an argument for standing grants. Per-task authority bounded by the delegating human is the right design, and it is the half of the announcement that needs no caveat. The argument is that the evidence does not come along for free: moving from declared to computed authority moves your audit object from the directory to the telemetry, and almost nobody has noticed they need to go get it.
Six signal domains means one vendor's view of the truth
The six inputs — identity, data, device, cloud, network, and the agent's own behaviour — are the interesting disclosure, and not for the reason the press release intends. Read as a product claim it says the score is well-informed. Read as an architecture statement it says the score is only computable inside an estate that observes all six, which in practice means one suite. An agent that lives half in that suite and half outside it does not get a worse score; it gets a score computed from the half that is visible, which is a different and more dangerous failure, because the number arrives with no confidence interval attached.
That is the same structural problem that discovery produced last month in a different costume, and it has a mechanical consequence worth stating plainly: a throttle driven by behavioural signals inherits every blind spot of the telemetry it reads. The signals that discriminate for agents are the shape of the trajectory rather than the content of any one call — see detecting agent compromise for which ones actually earn their keep — and the trajectory of an agent that calls three SaaS APIs you do not front is simply absent from the score that governs it.
The question to ask before you turn it on: which way does it fail?
Graduated response introduces a dependency nobody budgets for. A static policy has a failure mode you chose: when the policy engine is unreachable, you decided in advance whether the call proceeds or is refused, and fail-closed versus fail-open is a design decision with a name. A scored throttle has a failure mode that falls out of implementation details: if the scorer is degraded and returns stale values, agents keep the authority their last good score bought them; if it returns nothing and the policy treats absence as low risk, every agent is promoted at once, silently, at the worst possible moment.
None of the coverage says which way this one fails, and it is the first question to put to the vendor. The second is whether an administrator can see the current score and the inputs that moved it. A control you cannot observe is not a control you can operate — and with Guardian Agents able to apply containment themselves, you now have a system that can withdraw an agent's write access for reasons no human has read.
Three things to log on every allowed and every refused action from day one: the score at decision time, the band it fell in, and the policy version that mapped band to permission. Two of the three are typically available and none is retained by default. Without them your audit trail records what happened and loses the only field that explains it.
Priced per human, scaled per agent
One outlet puts the whole stack inside Microsoft 365 E7 at $99 per user per month, bundling E5, Copilot, the Entra Suite and Agent 365. If that holds, the containment layer is priced per human exactly as Agent 365 priced governance per human in August, and the objection is the same one, now with more at stake. Agent risk does not scale with headcount. It scales with the number of agent instances holding credentials, and the deployments that most need per-task authority and a live risk score are precisely the ones where agents outnumber the people who launched them by an order of magnitude.
The practical effect is a coverage gap shaped like your own success. A team of eight running two hundred scheduled agents pays for eight seats and needs two hundred scored identities; whether that works is a licensing question, not a security one, and it is worth settling before the architecture review rather than after. Note also what per-seat pricing does to the incentive at the edges: the agents least likely to be enrolled are the ones running on a contractor's laptop or in a CI job that belongs to no seat, and those are not the low-risk tail.
The floor is still enrolment, and the floor is a list
Sixty detectable agent types is a real improvement over any number smaller than sixty, and it is a list of known binaries. An agent gets an identity, a score and a throttle if something recognised it; a Python script with an API key and a loop is an agent by every definition that matters and by no definition a scanner can match. The announcement is honest about the direction here — giving unknown agents their own identities is explicitly part of it — but the detection surface is still signature-shaped, and signature-shaped coverage of a population that anyone can add to in an afternoon has a known shape of hole.
This is why the ambient authority framing stays the one to reason from. The agents that cause incidents are usually not the ones with a product name; they are the ones that inherited a human's session, a shared service account, or a token that outlived the task. A score attached to enrolled agents does nothing about an unenrolled process acting with a credential it found, and the remedy for that has not changed: shorten credential lifetime and put the authority in the task, which — to Microsoft's credit — is the other half of what shipped.
What to actually do with this
| If you… | Adopt | And insist on |
|---|---|---|
| Run agents inside one suite, with standing service-account grants today | Dynamic Permissions first; it strictly dominates what you have | Score, band and policy version written into your own log, not the vendor's |
| Run agents across several clouds and SaaS vendors | The per-task authority; treat the score as partial by construction | A documented answer to what the score does when a signal domain goes dark |
| Have an auditor, a regulator or a contestable decision in scope | Nothing until you can replay a past decision | Score retention long enough to cover your own review window |
| Run mostly unenrolled agents — scripts, CI jobs, workstation tools | Discovery, and expect the inventory gap to be the finding | A plan for the processes no scanner names |
The durable practice underneath the product is worth separating from the product, because every major vendor will ship a version of this within two quarters and the operational work is the same in each: pick your own bands, log the score with the decision, and test the scorer's absence before you test its accuracy. We wrote that up as risk-scored permissions, which is the runbook this post is the news story for.
FAQ
Is a risk-scored throttle better than a standing grant?
For containment, clearly yes: it removes standing authority and shrinks what a compromised agent can reach. For evidence, clearly no: it replaces a reviewable object with a transient number. Both are true at once, and the second one is fixable by logging while the first is not fixable at all with grants.
Can I see the score that blocked an action?
Nothing in the launch coverage says. Treat it as the gating question for adoption rather than a detail to settle later — a decision whose deciding input you cannot retrieve is not auditable, however good the decision was.
Does this stop prompt injection?
No, and it is not sold as doing so. It reduces what a successfully injected agent can do next, which is the right place to spend effort, but the injection still lands. The structural defence remains breaking the combination of private data, untrusted content and an outbound channel — see the lethal trifecta.
What happens when the risk scorer is unavailable?
Unstated, and the two plausible behaviours are opposite: stale scores preserve whatever authority agents last earned, while a missing score treated as low risk promotes every agent simultaneously. Ask, and write the answer into your runbook.
Does per-seat pricing actually matter for security?
It decides coverage. If scored identities are bounded by seats, the agents outside a seat — contractor machines, CI jobs, scheduled runs — are the ones left unscored, and they are not the benign tail of the distribution.
Further reading
On this wiki:
- Risk-Scored Permissions — the vendor-neutral runbook: bands, logging, and testing the scorer's absence.
- Agent Identity & Permissions — why identity and authorization are separate questions for agents.
- Decision Receipts & Audit — writing the authority record at the moment of the act.
- Progressive Autonomy — the human-facing version of a graduated ladder, and why demotion must be automatic.
- Discovery is not an inventory — the gap between what you detect and what you register.
Sources:
- Microsoft Security blog, 19 October 2026 — the primary announcement.
- SiliconANGLE and The Next Web — feature detail and packaging.