Preventative Control

Expanded Definition

A preventative control is a safeguard that blocks an unwanted action before it can occur. In NHI and IAM programmes, it is most often used to constrain execution authority, isolate sensitive duties, and keep a compromised identity from reaching the action in the first place.

For Non-Human Identities, preventative controls usually operate as policy, architecture, or workflow constraints rather than after-the-fact detection. That includes separation of duties, least privilege, approval gates, network and workload boundaries, and cryptographic enforcement around secrets and tokens. In a zero trust model, the control is not based on assumed trust in the workload, but on explicit verification and narrow authorization, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG’s guidance in Ultimate Guide to NHIs — Standards.

Industry usage is still evolving in some agentic AI environments, where vendors may call runtime filters, approval workflows, and policy guards “preventative” even when they only reduce likelihood rather than fully block execution. The most common misapplication is treating logging or alerting as preventative control, which occurs when organisations confuse post-event visibility with pre-event prevention.

Examples and Use Cases

Implementing preventative controls rigorously often introduces workflow friction and engineering overhead, requiring organisations to weigh reduced blast radius against slower delivery and more approvals.

• Splitting code deployment and production approval across separate NHIs so one service account cannot both push and release changes, a classic separation-of-duties pattern.
• Using a secrets manager and short-lived credentials so an application cannot read long-term API keys directly from source code, build logs, or config files. NHIMG notes that 96% of organisations still store secrets outside secrets managers in vulnerable locations, which makes this control especially relevant; see Ultimate Guide to NHIs — Standards.
• Enforcing just-in-time elevation for privileged automation so a bot only gains sensitive rights for a narrow task window, then loses them automatically.
• Applying policy gates in an agentic workflow so an AI agent must obtain explicit approval before it can invoke payment, deletion, or identity-altering tools, consistent with the NIST Cybersecurity Framework 2.0.
• Restricting token scope at issuance so a third-party integration can only read one dataset or call one API, even if the token is later exposed.

These use cases are most effective when paired with strong identity inventory and lifecycle governance, because a control cannot prevent abuse if the organisation does not know which service accounts, workloads, or agents exist.

Why It Matters in NHI Security

Preventative controls matter because NHI compromise is often about speed and reach. Once an API key, workload identity, or agent credential is exposed, an attacker can act immediately unless there is a control that blocks the next step. NHIMG reports that 97% of NHIs carry excessive privileges, which makes preventive containment critical; see the broader risk context in Ultimate Guide to NHIs — Standards.

For governance teams, the main question is not whether a control exists in policy, but whether it actually stops unauthorized execution in production. That is especially important for secrets, service accounts, and agentic tools, where post-incident detection is often too late to prevent lateral movement, data access, or destructive changes. Preventative controls are also the practical expression of zero trust in NHI environments, because every sensitive action should be constrained before it executes rather than trusted after authentication.

Organisations typically encounter the need for preventative controls only after a service account, token, or AI agent is abused, at which point the absence of pre-execution barriers becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Control Monitoring
• What is the difference between patching and blast radius control?
• What is the difference between source control leakage and SharePoint secret exposure?
• How should security teams control overprivileged NHIs?