The dangerous condition where several individually reasonable permissions become high risk when held by the same identity. In cloud governance, adjacency matters because create, update, and delete actions can combine into full lifecycle control over workloads, clusters, or AI workspaces.
Expanded Definition
Permission adjacency describes a risk pattern in which a set of individually defensible entitlements becomes dangerous when concentrated in one NHI, AI agent, or service account. In practice, the issue is not any single permission, but the operational path created when create, update, delete, read, and execute rights combine into unintended control. This is especially relevant in cloud IAM, Kubernetes, CI/CD, and agentic systems where identities can chain actions across resources.
Definitions vary across vendors, but the security concern is consistent: adjacency turns local least-privilege decisions into system-level exposure. The OWASP Non-Human Identity Top 10 treats excessive or mis-scoped NHI permissions as a core governance problem, while NHI Mgmt Group documents how broad privilege concentrations amplify breach impact in real environments through the Ultimate Guide to NHIs — Key Challenges and Risks. The most common misapplication is reviewing permissions one at a time, which occurs when teams approve each action as reasonable without testing the combined effect of the full entitlement set.
Examples and Use Cases
Implementing permission adjacency controls rigorously often introduces review overhead, requiring organisations to weigh faster delivery against a more complete analysis of what an identity can do end to end.
- A deployment bot can create workloads, update configuration, and delete old releases. Each permission seems normal, but together they allow full lifecycle manipulation of production services.
- An AI agent with access to a vector store, a secrets API, and a runtime executor may be able to retrieve sensitive context and then act on it, even if no single permission appears overbroad.
- A Kubernetes automation identity that can patch roles, create service accounts, and bind permissions can escalate into cluster-wide control through chained actions.
- A CI/CD pipeline identity that can read build artifacts, write deployment manifests, and trigger rollouts can alter what gets shipped without direct approval from a human operator.
- Service account reviews informed by NHIMG research on NHI risk and the OWASP Non-Human Identity Top 10 often reveal that the risky part is the permission combination, not the individual grant.
Why It Matters in NHI Security
Permission adjacency is a breach amplifier because adversaries rarely need exotic exploits when ordinary permissions can be composed into destructive action. Once an NHI is compromised, adjacent privileges may let an attacker pivot from read-only access to secret extraction, from deployment access to code tampering, or from routine automation to irreversible deletion. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which is why adjacency analysis is not optional in mature governance programs.
This concept also aligns with zero trust and identity assurance thinking in NIST SP 800-207 Zero Trust Architecture and the permission scoping concerns reflected in CISA Zero Trust guidance. Organisations typically encounter the consequences only after a compromised service account is used to chain routine privileges into outage, data exposure, or unauthorized infrastructure changes, at which point permission adjacency becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Focuses on excessive NHI privilege and risky permission combinations. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management directly addresses adjacency risk. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits blast radius when identities have compound access paths. |
Review each NHI for chained capabilities, not just isolated permissions, and remove any privilege overlap.
Related resources from NHI Mgmt Group
- When should organisations revoke an OAuth grant or third-party app permission?
- What is the difference between client identity and permission scope in MCP governance?
- Why do permission boundaries fail as a scale control for cloud access?
- What is the difference between SCPs and permission boundaries in AWS governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
