Permission Boundary

A permission boundary does not grant permissions itself. Instead, it establishes an absolute ceiling on what is allowable. The effective permissions for an IAM entity are the intersection of its attached identity-based policies and its permission boundary. Even if a broad administrator policy is attached directly to a role, the boundary restricts its usable scope.

The primary security function is to mitigate privilege escalation risk. By capping maximum permissions, it prevents an entity from leveraging its own permissions to grant itself broader access—a critical defense against misconfiguration or compromised credentials. It is a key control for implementing just-in-time (JIT) access and privileged access management (PAM) paradigms.

Boundaries are attached directly to IAM users and IAM roles, not to resources. This makes them an identity-centric control, distinct from resource-based policies. They are particularly critical for roles assumed by:

• Federated users from corporate directories
• AWS service roles for EC2, Lambda, etc.
• Cross-account access roles
• Third-party application service accounts

A permission boundary is defined using a standard IAM policy document (JSON), specifying Allow and Deny actions. It uses the same syntax as other IAM policies but is evaluated differently in the authorization logic. Best practice dictates defining boundaries with Deny statements for sensitive, high-risk actions (e.g., iam:*, s3:DeleteBucket) that should never be available to the bounded entity.

Authorization follows a specific evaluation order:

1. Explicit Deny in any applicable policy (including the boundary).
2. Intersection of the boundary with all other identity-based policies.
3. Resource-based policies and organizational SCPs are evaluated separately. The final effective permission is the overlap between what the boundary allows and what other attached policies allow.

The foundational security principle that mandates every user, process, or system should operate with the minimum levels of access necessary to perform its legitimate function. A permission boundary is a direct implementation of this principle, as it sets an absolute ceiling on permissions, preventing an entity from ever exceeding its necessary operational scope, even if misconfigured policies grant broader rights.

An access control model where permissions are assigned to roles, and users or services are assigned to these roles. RBAC simplifies management in large systems. A permission boundary is often applied to an IAM role in an RBAC system. The boundary defines the maximum permissions the role can have, while the role's attached policies define its operational permissions, ensuring the role never escalates beyond its intended design, even if new policies are added.

An access control policy that is attached directly to a resource (like an S3 bucket or a Lambda function), specifying which principals can access it and what actions they can perform. This contrasts with identity-based policies attached to users or roles. A permission boundary works in conjunction with resource-based policies; the boundary limits the principal, but the resource policy defines if that principal is explicitly allowed or denied access to that specific resource.

The core components of a policy-based authorization architecture.

• Policy Decision Point (PDP): Evaluates access requests against policies to render an allow/deny decision. In cloud IAM, the evaluation engine that checks identity policies, resource policies, and permission boundaries is the PDP.
• Policy Enforcement Point (PEP): Intercepts the request, queries the PDP, and enforces the decision. The cloud service API gateway acts as the PEP. The permission boundary is a critical input to the PDP's evaluation logic.

The practice of limiting the permissions and resource access granted to a set of security credentials (like an API key, OAuth token, or IAM role) to the minimum necessary for their intended function. While a permission boundary is a static, maximum-permissions envelope for an IAM entity, credential scoping is a broader practice that can be dynamic. For example, using OAuth 2.0 scopes to limit an access token's power is a form of runtime credential scoping that works alongside static permission boundaries.

The logical perimeter that defines the scope of resources, data, and operations for which a specific set of permissions or a security principal is valid. A permission boundary is a specific type of authorization boundary implemented within IAM systems. More broadly, an authorization boundary can refer to the trust zone of a microservice, the data plane of a specific application, or the limits of a software module's access, all conceptually serving to contain and define the sphere of allowed influence.