PMapper (Principal Mapper, AWS IAM Analysis Tool) is a tool for analysing AWS IAM principals, permissions and trust relationships to identify what identities can reach sensitive actions or resources. Defenders use it to spot privilege escalation paths, over-permissioned roles and unintended access chains that static policy review often misses.
What PMapper Reveals About AWS IAM Attack Paths
PMapper turns aws iam policy evaluation into a graph of principals, permissions, and trust edges, which makes it easier to see how a seemingly ordinary role can reach sensitive actions through chaining, pass-role abuse, or indirect assumption paths.
That matters because static policy review often misses the effective permission set created by role assumption, cross-account trust, and inherited access. A tool like PMapper helps defenders reason about what an identity can actually do, not just what each policy document appears to allow in isolation.
How PMapper Models Principals, Permissions, and Trust
At its core, PMapper is an analysis lens for AWS IAM. It starts with principals, then follows attached policies, resource-based permissions, and trust relationships to expose where access can fan out into broader reach than expected. The output is not just a list of permissions, but a map of connected identity paths.
That graph-based view is valuable in AWS because trust policy mistakes, wildcard permissions, and transitive role chaining can create access that is difficult to spot from one policy at a time. It is especially useful when an organisation needs to understand whether a low-privilege principal can pivot into a higher-value role or service.
For readers who want the broader identity context behind this kind of analysis, Ultimate Guide to NHIs — What are Non-Human Identities explains the identities, keys, tokens, and service accounts that often sit behind cloud access paths.
Where PMapper Fits in AWS IAM Review
PMapper is most useful when teams need to move from document review to exposure analysis. It helps answer practical questions such as which principals can assume which roles, whether a trust policy creates an unexpected bridge, and where privilege escalation paths exist even if no single policy looks obviously dangerous.
That makes it a strong companion to manual review, access analysis, and least-privilege cleanup. It is also helpful during migration, incident response, or environment hardening, when the priority is to understand effective access quickly rather than audit every statement by hand.
Related operational guidance on AWS permission structure is covered in AWS IAM Policies and Roles Guide, which explains how policy evaluation, role trust, and role chaining shape the access paths that PMapper surfaces.
For a broader view of how cloud privilege should be reduced once those paths are known, see Cloud PAM and CIEM Guide, which focuses on effective permissions, escalation paths, and right-sizing.
Why AWS IAM Attack-Path Analysis Matters
AWS IAM risk rarely comes from one policy alone. It comes from the combination of identities, trust relationships, temporary credentials, resource permissions, and human error. Tools like PMapper are useful because they expose the path structure that attackers and over-permissioned workflows can exploit.
Once a dangerous path is visible, defenders can prioritise the highest-impact fixes first: breaking unintended trust, tightening pass-role capability, reducing wildcard permissions, and removing redundant privilege bridges. That is often more effective than treating every policy statement as equally important.
If you are building the broader control plane around these findings, the Top 10 AWS IAM Mistakes guide is a useful companion for recognising the most common IAM misconfigurations that create escalation paths in the first place.
Risk and Threat Considerations
Graph-based IAM analysis is important because the dangerous part of AWS access is often the chain, not the single permission. An attacker or insider who reaches one weak principal can sometimes move laterally through trust relationships, discover a higher-privilege role, and then use that role to access data, infrastructure, or administrative actions that were never intended to be reachable from the starting point.
Failure mechanism: Unintended trust edges, overbroad permissions, and role chaining create a hidden path from a low-value principal to sensitive actions. Static review can miss that path because each individual policy may look acceptable while the combined graph is not.
Impact: The result can be privilege escalation, cross-account access, exposure of sensitive resources, and faster attacker movement through the AWS environment. Once a sensitive role is reachable, any compromise of the starting identity becomes a much larger blast-radius problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | PMapper reveals where effective permissions exceed intended access. |
| IA-9 — Service Identification and Authentication | AWS roles and trust relationships are part of machine and service authentication paths. | |
| Recommendation — Use AC-6 to reduce reachable privileges and remove unnecessary escalation paths. Use IA-9 to govern service-to-service trust and constrain role assumption paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The tool is used to find and remove excessive access and privilege pathways. |
| Recommendation — Apply CIS-6 to inventory, review, and restrict effective access paths. | ||
| OWASP API Security Top 10 | API5 Broken Function Level Authorization — Broken Function Level Authorization | Privilege escalation paths can expose functions a principal should not reach. |
| Recommendation — Map reachable actions and close authorization gaps that expose privileged functions. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Attack-path analysis often exposes credentialed privilege escalation and trust abuse. |
| Recommendation — Hunt for manipulated accounts and trust changes that create escalation paths. | ||
Practitioner Guidance
Why practitioners should care: PMapper is most valuable when you need to prioritise IAM remediation by reachability rather than by policy count. It helps teams focus on the identities that can actually reach privileged actions, which is a better signal than reviewing every permission equally.
What to watch for: Pay special attention to role assumption chains, pass-role capability, wildcard resource access, and trust policies that bridge accounts or environments. Those are the patterns that most often turn a small permission mistake into a meaningful escalation path.
Related resources from NHI Mgmt Group
- Guide: Identity Attack Paths Guide
- What are the signs that a compromised IAM principal is being used for attacker discovery in AWS?
- Cloudsplaining (AWS IAM Policy Assessment Tool)
- When do MCP tool controls become an IAM issue rather than a platform issue?
- When does IAM become a compliance control instead of an access tool?