Toxic Permission Combination

A toxic permission combination is a set of individually acceptable permissions that becomes risky when combined, such as approve, modify, and audit in the same account. The danger comes from cumulative capability, not a single obviously privileged role.

Expanded Definition

A toxic permission combination is not about a single role being obviously overpowered. It describes a permission set that appears reasonable in isolation but creates unsafe cumulative authority when the same NHI, AI agent, or service account can approve, change, and inspect the same workflow. In NHI governance, the risk often emerges where RBAC is coarse, JIT is missing, or privileged workflows are split across systems without separation of duties.

Definitions vary across vendors, but the security principle is consistent: combine enough individually legitimate permissions and the account can bypass intended controls. This is especially relevant in agentic systems where tool access can let an AI agent chain actions across code, cloud, and ticketing systems. The OWASP Non-Human Identity Top 10 frames this as a governance problem, not just an access-control problem, because the damage comes from what the identity can do end-to-end. The most common misapplication is treating each permission as harmless during review, which occurs when reviewers fail to evaluate cross-system capability and effective privilege escalation.

Examples and Use Cases

Implementing toxic-permission review rigorously often introduces workflow friction, requiring organisations to weigh operational speed against stronger separation of duties and auditability.

• A deployment service account can trigger a release, approve the change record, and edit rollback evidence, allowing it to conceal a bad deployment after the fact.
• An AI agent granted read access to incident data, write access to tickets, and approval rights in a chatops tool can self-authorise remediation without human review.
• A CI/CD identity can modify build definitions, access signing secrets, and publish artifacts, creating a path from code change to trusted release.
• A finance automation account can create payments, reconcile exceptions, and alter logs, which turns a routine processor into a fraud-enabling identity.
• NHIMG notes that excessive privilege is widespread in NHIs, with 97% carrying excessive privileges in the Ultimate Guide to NHIs, which is why permission combinations must be reviewed as a whole rather than per entitlement. This maps to the OWASP guidance on stacked authority and effective privilege.

Why It Matters in NHI Security

Toxic permission combinations are dangerous because NHI compromise is rarely dramatic at first. The account may only hold normal-looking permissions, but once one credential or token is stolen, the attacker can pivot through allowed actions that should never coexist in one identity. That is why the issue shows up in secret theft, service-account abuse, agent prompt injection fallout, and post-incident privilege discovery.

NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, while 96% of organisations store secrets outside secrets managers in vulnerable locations. When those identities also carry toxic combinations, the blast radius expands quickly. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both emphasize visibility and least privilege as core controls for reducing this risk. Organisations typically encounter the consequence only after an incident review reveals that a single identity could both alter controls and validate its own actions, at which point toxic permission combination becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when a toxic combination leads to fraud or audit findings?
• Toxic Access Combination
• Toxic Scope Combination
• Toxic Entitlement Combination