Topic starter
11/11/2026 6:01 pm
TL;DR: AWS external access is fragmented across multiple sharing mechanisms, and Plerion shows that no single AWS query returns a complete answer. Identity reviews have to account for the object that holds permission, not just the account that is named.
Editorial analysis by NHI Mgmt Group, based on content published by Plerion: “I lost my mind doing an AWS external access review”.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Key questions
Q: Why do account lists miss some AWS sharing paths?
A: Account lists usually track IAM users, roles, and groups, but they miss sharing created through resource policy because access can be granted directly on a bucket, queue, topic, or key without appearing as an identity attachment.
Q: How does AWS access analyzer find cross-account access?
A: AWS access analyzer evaluates resource-based policies and IAM trust relationships to identify who can reach a resource from outside the account.
Q: How should teams review external access in AWS accounts?
A: Review every IAM role trust policy, resource policy, and identity-based policy that grants access to principals outside the account, then confirm the permission object, such as the role, key, or session, is limited to the intended external principal.
Practitioner guidance
- Build a permission-object inventory Classify every external-access mechanism by the object that carries permission, including trust policies, resource policies, grants, RAM shares and service-specific lists.
- Separate principal type from account ID Record whether the effective trust comes from an AWS principal, federated principal, service principal or organisation-scoped entry before you decide it is external.
- Validate service-specific read paths Test the exact API or console path for each service so you know which policies are hidden, normalised on read, or only visible through a second query.
Bottom line: AWS external access is fragmented across several AWS permission models, so a single account or role sweep cannot prove who is outside the organisation.
Glossary terms: Resource Policy, Trust Policy, Federated Principal, Access Analyzer
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
External access in AWS is a permission-object problem before it is an IAM problem. The central governance failure is assuming that a list of accounts or roles can represent all outside access. In AWS, the controlling object may be a trust policy, resource policy, grant, account-level share, or service-specific permission structure, so effective access is distributed across several storage models. Practitioners need a review model that follows the permission object rather than the visible account label.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between a trust policy and a resource policy?
A: A trust policy defines which principals can assume a role, while a resource policy defines who can use a resource such as a bucket, topic, queue, or key. The trust policy controls role assumption, and the resource policy controls direct access to the resource, including cross-account permissions.
👉 Read our full editorial: AWS external access spans policies, shares and grants, not one view