Sensitive Permissions

Focus on AWS actions whose misuse can create a larger security consequence.

Not every allowed AWS action deserves equal attention. For example, ec2:DescribeInstances and iam:PassRole are both permissions, but they can create very different security outcomes. Securitain classifies supported high-consequence actions so teams can identify which principals deserve deeper investigation.

Where to find Sensitive Permissions

The current view lists sensitive permissions associated with supported IAM entities. Current table fields include:

• Entity
• Action
• Category
• Source Policy
• Severity

What makes a permission sensitive?

A permission can be sensitive because it can contribute to capabilities such as:

• modifying identity or permission configuration
• escalating privileges
• accessing secrets or encryption functions
• reading or exporting sensitive data
• modifying security controls
• creating or modifying compute or deployment infrastructure
• changing network exposure
• changing organization or workforce-access controls

The exact risk depends on resource scope, conditions, target resource and other permissions held by the principal.

Sensitive does not mean exploitable

For example, iam:PassRole may be sensitive, but actual consequence depends on which roles can be passed, which AWS services the principal can operate, role trust and service behavior, resource scope and conditions. Use Privilege Escalation for path analysis.

Representative categories

The current Securitain sensitive-permission taxonomy includes multiple categories. Representative public concepts include:

• IAM / permission mutation
• privilege escalation
• secret or encryption-key access
• data access / exfiltration potential
• security-control modification
• infrastructure / deployment control
• network exposure
• organization / identity administration

Example: IAM mutation

Permissions that can create or modify IAM policies and identities deserve attention because they can alter the authorization model.

Current permission
      ↓
Modify IAM
      ↓
Potentially broader future permission

The exact action and exploitability depend on scope and conditions.

Example: PassRole

iam:PassRole allows a principal to pass an IAM role to supported AWS services when the AWS authorization requirements are met.

Developer
   ↓
iam:PassRole
   ↓
Execution Role
   ↓
AWS Service

Sensitive Permissions identifies the action. Privilege Escalation evaluates supported paths.

Example: secret access

Actions related to Secrets Manager, SSM parameters and KMS decrypt capability can be security-sensitive because they may expose credentials or protected application data. Actual access remains resource and condition dependent.

Example: security-control modification

Permissions that can modify or disable logging, security monitoring, configuration recording or key availability can increase operational security risk. A sensitive-permission classification does not mean the control has actually been disabled.

Example: organization administration

Actions that can alter AWS Organizations, permission-set assignments or central workforce access can have enterprise-wide consequence. Use Organizations & SCPs and IAM Identity Center for the corresponding governance context.

Source Policy

The current Sensitive Permissions result identifies the policy source associated with the action. For group-derived permissions, this can show:

DeploymentPolicy

DeveloperInlinePolicy (inline)

AssumeRolePolicy (via group Developers)

Group-derived permissions

Consider:

alice
  ↓ member of
Developers
  ↓ attached policy
DeploymentPolicy
  ↓
iam:PassRole

This helps avoid the common IAM mistake of looking only at directly attached user policies when auditing who holds a sensitive capability.

Resource scope

A sensitive action scoped to Resource: "*" can have a different risk profile from the same action restricted to one specific resource. The Sensitive Permissions result model preserves resource-scope context. Action name alone does not determine final severity.

Conditions

Policy conditions can materially constrain sensitive actions. A sensitive action combined with a specific resource and a restrictive condition can be less dangerous than the same action with broad scope. The current analysis preserves whether policy-statement conditions are represented.

Sensitive vs Effective Permissions

For best investigation, use them together.

Sensitive vs Toxic Combinations

Sensitive vs Privilege Escalation

A sensitive permission such as iam:CreatePolicyVersion is a triage layer — it flags the action as consequential. Privilege Escalation asks whether the permission can be used in the current context to obtain a stronger capability — it is a consequence and path layer.

Investigating a sensitive permission

1. 1

   Identify the principal

   Determine whether it is a user, role or group-derived user.

2. 2

   Review the action

   Understand its AWS semantics and what it could enable.

3. 3

   Review source policy

   Determine where the permission came from.

4. 4

   Review scope

   Look at resource constraints — wildcard or specific resource?

5. 5

   Review conditions

   Determine whether context limits the permission.

6. 6

   Review effective access

   Use Effective Permissions to understand remaining available permissions.

7. 7

   Review combinations and paths

   Use Toxic Permission Combinations, Privilege Escalation and Blast Radius.

8. 8

   Review business need

   Then remediate or apply least-privilege scoping as appropriate.

Public taxonomy boundary

Evidence and limitations

Sensitive-permission results depend on:

• collected policy documents and attachments
• inline policies and group membership
• recognized action patterns
• scan freshness

A sensitive action can appear in a policy while final access is constrained elsewhere by boundaries, SCPs or denies. Use Effective Permissions and related views for consequence analysis.

Related guides