The Science of Setting Up Security Boundaries

Updated August 2026: This article was originally published in November 2024 and has been comprehensively updated to include multi-cloud boundary strategies, policy-as-code tooling (Cedar, OPA), identity-aware boundaries in zero-trust architectures, and practical implementation patterns as of 2026.

Setting permission boundaries is one of the most consequential architectural decisions in cloud security. It involves defining the maximum permissions that users, groups, or roles can hold within a cloud environment — effectively drawing the lines that separate what is permissible from what is not. When implemented correctly, these boundaries prevent unauthorized access, reduce blast radius during incidents, and enforce the principle of least privilege at scale.

In this article, we go deep into the process of setting permissions boundaries in large cloud environments, explore how to build strong security foundations across multiple cloud providers, examine modern policy-as-code tooling, and discuss how identity-aware boundaries fit into zero-trust architectures.

What is a Security Boundary?

A security boundary refers to the perimeter or barrier that separates a trusted system or network from an untrusted environment. The term “perimeter” is often used interchangeably with “boundary,” though in modern cloud architectures the concept has evolved well beyond physical network edges.

In cloud computing, security boundaries exist in both physical and logical forms. Physical boundaries include network firewalls, hardware security modules (HSMs), and physical access controls at data centers. Logical boundaries encompass security policies, IAM configurations, encryption mechanisms, and software-defined network segmentation.

The security boundary in a cloud environment defines the maximum permissible permissions for users or resources. It is a logical separation that can be enforced at the network level, the identity level, or increasingly, at both simultaneously.

• Network boundaries: These define the network segments, zones, or micro-perimeters within a cloud environment. VPCs, subnets, security groups, and network ACLs all serve as network-level boundaries.
• IAM boundaries: These restrict the permissions granted to identities within the cloud environment. Permission boundaries, SCPs, and conditional policies all operate at this layer.

The distinction matters because modern attacks frequently exploit the gap between network-level and identity-level controls. An attacker who gains access to a VPC through a compromised workload still needs to overcome IAM boundaries to escalate privileges or move laterally. Effective security architecture layers both types of boundaries.

Permissions boundary in a nutshell

Credit: Kushagra Sharma

The diagram above illustrates a fundamental concept: a user’s effective permissions are the intersection of their identity-based policies and the permissions boundary attached to them. Even if an identity policy grants s3:*, a permissions boundary that only allows s3:GetObject and s3:PutObject means the effective permission set is limited to those two actions. This intersection model is what makes boundaries so powerful as a guardrail mechanism — they cap the ceiling regardless of what individual policies grant.

Differentiating security boundaries and security baselines

People often confuse security boundaries with security baselines. When we asked Kushagra to shed light on the differences, he distilled it into a framework that is immediately actionable:

• Scope: Boundaries focus on maximum limits — the ceiling of what is permitted. Baselines establish the minimum requirements — the floor of what must be in place.
• Relationship: Baselines are broader in scope, encompassing various security controls (encryption at rest, logging requirements, network segmentation). Boundaries are more specific to particular aspects of the environment, such as IAM permissions for a given account or OU.
• Intersection: Security boundaries can be considered a subset of security baselines. They contribute to the overall security posture by enforcing the guardrails that prevent policy violations, while baselines define what “good” looks like across all dimensions.

Understanding this distinction is critical for platform teams: your baseline defines what every account must have (CloudTrail enabled, default encryption, VPC flow logs), while your boundary defines what no account is allowed to exceed (no public S3 buckets, no IAM users with console access outside SSO, no EC2 instances in unapproved regions).

Setting up the basics — Challenges with IAM management

Security leaders consistently emphasize that in large cloud environments, the battle is won or lost at the identity layer. The old-aged debate between IAM and cloud security never ends. When it comes to large environments, here are the challenges with IAM management that make boundary definition difficult:

