Permission Boundaries for Developer Roles

Permission boundaries cap maximum permissions.

Idea

One of the hardest parts of IAM at scale is letting developers create roles for their workloads without giving them the ability to over-grant permissions. The team that requires every IAM change to go through security review becomes the bottleneck on every project; the team that lets developers self-serve produces over-permissioned roles. Permission boundaries solve this by letting developers create roles within a hard cap on what those roles can do.

What permission boundaries actually are:

• Cap on effective permissions.: A permission boundary is a policy attached to a role that limits the maximum permissions that role can have. Even if the role's own policy grants broader permissions, the boundary prevents them from being effective. The cap is the floor of constraint.
• Developer-created roles are bounded.: When a developer creates a new role for their workload, the boundary attaches automatically. The developer can grant permissions up to the boundary; they cannot grant beyond it. The boundary is the safety net that lets developers self-serve.
• Production destructive operations excluded.: The boundary excludes operations like iam:CreateUser, iam:DeleteUser, iam:AttachUserPolicy, kms:DeleteKey. The developer-created role cannot perform these no matter what its own policy says. The permissions that could escalate privilege or destroy production are walled off.
• Cross-account boundaries.: The boundary can also restrict cross-account operations, ensuring that developer-created roles cannot assume roles in production accounts. The blast radius of a misconfigured developer role is bounded to their own account.
• Per-team or per-environment boundaries.: Different teams may have different boundary configurations. Engineering teams have a more permissive boundary than contractor accounts. Production environments have stricter boundaries than dev. The configuration matches the trust level.

Permission boundaries let security teams enforce constraints without becoming a bottleneck. Developers can move fast within the safe envelope; the unsafe operations stay out of reach.

Setup

Setting up permission boundaries is straightforward in concept and operationally significant in practice. The boundary is itself a policy, attached to roles either at creation time or via continuous enforcement.

• Default boundary on developer-created roles.: The IAM provisioning automation attaches the boundary to every new role created in developer-managed environments. Roles created without the boundary fail validation. The default is the safety net; opting out requires explicit security approval.
• Excludes destructive permissions.: The boundary policy explicitly denies high-risk actions: IAM modifications, key deletions, account-level changes, S3 bucket deletions of certain prefixes, RDS instance deletions. Each exclusion is documented; the rationale is captured.
• Includes everything else.: The boundary allows the standard set of operations a developer workload typically needs: read/write to their own data plane, invoke specific Lambda functions, query specific databases. Within the boundary, developers can grant whatever they actually need.
• Service control policies pair with boundaries.: At the AWS Organizations level, service control policies (SCPs) provide an additional cap. The SCP applies to all roles in the account, including ones that bypass the boundary. The two layers compound.
• Document the boundary policy.: The boundary is itself code, version-controlled, reviewed. The current boundary is published to engineering. Developers know what their roles can and cannot do; they design within those constraints rather than building roles that will fail at runtime.

The setup is one-time work. Once the boundary is in place, every new role inherits it; the protection is automatic.

Audit

Permission boundaries are not set-and-forget. The discipline of maintaining them includes auditing the cases where roles are bumping against the boundary, tuning the boundary as the engineering needs evolve, and verifying that the boundary is actually being applied to all new roles.

• Roles bumping against boundary surface.: When a role's own policy would grant a permission that the boundary denies, the IAM service logs the deny. The audit reviews these cases periodically. Some are legitimate (the workload genuinely does not need that permission); some indicate that the boundary is too restrictive for the workload's actual needs.
• Investigate the gap.: When a workload genuinely needs a permission the boundary denies, the team has two choices: change the workload to not need it, or relax the boundary. The choice is deliberate; relaxing the boundary requires explicit security approval and documentation.
• Tune the boundary periodically.: The boundary's exclusions reflect the current security policy. As new services emerge and new threat patterns develop, the exclusion list gets updated. Quarterly review of the boundary catches the cases where it has drifted out of date.
• Verify boundary application.: Periodically scan the role inventory to confirm that the boundary is attached where expected. The IAM provisioning automation should be enforcing it; the verification confirms the automation is working. Drift is detected and corrected.
• Compliance evidence.: The permission boundary is itself a compliance control. Auditors verify the boundary exists, is applied, and excludes the right destructive operations. The audit trail of boundary enforcement and exception approvals is the evidence.

Permission boundaries are the IAM pattern that lets engineering organizations move quickly without producing the kind of over-permissioned roles that cause incidents. Nova AI Ops integrates with cloud IAM systems, audits the application of boundary policies across the role inventory, and surfaces the cases where roles are operating near or against their boundaries so the security team has visibility without blocking developer velocity.