Toxic Permission Combinations
Identify permissions that become more dangerous when combined.
A security review that evaluates each IAM action separately can miss an important class of risk. Two permissions may appear manageable on their own but create a much more powerful capability when they exist together. Securitain calls these toxic permission combinations.
The core idea
s3:GetObject + kms:Decrypt ↓ Potential ability to read encrypted S3 data
Neither permission tells the whole story alone. The security consequence appears when the identity can perform both parts of the operation within the applicable AWS authorization context.
Where to find toxic-combination findings
Toxic combinations are currently surfaced as IAM findings.
Then filter by category: toxic_combination. There is no dedicated Toxic Combinations navigation item today — a toxic-combination finding uses the standard Securitain finding workflow: review severity, inspect affected entity, inspect evidence, understand the security consequence, review remediation, and govern the finding through the normal finding lifecycle.
Why individual permission review can fail
Imagine an identity with Permission A and Permission B. A rule checking only Permission A may decide it is not sufficient to create a serious outcome. A separate rule checking only Permission B may reach the same conclusion. But:
Permission A + Permission B ↓ Security-relevant capability
This is why permission relationships matter.
Example: encrypted data access
An identity may have both s3:GetObject and kms:Decrypt. When the relevant S3 objects are encrypted with a KMS key the identity is also authorized to use, the combination can enable access that would not be understood by looking at either permission alone.
This is a conceptual example. Actual access still depends on resource policy, KMS key policy, resource scope, conditions, explicit denies, encryption configuration and request context.
Example: code modification and secret access
Consider a workload-related identity with the ability to modify executable workload code and the ability to read sensitive secrets. Together, those capabilities can create a more serious application-security concern than either capability viewed independently. The exact exploitability depends on the workload, role, resource restrictions and runtime configuration.
Example: visibility reduction plus privileged change
A particularly important class of security combination is the ability to reduce security visibility combined with the ability to make privileged changes. For example, an identity that can modify logging or detection controls and also make powerful IAM changes may create a higher-risk operational scenario.
Securitain does not publish the complete internal action taxonomy used to identify this category.
Example: resource-policy modification
Another class of combination can involve the ability to change a resource policy combined with the ability to access the resource. In some environments, this can create a path toward broader exposure or data movement. Again, actual consequence depends on service-specific authorization behavior and applicable restrictions.
What a toxic-combination finding means
Securitain identified a supported combination of permissions on an identity that can create a more serious security capability when the permissions are considered together.
It does not mean:
- compromise has already occurred
- the permissions have been used maliciously
- every possible resource in the service is reachable
- remediation is always to remove both permissions
Why severity can be higher than either permission alone
The combined capability can be more consequential than the individual actions.
Permission A Medium concern Permission B Medium concern A + B High concern (combined consequence)
This is a useful reason to investigate toxic combinations separately from single-permission findings. Securitain does not disclose its internal severity rules.
How to investigate a toxic combination
- 1
Identify the principal
Determine whether the affected principal is human, workload, CI/CD, administration or federated role.
- 2
Review the actions
Understand what each permission allows.
- 3
Review scope
Check whether the permissions are limited to a specific resource, a set of resources, or all resources.
- 4
Review conditions
Determine whether context restrictions limit the combination.
- 5
Review resource controls
For data-access scenarios, inspect resource and encryption policies where supported.
- 6
Check actual use
Where usage evidence is available, determine whether the permissions are actively required.
- 7
Break the unnecessary combination
The remediation objective is often to remove or constrain the permission that is not operationally necessary rather than blindly removing every action in the pair.
Remediation patterns
Depending on the finding, remediation can include:
- narrowing resource scope
- adding conditions
- splitting duties across identities
- removing unused actions
- separating security-administration capabilities from workload permissions
- limiting KMS access
- limiting IAM mutation
- preventing workloads from modifying their own privilege boundary
- tightening resource policies
Always validate operational impact before changing production authorization.
Toxic Combinations vs Privilege Escalation
Toxic Permission Combination
Do multiple permissions create a more dangerous capability when held together?
Focused on paired/grouped permissions on one identity.
Privilege Escalation
Can the identity use its available capabilities to reach a stronger identity or privilege outcome?
Focused on reaching a stronger capability or identity.
A toxic combination may support an escalation path, but not every toxic combination necessarily results in privilege escalation. For example, S3 read + KMS decrypt can create sensitive data exposure without necessarily creating administrator privilege.
Toxic Combinations vs Identity-to-Data
Toxic combinations focus on permission combinations. Identity-to-Data focuses on which identities can reach supported sensitive data resources. When the toxic combination involves data-access permissions, the two views can reinforce each other.
Evidence and limitations
Toxic-combination analysis depends on supported effective-permission information and available resource/security context. Actual exploitability can depend on policy scope, resource policy, trust, key policy, conditions, explicit deny, workload configuration and service-specific behavior.
Important
Limitation
Related guides