IAM wildcards deserve attention because they can express broad authority. Counting * characters, however, cannot tell you which requests a principal can actually make or what those requests can change.
An AWS authorization decision is evaluated for a concrete principal, action, resource, and request context across every applicable policy. A narrow-looking identity policy can combine with a permissive resource policy. A broad action can be constrained by resources and conditions. A permissions boundary, session policy, service control policy, resource control policy, or explicit deny can change the result.
A wildcard is a signal, not a risk score
Compare three policy fragments:
{ "Action": "s3:*", "Resource": "arn:aws:s3:::example/*" }
{ "Action": "s3:GetObject", "Resource": "*" }
{ "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/*" }
The first contains an action wildcard, the second a resource wildcard, and the third a partial resource wildcard. Their risk cannot be ranked from wildcard position alone. You need to know the data in the bucket, which buckets are reachable, whether conditions narrow the request, which roles can be passed, which services can receive them, and what those roles authorize.
Calculate the effective request path
AWS documents that authorization combines multiple policy types and that an explicit deny overrides an applicable allow. The combination rules vary with policy type and request context. AWS IAM policy evaluation logic
Review one request as a tuple:
principal × action × resource × context × applicable policies → decision
For each material path, capture:
| Dimension | Questions |
|---|---|
| Principal | User, role, role session, service principal, or federated subject? |
| Action | Read, write, permission-management, or role-passing consequence? |
| Resource | Which concrete ARN or resource class is reachable? |
| Context | Source identity, organization, network, tags, region, time, or session attributes? |
| Policies | Identity, resource, boundary, session, SCP, RCP, key, or trust policy? |
| Effect | What data, identity, execution, or control-plane state can change? |
AWS's request-context documentation describes how applicable policies compare principal, action, resource, and condition data from the request. AWS request-context documentation
Broad authority can hide without a visible wildcard
A policy can enumerate many sensitive actions and resources explicitly. It may contain no wildcard and still allow destructive administration. Conversely, a wildcard over a deliberately constrained resource namespace may present less reach than an explicit list covering production resources.
Other patterns also hide reach:
- resource policies that name a principal or session;
- role trust that accepts a broader federated subject than intended;
iam:PassRolecombined with a service action;- tag-based conditions when the same principal can modify the tags;
- KMS key policy and grant paths outside the identity policy being reviewed;
- organization policies that differ between accounts or organizational units;
- service-linked and cross-account behavior.
The question is not “does the document look broad?” It is “which high-impact effects are reachable, under which contexts, by which principal?”
Worked example: deployment plus role passing
Suppose a CI principal can update a compute service and pass one explicitly named runtime role. There may be no wildcard. If that runtime role can read all secrets and write to a production datastore, the deployment path can still obtain those capabilities by changing the workload image or configuration.
The exposure graph is:
CI principal → update service → pass runtime role → workload session → secrets/data
A line-by-line review of only the CI identity policy will miss the permissions attached to the passed role and the downstream resources that honor it. Remediation may require narrowing the pass-role condition, restricting deployment targets and artifacts, reducing the runtime role, and protecting the workflow that initiates deployment.
Use validators, then test meaningful paths
IAM Access Analyzer policy validation checks grammar and provides errors, security warnings, warnings, and suggestions. AWS IAM policy validation That is valuable static evidence. It should be combined with environment-aware analysis and controlled authorization tests for the requests that matter.
A useful review report should therefore include both:
- syntactic and best-practice findings; and
- effective access paths with principal, action, resource, context, policy sources, and consequence.
Practical takeaway
Keep wildcard checks because they are fast and often useful. Do not promote a wildcard count into an authorization verdict. Prioritize reachable high-impact effects, especially paths involving role assumption, role passing, resource policies, cryptographic keys, secret access, and production mutation.
Continue with Secure AWS Architecture: Decisions, Controls, Evidence, and Recovery for a broader control-and-evidence review.
Limitations
This Article does not calculate effective permissions for any AWS environment. The simplified policy fragments omit service-specific actions, conditions, and resource behavior. A real assessment must use current AWS service-authorization references, all applicable policies, and the deployed account and organization context.