Resource policies need concrete scope

Find the grant that a narrow-looking role summary leaves out.

Read both sides

A resource-based policy is attached to a resource and can grant specified principals access to it. In a straightforward AWS same-account evaluation, an applicable allow from an identity or resource policy can authorize the action. A narrow allow in one document does not automatically cap another grant.

Three records for Exporter

R1: Exporter’s role policy allows reading objects under reports/approved/.

R2: The bucket policy grants that same role object reads under reports/*, including reports/draft/forecast.csv.

R3: The owner approves only reports/approved/. Both policies and the role belong to one account.

These are simplified policy summaries. Assume valid authentication, matching conditions, satisfied encryption prerequisites, and no explicit deny, permissions boundary, session restriction, or organization restriction affecting these reads.

R2 supplies the excess allow. Under those assumptions, reading the draft is permitted by policy even though it is outside the owner’s approved purpose. R1 does not subtract R2’s permission. The wildcard also includes future object keys matching that prefix; it does not grant unrelated operations such as deletion.

A useful proposal narrows R2 to the approved prefix and checks for other grants before declaring closure. Adding another narrow allow leaves the original excess intact. If the team considers an explicit deny, it must assess which legitimate consumers that deny would also affect.

Write a review citing R2 and R3, with two acceptance expectations: the approved report remains readable and the draft is denied for Exporter. Separate policy authorization from observed use: these records establish a grant, not that anyone read the draft. Cross-account access and additional policy types need their own evaluation.