TL;DR: AWS external access cannot be answered from a single inventory path because trust policies, resource policies, RAM shares, grants and account lists all expose different slices of access, while some services hide or delay what they report, according to Plerion research. The practical issue is not finding a policy, but proving who can actually use it across the service boundary.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Plerion's blog post: AWS external access is split across trust policies, resource policies, RAM shares, grants and account lists, so no single inventory query gives a complete answer.
Why it matters: IAM and cloud security teams need to model external access by sharing mechanism and effective principal, or they will miss permissions that sit outside the obvious account list.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
Context
AWS access review gets harder when the permission is attached to a resource, not just to an identity. In practice, the same external relationship can appear as a role trust, a resource policy, a RAM attachment, a grant, or a service-specific list, which means a simple account enumeration misses part of the exposure.
The governance gap is not a lack of logs or tooling alone. It is a structural mismatch between how AWS stores sharing intent and how practitioners usually try to answer a lifecycle question about who outside the organisation can still act inside it.
That mismatch makes external access review an identity problem as much as a cloud problem: the control objective is to identify effective trust, not merely to list accounts or principals.
Key questions
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. Check for direct cross-account trust, wildcard principals, and stale access paths created by bucket, queue, topic, or key policies.
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. That means external access may exist even when no corresponding principal shows up in the account inventory.
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. It looks for cross-account access paths, public exposure, and conditions that make a principal effectively trusted, then reports the access path rather than only the named identity.
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.
Technical breakdown
Why AWS sharing is split across seven permission objects
AWS does not use one uniform external-access model. Depending on the service, permission may live in a role trust policy, a resource policy, an account-level policy, a grant, or a service-owned access list. Some objects are readable only through the owning service, some are normalised on read, and some are not policy documents at all. That means the same external relationship can be expressed in several incompatible formats, which breaks any one-size-fits-all enumeration approach. See the IAM and IGA Basics.
Practical implication: Inventory external access by permission object and service family, not by trying to rely on a single AWS-wide lookup.
Why account IDs are not enough to prove external access
An account identifier often appears where the actual trust decision is elsewhere. Federated principals, organisation-scoped access, and service-linked permissions can all hide the real subject behind an ARN or a service principal, while some entries look external even when they resolve to an internal trust boundary. In several AWS services, the account list is only one fragment of the effective access story, so an account-only report can be both incomplete and misleading.
Practical implication: Correlate account IDs with the actual principal type and trust source before treating a share as external exposure.
Why AWS access analyzers still miss parts of the picture
AWS access analysis is useful, but it is bounded by what it can read and when it rescans. Some services and scopes are excluded, some findings lag behind configuration change, and some results require a second API call to recover the principal details. That makes the analyzer a partial evidence source rather than a definitive answer engine. Where the analysis depends on delayed scans or service-specific coverage gaps, the absence of a finding does not mean the absence of access.
Practical implication: Treat analyzer output as one input to external-access review, then validate service gaps and scan latency before closing findings.
Threat narrative
Attacker objective: The objective is persistent cross-account or cross-organisation access to AWS resources without immediate detection by the account owner.
- Entry occurs when an external principal is granted access through a role trust policy, resource policy, RAM share, grant, or service-specific permission object.
- Credential or access scope is then expanded when the effective principal is hidden inside a federated identity, organisation reference, or service-linked control rather than an obvious account list.
- Impact follows when a reviewer assumes the account list is complete and leaves external access in place after a vendor, partner, or automation relationship should have been removed.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Effective external access is determined by who can act, not who is named. A federated principal, organisation-scoped entry, or service principal can all look simple in a report while hiding the real trust relationship. That makes the visible ARN an insufficient unit of governance unless the service-specific semantics are understood. The implication is that access review has to evaluate principal type, scope, and storage location together.
Access analysis latency changes the meaning of a green result. If a service reports ACTIVE before the scan is complete, or only surfaces part of a finding through a follow-up call, the control is evidentially weak at first read. That is not just a tooling nuisance; it means the assurance boundary is time-bound. Practitioners should treat delayed or partial read-back as a governance risk, not an implementation footnote.
Resource access grants make a previously scattered problem legible. Turning each share into one row with a single principal and a single resource is a strong named concept for governance because it converts many AWS-specific shapes into one reviewable unit. That does not eliminate the underlying service differences, but it does create a usable abstraction for accountability and certification. The practical conclusion is that external access review should be normalised around effective grants rather than raw policy text.
Permission drift is inevitable when service owners can invent their own access vocabulary. AWS services do not share one common policy grammar, one common read API, or one common revocation path. That fragmentation means external access governance will remain brittle unless organisations standardise their own review taxonomy above the platform layer. The implication for practitioners is to govern the semantics of access, not only the syntax of the service API.
From our research library:
- 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.
- Read next: Access Reviews and Certification Guide
What this signals
Permission-object governance is the real lesson here: external access cannot be certified from a single account-centric sweep because the permission may live in a trust policy, a resource policy, a grant, or a service-owned list. That means external-access programmes need a canonical inventory layer above AWS service syntax, otherwise review outcomes will remain partial by design.
The next maturity step is to govern effective grants, not raw documents. When access is normalised into one row per principal and resource, reviewers can separate deliberate vendor and partner access from orphaned or untrusted external access, which is the only version of the problem that practitioners can realistically close.
For practitioners
- 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. See the IAM and IGA Basics.
- 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.
- Treat delayed scan states as open risk Do not mark a share as cleared until the service has finished rescanning and the principal details are present, not just the status flag.
- Normalise findings into one review row Convert each effective share into a single reviewable grant that names the resource, principal and trust state so business owners can certify or revoke it.
Key takeaways
- AWS external access is fragmented across several AWS permission models, so a single account or role sweep cannot prove who is outside the organisation.
- Service-specific semantics matter because the same principal can be visible in one API path and hidden in another, which creates false confidence during reviews.
- The practical control is to normalise effective shares into reviewable grants and validate them against service-specific read paths before certifying access.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · IAM and IGA Basics · Access Reviews and Certification Guide · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | External vendor and partner access through AWS trusts is the article's core exposure pattern. |
| NHI-04 — Insecure Authentication | Federated principals and trust policies determine how external identities authenticate into AWS. | |
| NHI-05 — Overprivileged NHI | The article shows how external principals can retain broader access than reviewers expect. | |
| Recommendation — Map outside principals to NHI-03 and review third-party access paths service by service. Validate federated trust paths and constrain authentication flows that reach AWS resources. Reduce external shares to the minimum effective scope and re-certify any broad grants. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | External access should be scoped to least privilege across accounts, grants and resource policies. |
| Recommendation — Apply least privilege across all AWS sharing mechanisms and remove unnecessary external entitlements. | ||
| CIS Controls v8 | CIS-5 — Account Management | External access review depends on knowing which accounts, roles and service principals remain active. |
| Recommendation — Maintain an authoritative inventory of external accounts and revoke stale access paths promptly. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Cross-account trust can be abused to gain credentialed access and move laterally inside cloud environments. |
| Recommendation — Hunt for externally granted cloud access that could support credential access or lateral movement. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is the accuracy of entitlement reporting across AWS access mechanisms. |
| Recommendation — Map every AWS share to a governed entitlement and verify the effective authorisation path. | ||
Key terms
- Resource Policy: A resource policy is an access-control document attached to a cloud resource that defines who can interact with it and under what conditions. In practice, overly broad resource policies can allow unintended subscription, invocation, or data exposure, so they must be evaluated alongside identity permissions.
- Trust Policy: The rules that decide which workload may receive access under federation. In practice, trust policy binds claims such as repository, branch, environment, or runner posture to specific permissions, making it the control point that replaces the old stored secret.
- Federated Principal: The verified identity used in a federation exchange, such as an IAM role or service account. Unlike a shared API key, the principal is tied to a specific runtime context, which allows logs, policies and lifecycle controls to follow the actual workload rather than an opaque string.
- Access Analyzer: Access Analyzer is a security analysis tool that reviews access policies and resource permissions to find where access is granted outside intended boundaries. It works by evaluating identity-based policies, resource policies, and sharing configurations, then flagging findings that indicate public, cross-account, or otherwise overly broad access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org