• Myriad compliance requirements: Organizations operating across jurisdictions must adhere to overlapping and sometimes contradictory compliance standards — SOC 2, PCI DSS, HIPAA, GDPR, and industry-specific regulations. Each may impose different constraints on permissible actions.
• Evaluating effective permissions gets complicated for cloud developers: Developers are not security practitioners. The intersection of identity policies, resource policies, permission boundaries, SCPs, and session policies creates a combinatorial explosion that few humans can reason about correctly.
• Difficulty keeping up with new cloud services: AWS, Azure, and GCP ship hundreds of new services and features annually. Each new service introduces new IAM actions that must be evaluated against existing boundaries.
• Security teams end up operationalizing: Instead of focusing on strategic security architecture, teams become ticket-resolution machines — processing access requests, reviewing policies, and troubleshooting denied actions.
• “Security creates friction”: When boundaries are poorly designed, they block legitimate work. When they are too permissive, they provide false confidence. The perception of security as a blocker often stems from boundaries that were not designed with developer experience in mind.

Is a one-size-fits-all permissions boundary possible?

Building a one-size-fits-all permissions boundary that addresses AWS account-level exceptions, allows only vetted service deployments, satisfies regulatory requirements, and scales across hundreds of accounts is, in short, not practical.

Booking.com developed a unique approach for permissions boundaries, as Kushagra shared. He described 4 real-time steps of their “flavored approach to permissions boundary” method:

1. One dynamic boundary with global defaults defined by the security team. This establishes the baseline restrictions that apply everywhere — deny actions that are never acceptable (e.g., disabling CloudTrail, creating IAM users outside the identity provider).
2. Allow exceptions to the boundary on a per-account level. Some accounts have legitimate needs that deviate from the global default (e.g., a data science account that requires SageMaker access that other accounts do not).
3. Enable developers to contribute to the boundary, moving towards a self-service IAM model. Developers submit boundary modification requests as pull requests to an IaC repository, subject to automated policy checks and security review.
4. For environments under regulatory scope, create a “new flavor” of the boundary. PCI environments get one flavor; HIPAA environments get another. Each flavor is a composition of the global defaults plus environment-specific restrictions.

To implement this in practice using Terraform, you define a hash map specifying expectations for regions, IAM actions, and allowed AMI owner IDs for deploying vendor tooling. Each “flavor” is a Terraform module that composes these variables differently based on the target environment’s classification.

This is fundamentally a layered approach: a global baseline combined with environment-specific permission boundaries. It allows flexibility and scalability while maintaining consistency. A standardized template dynamically generates permission boundaries based on context, avoiding the complexity and maintenance burden of siloed baselines per account.

Multi-Cloud Security Boundaries

Most organizations operate across multiple cloud providers. Maintaining consistent security boundaries across AWS, Azure, and GCP requires understanding each provider’s native boundary mechanisms and designing an abstraction layer above them.

Azure: Management Groups and Azure Policy

Azure’s boundary hierarchy operates through Management Groups, which provide a scope above subscriptions. Azure Policy serves a similar role to AWS SCPs — it enforces organizational rules at scale.

• Management Groups allow you to organize subscriptions into a hierarchy and apply governance conditions. A deny policy at the management group level cascades to all child subscriptions.
• Azure Policy definitions can enforce resource configurations (e.g., “all storage accounts must have HTTPS-only enabled”) and deny non-compliant deployments. Policy initiatives group related policies into a single assignable unit.
• Azure RBAC with deny assignments can restrict specific actions at the subscription or resource group level, functioning similarly to permission boundaries in AWS.

GCP: Organization Policies and IAM Conditions

GCP takes a different architectural approach to boundaries:

• Organization Policies are constraints applied at the organization, folder, or project level. They restrict which resources can be created and how they can be configured (e.g., constraints/compute.disableSerialPortAccess).
• IAM Conditions add context-aware restrictions to role bindings — you can grant a role only during business hours, only from specific IP ranges, or only to resources with specific labels.
• VPC Service Controls create security perimeters around GCP resources to prevent data exfiltration, even for users with legitimate IAM permissions.

Maintaining Consistency Across Providers

The challenge is not just implementing boundaries on each provider, but ensuring they express the same organizational intent. A practical approach involves:

1. Define boundaries at the intent level first. Document what the boundary means in cloud-agnostic language: “No production database may be publicly accessible.” Then translate that intent into each provider’s native enforcement mechanism.
2. Use a policy-as-code layer (discussed in the next section) to express boundaries in a single language and compile them to provider-specific formats.
3. Maintain a boundary registry — a versioned catalog that maps each organizational boundary to its implementation in AWS (SCP), Azure (Policy), and GCP (Organization Policy).
4. Validate continuously with cross-cloud visibility tools that evaluate effective permissions across all providers and flag drift from the intended boundary posture.

