Least Privilege

Reduce permissions that appear broader than the identity's observed operational need.

AWS permissions tend to accumulate over time. A role may receive temporary access for a project. A developer may move teams. A service may stop using an AWS capability. A deployment process may be redesigned. The policy often remains.

Least-privilege analysis helps identify where granted access may be broader than the evidence suggests is required.

Where to find Least Privilege

The current view is named Least Privilege Advisor. Depending on available evidence, an opportunity can show context such as identity, identity type, granted actions, used actions, unused actions, unused services, last activity, recommendation and risk-prioritization context.

Least privilege is not simply “remove unused permissions”

A permission that has not appeared in recent activity can still be legitimately required. Examples:

• disaster-recovery action
• quarterly process
• incident-response permission
• infrequent deployment capability
• failover action
• annual administrative task

Least-privilege decisions should combine technical evidence with workload and business knowledge.

Granted permissions

Granted permissions represent the actions currently available to the identity based on the supported permission analysis.

Identity
   ↓
Policies
   ↓
Granted Actions

Use Effective Permissions where supported to provide a more realistic permission baseline than attached-policy text alone.

Usage evidence

Securitain can use supported AWS evidence to add context around permission usage. Depending on assessment capability, this may include:

CloudTrail activity

Provides action-level evidence for supported AWS API activity.

Service last accessed

Provides service-level usage information for supported identities.

Access-key usage

Can provide additional activity context for IAM identities using access keys.

Why evidence quality matters

A recommendation derived from strong evidence deserves different weight than one derived from policy text alone.

Example: unused service

A role has permissions across S3, Lambda, DynamoDB, SNS and KMS. Observed usage evidence suggests it currently uses S3, Lambda and DynamoDB. Securitain may identify SNS and KMS as services deserving least-privilege review.

This does not automatically mean the permissions should be removed. The owner should confirm whether those services are required for backup, failover, deployment, infrequent processing or emergency operations.

Example: broad developer role

A developer role that historically accumulated permissions for S3, EC2, Lambda, IAM, Secrets Manager and RDS — where activity evidence indicates normal use only covers a subset — becomes a candidate for narrowing.

Review should focus first on high-consequence unused capabilities such as IAM mutation, PassRole, secret access, production data access and security-control changes. Unused permission count alone should not define priority.

Last activity

Last activity can help determine whether an identity or permission set is still operationally relevant. However:

• not all AWS activity is observable through the same source
• historical coverage may be limited
• service-last-accessed data has its own semantics
• an identity can be intentionally dormant

Use activity timestamps as context, not a binary decision.

Risk prioritization

The Least Privilege Advisor can include a risk score. Interpret it as a prioritization aid. Do not interpret it as exploitation probability, compliance score, exact percentage of unnecessary permissions or a guarantee of safe permission removal.

Least Privilege vs Effective Permissions

Effective Permissions
        ↓
Granted Capability
        +
Usage Evidence
        ↓
Least-Privilege Opportunity

Least Privilege vs Credential Inactivity

An old or inactive access key is a credential-security issue. An unused permission is an authorization issue. They can be related but should not be treated as the same condition.

Safer least-privilege workflow

Identify opportunity
      ↓
Validate owner / workload
      ↓
Review historical evidence
      ↓
Narrow access
      ↓
Test application
      ↓
Observe
      ↓
Reassess

Least privilege should be treated as an engineering process, not a one-click cleanup operation.

Investigating a least-privilege opportunity

1. 1

   Identify the identity

   Determine user or role, owner, workload and environment.

2. 2

   Review granted actions

   Identify broad or high-consequence access — IAM mutation, PassRole, secret access, production data, security controls.

3. 3

   Review usage evidence

   Check what CloudTrail, service-last-accessed and access-key activity is available.

4. 4

   Review unused services and actions

   Focus on the capabilities most likely to reduce security consequence if narrowed.

5. 5

   Check operational edge cases

   Ask the owner about infrequent operations, deployment, DR, failover and incident response.

6. 6

   Narrow carefully

   Prefer controlled policy changes over aggressive removal.

7. 7

   Reassess

   Run a later assessment to verify the new posture.

Evidence and limitations

Least-privilege analysis can be affected by:

• CloudTrail coverage and retention window
• service-last-accessed availability
• access-key usage visibility
• effective-permission coverage
• infrequent workload behavior
• multi-account workflows
• scan freshness

Related guides