The previous article in this series argued that the combination of incremental and dynamic user consent and Microsoft Entra Agent ID gives interactive AI agents something genuinely new: the ability to earn their access in the wild, scope by scope, prompted by the humans and other agents they work alongside. Aria, the example agent, started with two delegated permissions and grew into a productive contributor across SharePoint, ServiceNow, and the Finance API in roughly a quarter — without its creators pre-declaring any of it.

That was the optimistic half. This is the other half.

By the end of that quarter, Aria is — by any reasonable measurement — the most over-privileged identity in the tenant. No one noticed, because there was nothing to notice. Every grant was legitimate, contextual, and user-approved. The risk did not arrive in a single bad decision. It arrived as a hundred reasonable yeses.

A different kind of over-permissioning

Classic over-permissioning is an event. Someone hands a service account Directory.ReadWrite.All because the deployment was due Friday, an auditor flags it months later, a ticket is opened. Slow, but the control loop exists, and it is built around discrete moments of poor judgment.

Permission accumulation through dynamic consent is structurally different. There is no single bad decision to find. The permission graph grows monotonically — one narrow, well-justified scope at a time — because the mechanism that makes the agent useful is the same mechanism that makes it dangerous. Nothing in the platform prunes that graph by default, and nothing in most organizations does either: access-review tooling was designed around human role changes, not around agents whose role is to absorb new capabilities.

Why agents become the target

A compromised agent identity is qualitatively worse than a compromised user account, and the reasons are worth stating plainly.

A user holds permissions scattered across teams, sick days, role changes, and eventual departures. Their access constantly churns, and the blast radius of any single compromise is naturally bounded by the messiness of human work.

An agent does none of that. It persists. It centralizes. Every scope a hundred different users granted to it is reachable through one set of tokens, one blueprint, one set of credentials issued by that blueprint. Add the realistic threat surface of a modern agent — token theft, blueprint compromise, prompt injection used as a lateral-movement primitive — and the picture becomes uncomfortable: the most attractive principal in the tenant is also the one whose authority grew quietly enough to escape notice.

What the SOC must change

Most security operations centers treat sign-in logs as the primary identity signal. For agents under dynamic consent, that is no longer sufficient. The consent log itself becomes a first-class detection surface.

Three signal families deserve attention:

• Scope-acquisition velocity. A productive agent acquires new scopes in bursts that follow human work. An agent that suddenly requests broad scopes — especially ones approaching admin-consent thresholds — outside its normal pattern is worth waking someone up for.
• Grant-versus-use gap. Scopes that were granted but are never exercised are dead weight at best, pre-positioned capability for an attacker at worst. Track them, and feed the gap into automated revocation.
• Introduction chains. When agent A pulls agent B into a workflow and B requests new scopes as a result, that chain is part of the audit story. SOC tooling needs to render it as a graph, not as isolated events.

None of these are exotic. They are sign-in analytics one layer up the stack.

What in identity governance must change

Access reviews built for humans assume a relatively stable role. The reviewer is asked, in effect, "does this person still need what they had last quarter?" That question does not work for an agent whose entire purpose is to absorb new capabilities continuously.

Three adjustments are required.

Reviews keyed to recent use, not recent grant. The relevant question is no longer "should the agent have this scope?" but "did the agent actually exercise this scope in the last N days, and was the use consistent with the original justification?" Scopes that fail both halves of that test should expire automatically.

Owners and sponsors as the accountable humans. Microsoft Entra Agent ID separates technical owners from business sponsors precisely so that someone with operational context and someone with business context can both be on the hook. Wire those roles into the review workflow. An agent without a current sponsor should not be holding sensitive delegated permissions.

Blueprint-level Conditional Access as the choke point. Because policies applied to a blueprint propagate to every agent identity created from it, the blueprint is the right place to enforce the constraints that should never be negotiable — geographic boundaries, sensitive-resource exclusions, step-up requirements for specific scope families. Treat the blueprint the way you treat a privileged-access workstation: small, hardened, watched.

A governance posture that grows with the agent

Three principles are worth taking back to the architecture board.

Consent is telemetry. Treat every dynamic consent event as a security signal of equal weight to a sign-in. Pipe it into the same analytics and the same review workflows.

Least privilege is a verb, not a noun. A static least-privilege list cannot survive contact with an agent that earns its access. The control objective is no longer to define the minimum scope set — it is to continuously prune toward it.

Grow with the agent; do not be the hurdle. The organizations that succeed will be the ones whose governance moves at the same cadence as the agent's learning. Quarterly reviews and annual recertifications were already too slow for humans. They are unworkable for agents.

Aria is going to keep growing. So will every other interactive agent in the tenant. The question for identity and security architects is not whether to allow it — that decision has already been made by the people on the other side of the chat window. The question is whether the controls, the detections, and the operating model are ready for what dynamic consent has quietly enabled.

If they are not yet, that is the work for this year.