Policy-as-Code Tooling for Boundaries

The shift from manually-managed policies to policy-as-code has transformed how organizations define, test, and enforce security boundaries. Here are the primary tools and when to use each.

1. OPA/Rego for Cross-Cloud Policy

Open Policy Agent (OPA) with its Rego policy language is the most widely adopted general-purpose policy engine. It decouples policy decisions from policy enforcement, meaning you can write one set of policies and enforce them across Kubernetes admission, CI/CD pipelines, Terraform plans, and API gateways.

When to use: When you need a single policy language to express boundaries across multiple enforcement points (cloud APIs, Kubernetes, service mesh, IaC). OPA excels at evaluating structured data (JSON/YAML) against declarative rules.

2. AWS Cedar for Fine-Grained Authorization

Cedar is AWS’s purpose-built authorization language designed for application-level access control. Unlike IAM policies, which are evaluated by AWS services, Cedar policies are evaluated by your application code via Amazon Verified Permissions.

When to use: When you need fine-grained, application-layer authorization decisions that go beyond infrastructure IAM — multi-tenant SaaS applications, API authorization with complex attribute-based conditions, or when you need sub-millisecond policy evaluation at the application edge.

3. HashiCorp Sentinel for Terraform Guardrails

Sentinel integrates directly into Terraform Enterprise and Terraform Cloud, evaluating policies against the planned infrastructure changes before they are applied.

When to use: When your infrastructure is managed via Terraform and you need pre-apply guardrails. Sentinel policies can prevent a terraform apply that would create a publicly accessible S3 bucket, an unencrypted RDS instance, or a security group with 0.0.0.0/0 ingress.

4. Kyverno for Kubernetes Admission

Kyverno is a Kubernetes-native policy engine that uses standard Kubernetes resource definitions (no new language to learn). It operates as an admission controller, validating and mutating resources before they are persisted.

When to use: When your workloads run on Kubernetes and you need admission-time enforcement — requiring specific labels, blocking privileged containers, enforcing network policies, or automatically injecting sidecars.

Choosing the Right Tool

Use Case	Primary Tool	Reason
Cross-cloud infra policy	OPA/Rego	Language-agnostic, broad ecosystem
Terraform guardrails	Sentinel	Native Terraform integration
K8s admission control	Kyverno	No new language, K8s-native
App-layer authorization	Cedar	Purpose-built, high performance
Multi-tool environments	OPA + provider-specific	OPA as lingua franca

In practice, most mature organizations use a combination: OPA for cross-cutting organizational policies, Sentinel or OPA-based Terraform checks for IaC boundaries, and Kyverno for Kubernetes admission. The key principle is to express the boundary once in human-readable policy and enforce it as close to the point of action as possible.

Identity-Aware Boundaries in Zero-Trust Architectures

Traditional security boundaries assumed a trusted internal network and an untrusted external one. Zero-trust architecture eliminates this assumption: no request is trusted by default, regardless of its origin. In this model, identity context becomes the primary boundary mechanism.

How Identity Context Complements Network Boundaries

In a zero-trust model, network boundaries still exist but are insufficient alone. A request from inside the VPC is not inherently more trusted than one from outside. Instead, every request is evaluated against:

• Who is making the request (authenticated identity)
• What they are trying to do (requested action)
• From where (network context, device posture)
• When (time-based conditions)
• Why (justification, business context)

Identity-aware boundaries combine these signals to make access decisions. An engineer requesting production database access is evaluated differently if they are on a managed device on the corporate network during business hours versus on an unmanaged device from an unusual geolocation at 3 AM.

Combining JIT Access with SCPs for Defense-in-Depth

One of the most effective patterns for reducing boundary complexity is eliminating standing privileges entirely. Instead of defining elaborate permission boundaries to constrain what users could do, Just-In-Time (JIT) access ensures they have no persistent access to escalate in the first place.

The defense-in-depth model combines multiple layers:

1. SCPs as the hard ceiling — actions that are never permissible regardless of context (e.g., deleting CloudTrail logs, disabling GuardDuty).
2. Permission boundaries as the role-specific ceiling — the maximum permissions any role of that type can receive.
3. JIT access as the operational layer — engineers request access for a specific duration with a stated justification. Access is granted, time-bounded, and automatically revoked.

