How should permissions, credentials, memory, tool access, network access, and spending authority be constrained?
Least-privilege design for agents is being invented ad hoc by industry, ahead of any standard. Visibility infrastructure — agent identifiers, activity logs — is the governance-side counterpart.
View on the map → · Open in Browse →
The permissioning question is being answered in production. Anthropic published its containment architecture — supervise what an agent is able to do, not what it does, via sandboxes, sealed VMs, and deterministic egress controls, with credentials kept out of the guest — and Microsoft's counterpart guidance argues for treating every agent as a first-class principal with a lifecycle-managed identity and tightly scoped, just-in-time permissions.
Rather than supervising what the agent does, we supervise what it's able to do by enforcing access boundaries through, for example, sandboxes, virtual machines, and egress controls.
The clearest published least-privilege agent architecture from a frontier lab: three isolation patterns, credentials kept out of the guest, and deterministic egress controls as the boundary that catches probabilistic failures.
The right mental model is to treat every agent as a first-class principal: give it a lifecycle-managed identity, assign explicit roles, scope its permissions tightly.
Enterprise guidance on the governance-side counterpart to containment: dedicated agent identities, task-scoped RBAC, tool allowlists, just-in-time elevation, and audit logging as infrastructure.