AWS organization guardrails can constrain the principal making a request or the resource receiving it. This analysis compares SCP and RCP scope, cross-account authorization and service-integration conditions, with an explicit test matrix and exceptions that must remain visible during rollout.
At a glance
Key findings
- SCPs and RCPs constrain different sides of a request and do not grant access by themselves. [1][2]
- A cross-account review needs the requesting principal, resource owner and applicable grants, not only the organization policy attached to one account. [3]
- Service support and policy exceptions must be part of the rollout evidence rather than hidden behind an organization-wide coverage claim.
Describe one request from both accounts
An organization can have carefully reviewed service control policies and still need a separate answer about who may reach its resources. The first control is centered on principals governed by the policy. The second question starts with the resource and includes callers outside the organization. A useful review names one request before discussing an organization-wide policy strategy.
AWS introduced resource control policies in November 2024. The launch article explains the resource-side guardrail model, but its original service list should not be reused as a statement of current coverage. For a 2026 review, use the current Organizations documentation to determine which services and resources are supported. [5][2]
Write a request record with the principal ARN, principal account, action, resource ARN, resource account and relevant service context. Identify whether the call is direct or made by an AWS service on another resource's behalf. This record is the input to the policy review. It prevents a diagram labeled “inside the organization” from obscuring two different accounts or an external caller.
Separate grants from maximum authority
An SCP limits the permissions available to principals in governed member accounts; it does not create a permission grant. AWS documents exclusions including management-account principals and service-linked roles. An SCP attached to your organization is therefore not a universal access filter for every principal that might interact with a resource you own. [1]
An RCP instead constrains access to supported resources in governed member accounts, including requests from external principals. It also does not grant access. Its documented exceptions include management-account resources and service-linked-role requests, with additional service-specific limitations. Check the exact support and exception rules for the resource being reviewed. [2]
Keep three entries in the review record: what grants the request, what constrains the caller and what constrains the resource. Do not write “allowed by the SCP” when the intended meaning is merely “not denied by this guardrail.” The distinction matters during an incident because removing a deny and adding a grant are different changes with different consequences.
Where organization guardrails apply
Locate grants, principal-side limits and resource-side limits separately before deciding what an organization guardrail covers.
Source. Primary documentation [1] [2] [3] [4] [5]. Accessed August 28, 2026.
Method. Original request-review map synthesized from AWS documentation. It separates principal-side limits, resource-side limits and grants. It is not a complete IAM evaluator or an observed access graph.
Accessible table and figure data
| Request context | Review focus | Required qualification |
|---|---|---|
| Member principal to member resource | Caller and resource guardrails | Service must support the relevant RCP |
| External principal to member resource | Resource-side restriction | Explicit resource grant still matters |
| Member principal to external resource | Caller-side restriction | RCP cannot be assumed on the external resource |
| Service-linked role | Documented exemption | Do not claim uniform guardrail coverage |
| Resource in management account | Outside RCP scope | Use a separate control review |
| Request context | Review focus | Required qualification |
|---|---|---|
| Member principal to member resource | Caller and resource guardrails | Service must support the relevant RCP |
| External principal to member resource | Resource-side restriction | Explicit resource grant still matters |
| Member principal to external resource | Caller-side restriction | RCP cannot be assumed on the external resource |
| Service-linked role | Documented exemption | Do not claim uniform guardrail coverage |
| Resource in management account | Outside RCP scope | Use a separate control review |
Evaluate the cross-account path
AWS's cross-account evaluation guidance describes authorization in both the trusted and trusting accounts. Identity-based and resource-based permissions, along with applicable controls, must be evaluated in the context of the request. The detailed rules depend on the principal and policy type; a single universal intersection formula is not an adequate substitute for IAM's documented evaluation behavior. [3]
Use a concrete example without treating it as a complete policy evaluator: a role in one member account requests access to an S3 object in another. Identify the caller's identity permissions, the resource-side permission grant and both accounts' applicable organization controls. Then repeat the review with an external principal as the caller. The second case changes which principal-side organization policy is relevant.
Record the principal form used by the resource policy. A grant to a role and a grant to a session are not details to discard before evaluation. If a review cannot explain the actual policy statement and principal type, it should not claim to have proved the request's effective authority. Keep the full policy evidence available to the specialist performing that evaluation.
Protect service integrations deliberately
Some resource requests are made by AWS service principals on behalf of another customer's resource. AWS documents confused-deputy protections using source context, including conditions such as aws:SourceArn, aws:SourceAccount and organization-related source keys where supported. The correct condition depends on what the calling service supplies and the integration being authorized. [4]
Do not transplant a resource-policy example into an organization guardrail without checking its scope. A condition designed to recognize a service acting for an approved source is different from a condition describing the identity of an ordinary caller. Misidentifying that context can either interrupt a legitimate service integration or leave the intended boundary unenforced.
Inventory the service integrations that touch the affected resources before rollout. For each, record the calling service, source resource, destination resource, required context and expected outcome. Include logging, encryption and other supporting integrations in the review where they are relevant. The owner of the primary application may not own these dependencies, so the acceptance record needs their participation.
Roll out with a boundary test set
The test set should distinguish at least a governed member principal, an external principal, a service integration and a documented exception. It should also distinguish supported resources from resources outside RCP coverage. These categories describe authorization boundaries; they are not numeric risk tiers and should not be combined into an invented protection score.
Begin in an explicitly approved test scope. Preserve the pre-change policy attachments and the expected permitted actions before introducing a deny. Exercise both an action that should remain allowed and one that should be rejected. Name the policy layer expected to cause the rejection, then inspect the observed result closely enough to rule out an unrelated permission failure.
Plan recovery before a production rollout. Identify who can change the organization policy, which account or organizational unit is affected and how essential access will be maintained. A staged change can reveal missed dependencies, but a successful test in one account does not prove that every service integration in another account uses the same source context.
Record the limits beside the policy
A useful guardrail record includes the statement's purpose, covered account set, supported resource types, relevant exceptions, dependency owners and acceptance results. Keep the current service-support reference with the record and revisit it when the resource estate changes. A policy can remain unchanged while the set of resources people assume it covers grows.
Describe unresolved cases directly. If a management-account resource is outside the chosen guardrail, name its separate control. If a service-linked role is excepted, record the role and why the exception matters to the request under review. If a service does not support the desired condition, do not write the condition into a diagram as though it were available.
The final decision should be understandable as an answer to a request: which grant permits it, which principal-side limit applies, which resource-side limit applies and which exceptions remain? For a cross-account resource, name both account owners so a later change on either side has a clear review route. That ownership record is what makes a policy diagram useful when a denied integration must be investigated under time pressure.
Method and provenance
Documentation review and original operational analysis using the cited primary sources, checked on August 28, 2026. The editorial date places the article in the retrospective series; publication and source review occurred in August 2026.
This analysis is not an exhaustive IAM evaluator. No organization, account, organizational unit or policy was inspected or changed. Current RCP support and exceptions require a resource-specific review; launch documentation is historical. No empirical tests were performed for this article.
AI assistance. Researched, drafted and checked against cited sources with AI assistance. No independent human editorial review or original empirical testing is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Service control policies Amazon Web Services. Accessed .
- Resource control policies Amazon Web Services. Accessed .
- Cross-account policy evaluation logic Amazon Web Services. Accessed .
- The confused deputy problem Amazon Web Services. Accessed .
- Introducing resource control policies, a new type of authorization policy in AWS Organizations Amazon Web Services. Published . Accessed .