This approach dramatically reduces the effective attack surface. An attacker who compromises an engineer’s credentials finds no standing permissions to exploit. The permission boundary exists as a safety net, but JIT access means it is rarely the only thing standing between an attacker and sensitive resources.

Context-Aware Access Decisions

Modern identity-aware boundaries evaluate access decisions based on a risk score derived from multiple signals:

• Device posture: Is the device managed? Is disk encryption enabled? Is the OS patched?
• Location: Is the request from a known IP range? Is there an impossible travel scenario?
• Behavioral baseline: Does this request pattern match the user’s historical behavior?
• Resource sensitivity: What is the data classification of the resource being accessed?
• Time context: Is this request during normal working hours for this user’s timezone?

These signals feed into a policy decision point that determines whether to allow, deny, or step-up (require additional authentication) the request. This is where tools like Cloudanix CIEM provide the visibility layer — understanding effective permissions across multi-cloud environments and identifying where standing access exceeds what identity-aware boundaries should allow.

Leveraging Threat Intelligence for Building Strong Security Foundations

Defining and maintaining security baselines is not a set-and-forget practice. In cloud environments where new services and features ship continuously, threat intelligence must inform boundary evolution. Below are the key elements of a threat-informed boundary strategy:

• Integrating threat intelligence: Threat detection and response teams provide insights into real-world attack patterns. If a new technique exploits a specific IAM action (e.g., iam:PassRole for privilege escalation), that intelligence should inform boundary restrictions.
• Baseline refinement: By analyzing threat intelligence, security teams can identify and address potential risks before they materialize. Boundaries should be version-controlled and updated through pull requests that reference the threat intelligence driving the change.
• Constant monitoring: Security teams need to stay current on new services, feature releases, and IAM namespace changes. AWS alone adds hundreds of new IAM actions per year — each one is a potential new attack surface.
• Multiple sources: Threat intelligence comes from public announcements, cloud provider security bulletins, industry ISACs, open-source threat feeds, and internal red team exercises. A structured intake process ensures relevant intelligence reaches the team responsible for boundary definitions.

The above principles highlight that boundaries are living artifacts. They require continuous maintenance driven by threat landscape changes, not just annual reviews.

Effective Strategies for Defining Strong Permissions Boundaries

When defining permission boundaries, identities are the starting point. But a boundary designed without considering developer workflows will generate friction and workarounds. The flavored approach described earlier addresses this by tailoring boundaries to context. Beyond that, organizations should consider:

Service Control Policies (SCPs) that apply to all IAM entities within a specific AWS account or organizational unit. SCPs are designed for non-negotiable controls — they cannot be overridden by any policy within the account. Use them for:

• Preventing regions you do not operate in
• Blocking services that have not passed security review
• Requiring encryption for data services
• Preventing deletion of audit logs

Permission boundaries that attach to IAM roles and users, capping their maximum effective permissions regardless of what identity policies grant. Use them for:

• Delegated administration (allow teams to create their own roles, but only within the boundary)
• Developer sandboxes (broad exploration rights that cannot exceed production-safe actions)
• Vendor access (third-party roles bounded to the minimum necessary)

IaC automation for creating and modifying boundaries. This streamlines the workflow, enables peer review, provides an audit trail, and reduces the risk of human error. Every boundary change should be a versioned commit with a linked justification.

The benefits of this layered approach:

• Enhanced Security: SCPs + permission boundaries + identity policies create defense-in-depth at the IAM layer.
• Improved Efficiency: Automation and dynamic boundaries reduce approval bottlenecks.
• Empowered Developers: Self-service within guardrails — developers can experiment without waiting for security team tickets.

Defining Permission Boundaries When Migrating from Legacy Systems

Migrating from legacy systems to cloud environments while maintaining security continuity remains challenging. The recommended approach starts with relaxed permission boundaries during migration, gradually tightening them as the environment stabilizes and the team gains confidence in the boundary definitions.

Priority areas during migration:

• Leverage flavored permission boundaries: Use different boundary flavors for legacy workloads (which may need broader access during transition), greenfield cloud-native workloads (which can start with strict boundaries), and regulated workloads (which require compliance-specific flavors).
• Refactor and optimize: Re-evaluate the existing environment to identify opportunities for leveraging cloud-native features. Legacy workloads that ran with root-equivalent access on-premises should be decomposed into least-privilege roles in the cloud.
• Centralized deployment: Ensure a centralized mechanism for deploying and managing permissions across multiple accounts to facilitate efficient migration and ongoing management.

