Least privilege for AI agents: Identity, access, and tool binding

A Microsoft Security Blog post arguing that AI agents — now planning, chaining actions across systems, and invoking tools autonomously — need managed identities and least-privilege access controls, not the ad-hoc permissions they typically inherit during development.

The authors identify a common failure pattern: agents provisioned with broad "Reader" roles for pilot use cases, then quietly granted wider permissions as workflows expand, without anyone revisiting the accumulated scope. They also flag the "identity ambiguity" problem — teams don't know whether an agent acts under its own identity, a delegated user scope, or a mix, which makes incident investigations stall even when logs exist.

Four pillars make up the recommended framework: (1) a dedicated agent principal with lifecycle management and fast shutdown; (2) task-based RBAC designed around discrete actions, not org charts; (3) multi-layered scoping — resource, data, and operation boundaries — with curated tool allowlists and JIT entitlements that drop back after workflow completion; (4) end-to-end auditability where downstream tools re-check claims on every call, and logs capture agent identity, role, scope, resource, action, and correlation IDs.

Common pitfalls include shared secrets across agents, relying on prompt guardrails instead of hard authorization boundaries, and temporary access that never expires. The authors recommend an immediate 30–90 day inventory of agent identities, removal of broad roles, and task-scoped RBAC rollout before expanding deployments.