Finding risky access is detective control, which tells you where exposure already exists. Preventing risky access is preventive control, which blocks the exposure from being created in the first place. In AWS, policy validation in CI/CD is the more durable answer because it stops overbroad resource policies before they become standing privilege.
Why This Matters for Security Teams
Finding risky access and preventing risky access are different operating modes, and the gap between them is where most exposure accumulates. Detective control tells security teams where an NHI, service account, API key, or resource policy is already too broad. Preventive control stops that state from being introduced, which is why policy validation in CI/CD is the more durable answer for AWS. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes “find it later” an expensive posture if overbroad access is becoming the default. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the governance context.
Security teams often confuse inventory with control. A dashboard may reveal who can assume a role, attach a policy, or use a secret, but that does not stop the next deployment from widening access again. Current guidance from NIST Cybersecurity Framework 2.0 favours continuous improvement and risk reduction, but the operational win comes from preventing bad configurations before they become standing privilege. In practice, many security teams encounter the blast radius of risky access only after a workload or pipeline has already used it.
How It Works in Practice
Detective controls look for exposure after the fact: unused permissions, broad resource policies, stale keys, or identities that violate least-privilege expectations. Preventive controls move that decision upstream. For AWS, that means validating IAM policies, trust relationships, permission boundaries, and resource-based policies before merge or release, then blocking builds that introduce excessive access. This is where policy-as-code, pull request checks, and CI/CD gates become more durable than periodic reviews, because they catch the problem at the moment it is created. The Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — Why NHI Security Matters Now frame why this matters operationally.
- Use static analysis to flag wildcard actions, wildcard resources, and cross-account trust that is broader than required.
- Require approval for policy changes that increase privilege, especially for deployer roles and workload identities.
- Test policies against known abuse paths, not just syntax, so valid but dangerous policies are rejected.
- Feed findings into remediation workflows so the same risky pattern cannot re-enter through another pipeline.
This is also the better fit for ephemeral and machine-driven access because the risk is created repeatedly at scale, not just once. A control that only discovers overpermission after deployment still leaves a standing window for misuse, and that window is exactly what attackers exploit. These controls tend to break down when organizations allow direct console edits outside CI/CD because policy drift bypasses the preventive gate.
Common Variations and Edge Cases
Tighter preventive control often increases delivery friction, requiring organisations to balance release speed against assurance. That tradeoff is real, especially where legacy applications depend on broad AWS permissions or where multiple teams share one pipeline. In those cases, current guidance suggests starting with the highest-risk policy classes first, then expanding coverage as patterns stabilise. There is no universal standard for this yet, but the direction of travel is clear: reduce the chance that risky access ever becomes live.
Edge cases matter. Some teams still need detective monitoring because third-party changes, emergency break-glass access, and manually created resources can bypass the normal release path. In those environments, preventive controls should be paired with continuous detection and rapid rollback rather than treated as a complete substitute. NHI Mgmt Group data from the 52 NHI Breaches Analysis and the broader Top 10 NHI Issues show why this layered approach remains necessary.
For most teams, the practical answer is simple: find risky access for visibility, prevent risky access for resilience, and treat detection as the backstop rather than the primary control. That is especially true when secrets, service roles, and agent-driven workloads can propagate excessive privilege faster than a review cycle can catch it.
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-03 | Addresses excessive privilege and risky NHI exposure before abuse occurs. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access control for identities and workloads. |
| NIST Zero Trust (SP 800-207) | Zero Trust favors continuous verification over assumed trust for access decisions. |
Block overbroad NHI policies in CI/CD and remove standing privilege before deployment.
Related resources from NHI Mgmt Group
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between protecting applications and protecting access?
- What is the difference between access review and continuous monitoring for AI integrations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
