Least privilege is the principle that any identity, human or automated, should hold only the permissions required to complete its assigned task, for only as long as that task requires. For human users and traditional service accounts, this maps cleanly onto identity platforms like AWS IAM and Microsoft Entra: an administrator grants a role or policy, the identity authenticates, and the granted permissions remain relatively static until reviewed.
AI agents complicate this model. A single agent session can chain multiple tool calls, API requests, and reasoning steps, each representing a distinct decision point about what the agent should be allowed to do next. These decision points occur between the moment an execution role is granted and the moment the session ends, a window that traditional IAM and identity platforms were not built to evaluate at that granularity. Understanding where each platform actually enforces permissions, at role assignment, at authentication, or at the point of each tool call, is the basis for comparing these approaches.
Where Each Platform Enforces Least Privilege
AWS IAM: Identity-Time Permission Grants for Bedrock Agents
Amazon Bedrock Agents rely on IAM execution roles and resource-based policies to define which AWS resources and action groups an agent's underlying functions can invoke. These permissions are set at configuration time: an administrator defines the action groups the agent can use, and the execution role determines the outer boundary of what those actions may touch. IAM policy evaluation occurs per AWS API request, so access checks are tied to discrete service calls rather than to the internal reasoning steps an agent takes between those calls.
AWS has extended this model with Amazon Bedrock AgentCore, which includes an Identity capability for managing workload identities and token-based authorization when agents call external tools and APIs. This addresses how an agent authenticates to external systems, but published documentation describes token issuance and workload identity management rather than a decision engine that evaluates the intent of a specific tool call in progress. In practice, teams scoping Bedrock Agents for least privilege must size the execution role broadly enough to cover every anticipated action group, which can work against strict least-privilege goals for agents that follow varied, multi-step workflows.
Microsoft Entra: Session-Level Identity Controls for Agents
Microsoft Entra Agent ID assigns AI agents, including those built with Copilot Studio and Azure AI Foundry, a unique identity object within Microsoft Entra ID. This gives agents a first-class identity distinct from a shared service principal, supporting more precise assignment of conditional access policies and lifecycle management. Conditional access in Entra is enforced at sign-in and token issuance: policies evaluate conditions before or at session start and determine whether a token is issued and what it authorizes.
That enforcement point means Entra's controls apply once, at the beginning of a session, rather than continuously against each action the agent takes afterward. For agents built outside Microsoft's first-party tooling, adopting Entra Agent ID also requires integration work to register the agent as an identity object. Organizations running agents across both AWS and Microsoft ecosystems will need to reconcile two separate agent-identity models, since neither is currently positioned as a cross-cloud enforcement layer.
The Gap Between Identity Issuance and Runtime Behavior
Both AWS IAM and Microsoft Entra enforce least privilege primarily at two moments: when a role or policy is assigned, and when an identity authenticates and receives a token. Between those moments and the end of an agent's session lies an execution window in which the agent may invoke several tools, each representing a separate decision about whether that specific action is appropriate given the current task.
Runtime governance is architecturally distinct because its enforcement point sits between the agent's decision to invoke a tool and the tool's actual execution. Trussed AI operates at this point, applying runtime policy enforcement and tool approval workflows to individual tool calls within an active session, and generating audit logs of those invocations separate from authentication or API-call logs. This does not replace IAM roles or Entra conditional access, both remain necessary for provisioning and authentication. It adds a control point that neither platform's public documentation describes as a native capability: evaluation of a specific tool call against the agent's current task context at the moment it occurs.
Frequently Asked Questions
Does runtime governance replace AWS IAM or Microsoft Entra?
No. IAM and Entra remain necessary for provisioning execution roles, authenticating identities, and issuing tokens. Runtime governance adds a separate enforcement point at the moment of tool invocation, which neither platform currently documents as a core capability.
Are Bedrock AgentCore Identity and Entra Agent ID generally available?
Both were introduced within the past year as extensions of existing identity platforms. Organizations should verify current vendor documentation for scope and maturity before treating either as equivalent to full runtime tool-call enforcement.
What is the practical risk of relying only on IAM or Entra for agent least privilege?
Execution roles and conditional access policies are typically scoped broadly enough to cover every action group or task an agent might perform, which can grant more standing permission than any single task requires, and audit trails may not capture the sequence of tool calls made during a session.