Why do account lists miss some AWS sharing paths?

Why inventory tools miss resource-policy sharing in AWS

Account inventory is usually built around IAM identities, so it sees users, roles, and groups first. Resource policies change the picture because access can be attached directly to a bucket, queue, topic, or KMS key. The result is a real sharing path that exists outside the principal list, so the inventory can look complete while external access still exists.

That gap is especially important in AWS because resource policies can grant cross-account or public access without creating a visible identity attachment. A team that checks only account objects may therefore miss who can reach the resource, even though the resource itself is effectively part of the access boundary. If the inventory model does not include resource-level permissions, it will undercount exposure.

Practical detection starts by reviewing the resource policy itself, not just the account list that sits beside it. For AWS readers, the AWS Multi-Account Security Reference Architecture Guide is useful here because it shows where identities, logs, and guardrails belong in an AWS organisation, which helps teams place resource-policy review into the wider control model.

Where the hidden access path comes from

A resource policy is attached to the protected service object, so it can authorize access independently of IAM role assignment. That means the access path may be real even if there is no corresponding entry in the account inventory, because the permission lives on the resource rather than on a principal. This is why a bucket policy, queue policy, topic policy, or key policy can create an access path that standard identity reports miss.

Cross-account access is the common case practitioners need to think about first. The policy may name another account, a federated principal, or a broad wildcard condition that is harder to spot in account-centric reporting. The inventory then becomes a partial view of control, not a full view of exposure.

The same pattern appears in other cloud services that support direct resource authorization. If your control process only asks “which identities exist?” it will miss the more important question, “which resources can those identities, or other accounts, actually reach?” The answer requires a resource-by-resource review of policy, conditions, and effective access, not just directory-style enumeration.

How to close the visibility gap without overcorrecting

The fix is to reconcile two views: the identity inventory and the resource policy inventory. For AWS, that means checking whether each shared object has an explicit policy, whether the principals named there are expected, and whether the access is still required. The most useful result is not simply “all sharing removed,” but “every sharing path is known, justified, and reviewable.”

That review is easier when you standardise on policy inspection for shared services and treat external access as a separate control domain. The How to review AWS cross-account trust policies for confused deputy guide is relevant because it reinforces the habit of checking the trust relationship itself, which is the same mindset needed when resource policies create non-obvious sharing paths.

When a resource policy is legitimate, document the business reason and the expected principal set. When it is not, remove the access at the resource layer rather than waiting for identity cleanup to solve it. That sequencing matters because deleting an IAM principal does not always remove access granted directly to the resource. If the policy survives, the exposure survives too.

Risk and Threat Considerations

Resource-policy sharing can create exposure that is invisible to identity inventories, which makes it easy to underestimate who can reach a sensitive AWS object. The security issue is not just missed reporting, it is missed enforcement, because a stale or overly broad policy can leave cross-account or public access active after the team believes access has been removed.

Failure mechanism: Access is granted on the resource itself, so inventory systems that only enumerate identities do not see the effective permission path, and cleanup efforts that focus on principals leave the shared resource policy intact.

Impact: External access may persist unnoticed, increasing the chance of data exposure, unauthorized modification, or lateral movement through a shared cloud service boundary.

Practitioner Guidance

What to verify: Confirm that every shared bucket, queue, topic, or key has an owner, an approved principal set, and a current policy review date. If a resource is reachable from another account, verify that the access is still needed and that the policy conditions are as restrictive as intended.

Decision rule: If the resource policy grants access directly, treat it as a first-class access control object, not a cosmetic exception to be handled later in identity cleanup. If the inventory cannot explain the access path, the control view is incomplete.

Practitioner takeaway: In AWS, a clean account list does not prove a clean access posture, because effective sharing can live on the resource, not the principal.

Related resources from NHI Mgmt Group

• Why do static scanners miss some cloud-native attack paths?
• Why do vulnerability scanners miss some real attack paths?
• Why do browser-only controls miss some AI data loss paths?
• Why do monitoring tools miss some attack paths that observability can uncover?