Agent Risk Score
Beak sees how an agent actually behaves — every moderated request, every blocked tool call, every red-team finding. Microsoft decides what an agent is allowed to reach. The Agent Risk Score connects the two: Beak reduces everything it knows about a governed agent to a single 0-100 number, and writes that number onto the agent's Entra service principal, where a Conditional Access policy can act on it.
Before this, a violation changed nothing outside Beak. An agent could be blocked repeatedly and keep exactly the access it started with.
Find it under Configure → Agent Risk Score. One agent's score, its band and the full factor breakdown also appear in the How risky section of that agent's Agent Passport, beside its authority and its recorded activity — with an explicit note on the dimensions this model does not measure.
How the score is built
Six independent signals, each scored 0-100 on its own terms and then weighted into the total. Higher is riskier.
| Signal | Weight | What it measures |
|---|---|---|
| Policy violations | 30% | Blocked, redacted and warned requests from the moderation audit trail |
| Entra risk | 20% | Microsoft's own risk verdict for the agent identity |
| Attribute probing | 15% | Refused attempts by the agent to write its own risk attributes |
| Red team | 15% | Severity-weighted failures from its most recent completed campaign |
| Reliability | 10% | Circuit-breaker trips and detected hallucinations |
| Configuration | 10% | Suspended state, missing signing key, attestation off, broad scopes |
Three properties of the model are worth understanding before you write a policy against it.
Violations decay. Evidence is weighted by age with a seven-day half-life over a 30-day window. A block last Tuesday counts for more than a block three weeks ago, and an agent that stops misbehaving drifts back down. Without decay a score could only ever rise until events fell off the window edge, which arrives as a cliff rather than a recovery.
Evidence accumulates, but saturates. The first serious violation moves the score the most. A bad afternoon does not pin an agent at 100 and leave the factor unable to distinguish bad from catastrophic ever again.
A signal with no evidence is not scored as zero. An agent with no Agent 365 identity has no Entra verdict; an agent that has never been red-teamed has no attack results. Beak marks those factors unknown and redistributes their weight across the signals it does have. This matters more than it sounds: if absence scored as zero, a never-tested agent would rank below an identical agent that was attacked and held — and the safest-looking agent in your console would be the one nobody had ever examined.
The detail panel shows an evidence coverage percentage for exactly this reason. A score built from two of six signals is a weaker claim than one built from six, and you should be able to see which you have before acting on it.
Bands
| Band | Score |
|---|---|
| Low | 0-24 |
| Medium | 25-49 |
| High | 50-74 |
| Critical | 75-100 |
Bands are tenant-wide, not per-agent. One Conditional Access rule has to mean the same thing for every agent it targets.
What gets written to Agent 365
For every governed agent linked to an Entra service principal, Beak writes up to three custom security attributes, in the attribute set and name prefix configured on the Microsoft Agent 365 integration:
| Attribute | Example | Purpose |
|---|---|---|
beakRiskScore | 072 | The score, zero-padded to three digits |
beakRiskBand | high | The band — the attribute your policy should target |
beakRiskUpdated | 2026-08-17T09:14:22+00:00 | When Beak last wrote it |
Target the band, not the score
This is the single most important thing on this page.
Conditional Access can only filter on string-typed custom security attributes, so any comparison it makes is a string comparison. A policy phrased as "block when beakRiskScore is greater than 50" compares text, and in text "9" sorts above "72". Written that way, the policy would match your single-digit — safest — agents and exclude everything else. Nothing errors: the write succeeds, the portal shows the attribute, and the policy simply protects the wrong agents.
Two things guard against this:
- Beak zero-pads the score to three digits, so
"009" < "072" < "100"sorts the way you expect. - Beak also publishes
beakRiskBand, which turns a threshold into an equality match — the comparison string filters actually do well.
Write your policy against beakRiskBand where you can. Use beakRiskScore for reporting and for reading an agent's position within a band.
Warning: Once a Conditional Access policy filters on these attributes, Beak raising an agent's band is Microsoft revoking that agent's access. Enable the sync deliberately, and test with a policy in report-only mode first.
Enabling the sync
Under Configure → Agent Risk Score → Sync settings.
The sync is off by default. Beak scores every governed agent regardless — the scores are visible in the console — but nothing is written to Entra until you turn it on. That default is a safety decision, not a preference: the authority to change what Microsoft allows should be granted, not inherited by upgrading the service.
- Configure the Microsoft Agent 365 integration first. The risk settings are stored with that credential, so there is nowhere to save them until it exists.
- Grant the Entra application
CustomSecAttributeAssignment.ReadWrite.Alland assign it the Attribute Assignment Administrator directory role. The permission alone is not enough — without the role every write fails with a 403. - Turn on Write risk attributes to Agent 365.
- Choose which attributes to push, and the recompute interval.
Choosing which attributes to push
Each attribute has its own checkbox, labelled with the resolved name as it appears in the Entra portal — beakRiskScore on a default tenant, contosoRiskScore on a tenant that has customised the property prefix.
You might not want all three. The score and the band are the same judgement at two resolutions, so an estate whose policies are written against the band has no use for the number. Deselecting is also how you stop writing an attribute that some other system in your tenant has started to read.
Note: Deselecting an attribute stops Beak maintaining it. The value already on the service principal is left in place, not deleted — removing it could break a Conditional Access policy still reading it. So it persists, frozen at its last value. The agent's detail panel marks such attributes
no longer maintainedso a stale value is not mistaken for a current one. Delete it in Entra if you want it gone.
An empty selection is rejected. The switch is how the sync is turned off; an empty set would be a second, silent off switch that looked like a misconfiguration.
When scores are pushed
Two triggers, working together:
- On an interval (default hourly, configurable) every governed agent is rescored, and anything whose value moved is pushed. This is also the only path by which a score comes down: nothing happens when an agent stops misbehaving, so without a periodic recomputation a score could rise but never fall.
- Immediately — within seconds — when a violation moves an agent across a band boundary. A score change inside a band is left for the next interval, because it changes nothing Conditional Access can act on.
A burst of violations from one agent produces one recomputation and one write, not one per event.
Reading a score
The Scores tab lists every scored agent, riskiest first, with server-side search, a band filter, sorting, a column picker, and CSV and PDF export that match the filters you have applied rather than the page on screen.
Select an agent for the detail panel, which shows three values separately because they can legitimately disagree — and the disagreement is the useful part:
| Meaning | |
|---|---|
| Beak's score | What the evidence says right now |
| Last synced | What Beak believes it last told Entra |
| On the service principal | What Entra actually holds — what a Conditional Access policy will evaluate |
If a push failed, the first two agree and the third is stale, which means Conditional Access is deciding on a value nobody is looking at. The panel says so plainly, and the list marks each agent as in sync, stale, pending, failed or not linked.
An agent showing not linked has no Entra service principal, so there is nothing to write to. Onboard it from the Microsoft Agent 365 page if you want Conditional Access to see its score.
The panel also breaks the score down factor by factor, with the evidence behind each one — 3 blocks in 6 days, 1 refused attribute write, never red-teamed. A governance score that cannot be decomposed is not defensible evidence, so anything you can act on, you can also explain.
Recomputing on demand
With the agents:update permission the detail panel offers:
- Recompute & sync — rescore now and push the result.
- Recompute only — rescore without telling Microsoft. Use this to see what a score would be before enabling the sync on a tenant whose Conditional Access policies are already live.
Permissions
| Action | Permission |
|---|---|
| View scores, breakdowns and settings | agents:read |
| Recompute an agent's score | agents:update |
| Change the sync switch, cadence or attribute selection | integrations:update |
Every write to Agent 365 — including automated ones, recorded against a system actor — appears in the property-write audit on the Microsoft Agent 365 page, together with the value it replaced. Refused writes are recorded too: an agent repeatedly trying to lower its own risk score is exactly what that trail exists to preserve, and it feeds the Attribute probing signal in the score itself.
Best Practices
- Write your Conditional Access policy against
beakRiskBand, notbeakRiskScore. A string filter does equality well and comparison badly. A threshold against the score is compared as text, and no error tells you it matched the wrong agents. - Turn the sync on before you write the policy, not after. Let one interval pass, confirm in Entra that the attributes landed on the service principal and are string-typed, then build the policy. The reverse order means your first test of the policy is also your first test of the write.
- Run the policy in report-only mode first. The score is derived from behaviour, so its first few days on a new tenant are also when it is least understood. Report-only tells you who would have been blocked while nobody is.
- Read the coverage percentage before acting on a score. A score built from two of six signals is a weaker claim than one built from six. Low coverage usually means the agent is new, has never been red-teamed, or the Entra risk permission was never granted.
- Treat
staleandfailedas operational alerts, not cosmetic states. Both mean Conditional Access is enforcing on a value that is not the current one. A persistentfailedis almost always the missing Attribute Assignment Administrator role. - Red-team your agents so the signal has something to say. A never-tested agent's score is built from five signals instead of six. Testing does not only find problems — it also lets a well-behaved agent demonstrate that it holds.
- Do not tune around a score you disagree with. The weights are fixed deliberately so a score means the same thing across tenants and can be compared and defended. If a score looks wrong, read the breakdown — it names the evidence.