The phased migration strategy should follow this progression:

1. Assess the legacy environment: Understand the current security posture, data sensitivity, and compliance requirements. Map existing access patterns to cloud IAM equivalents.
2. Define initial permission boundaries: Create boundaries that are broader than your target state but still enforce critical guardrails (no public exposure, encryption required, audit logging mandatory).
3. Migrate gradually: Start with less sensitive workloads. Use the migration of each workload as an opportunity to define and test tighter boundaries.
4. Refine and optimize: Analyze CloudTrail and access logs to identify permissions that are granted but never used. Tighten boundaries based on observed behavior.
5. Implement monitoring and auditing: Deploy continuous monitoring that alerts on boundary violations, unused permissions, and access anomalies.
6. Provide training and awareness: Ensure engineering teams understand the boundary model, how to request exceptions, and how to contribute to boundary definitions via IaC.

What If a Specific Cloud Provider Feature Does Not Align with Your Defined Security Baselines?

When a cloud provider rolls out a new feature that does not align with your security baselines — which happens regularly given the pace of cloud service releases — you need a structured response.

It is not recommended to follow a deny-list approach where you deny a specific set of services and allow the rest. This approach implicitly allows every new service without security review, creating an ever-growing attack surface.

What experts recommend is a safelisting approach: maintain a whitelist of approved cloud services and features. Only those explicitly on the list are permitted within the organization’s cloud environment.

Benefits of safelisting

• Controlled environment: Limiting the services in use reduces the attack surface of the production environment. Every service not on the safelist is denied by default.
• Proactive security: New services are blocked until they pass security review, preventing unauthorized or risky deployments.
• Baseline alignment: The safelist and the security baseline reinforce each other — the safelist ensures only reviewed services are used, and the baseline defines how those services must be configured.

Guidelines for implementation and maintenance

• Create the list: Carefully identify cloud services deemed necessary and secure for organizational operations. Include the specific IAM actions associated with each service.
• Regular review: Establish a cadence (monthly or per-sprint) for reviewing new services against your security criteria and adding approved ones to the safelist.
• Threat handling: For each approved service, implement appropriate security controls and monitoring. Define what “secure configuration” means for that service before adding it to the safelist.
• Continuous testing: Regularly test that the enforcement mechanism (SCP, Azure Policy, GCP Organization Policy) correctly blocks non-safelisted services.

While safelisting provides structure, it can limit agility if the review process is slow. The key is making the review process lightweight and fast for low-risk services while maintaining rigor for services that handle sensitive data or have high blast radius.

Conclusion

Setting up effective security boundaries in 2026 requires thinking beyond any single cloud provider’s native tooling. The principles remain the same — define the ceiling, enforce least privilege, and maintain visibility — but the implementation has evolved significantly.

Modern boundary architecture combines provider-native mechanisms (SCPs, Azure Policy, GCP Organization Policies) with cross-cloud policy-as-code engines (OPA, Sentinel, Kyverno), layered with identity-aware access decisions that evaluate context before granting access. The flavored approach pioneered at scale gives organizations a practical framework for maintaining consistency without sacrificing flexibility.

The shift toward JIT access and zero-trust principles means that permission boundaries increasingly serve as safety nets rather than primary controls. When standing access is eliminated, the boundary catches edge cases rather than being the daily enforcement mechanism. This architectural shift reduces both security risk and developer friction — the boundaries are still there, but they rarely fire because the access model itself has changed.

Organizations that invest in expressing their boundaries as code, testing them in CI/CD, and continuously refining them based on threat intelligence will build security postures that scale with their cloud footprint rather than becoming an ever-growing maintenance burden.

People Also Read

• AWS IAM Permission Boundary and Why You Shouldn’t Ignore It
• Comprehensive Guide to Threat Modeling
• Why IAM in the Cloud Needs Attention
• Top 18 Challenges of Cloud Security in 2026
• Top 15 Cloud Misconfigurations in 2026 - How to Fix Them?
• Kubernetes Security Checklist 2026
• The Science of Hiring Cybersecurity Professionals
• Building Cybersecurity Teams