Risk-Based Controls

Risk-based controls are security measures that change based on the sensitivity of the data, the trustworthiness of the tool, and the business context of the interaction. In AI environments, they help organisations avoid blanket blocking while still limiting high-risk use cases. The goal is proportional enforcement, not uniform restriction.

Expanded Definition

Risk-based controls are enforcement rules that adjust security requirements according to context, rather than applying the same restriction to every request. In NHI and agentic AI environments, that context can include the sensitivity of the data, the trust level of the tool, the privilege of the identity, the action being requested, and whether the interaction crosses an organisational boundary.

This approach sits between rigid allow-or-block policies and fully permissive access. Used well, it supports proportionality: low-risk actions can proceed with lighter friction, while higher-risk actions trigger stronger checks such as step-up authentication, tighter scope, approval workflows, or tool restrictions. The idea aligns with NIST Cybersecurity Framework 2.0 thinking around adaptive governance, though no single standard governs this term yet and usage in the industry is still evolving.

NHIMG guidance treats risk-based controls as especially important where machine identities, secrets, and agent tooling move faster than manual review can keep up. See the Top 10 NHI Issues and the OWASP NHI Top 10 for the underlying control gaps that make contextual enforcement necessary. The most common misapplication is treating “risk-based” as a vague justification for inconsistent approvals, which occurs when teams lack a defined risk model or threshold logic.

Examples and Use Cases

Implementing risk-based controls rigorously often introduces design and monitoring overhead, requiring organisations to weigh smoother user and agent workflows against the cost of policy complexity and ongoing tuning.

• A service account can read low-sensitivity telemetry without friction, but the same identity must trigger stronger controls before accessing production customer records.
• An AI agent may call a documentation API freely, yet require approval or restricted scopes before invoking a payment, deployment, or deletion action.
• A third-party integration can use short-lived credentials for routine queries, while cross-tenant data export is blocked unless risk signals and policy conditions are satisfied.
• A human operator using a privileged console may get step-up checks only when the request targets a sensitive environment or an unusual geolocation.
• Policy engines can treat a trusted internal model differently from an externally hosted model that requests the same secrets or tool access.

For implementation patterns, the Ultimate Guide to NHIs — Standards is useful for mapping contextual checks to identity lifecycle controls, while the NIST Cybersecurity Framework 2.0 provides a broader risk-management lens. Typical use cases include conditional API access, tool-level guardrails for agents, secret exposure controls, and differentiated approval paths for high-impact operations.

Why It Matters in NHI Security

Risk-based controls matter because NHI ecosystems are large, fast-moving, and often over-privileged. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which means blanket access is not only inefficient but dangerous. If controls do not vary with context, benign automation gets blocked unnecessarily while high-risk actions slip through with the same baseline treatment.

This is also where governance becomes operational. Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities by Oasis Security & ESG. That statistic shows why static policies fail in environments where secrets, tokens, and service accounts are continuously reused. Risk-based controls help reduce blast radius, but only if the risk signals are accurate and the policy exceptions are tightly governed.

Organisations typically encounter the true value of risk-based controls only after an abnormal tool action, privilege misuse, or secrets-related incident exposes how much damage a uniform policy allowed, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do proxy-based controls miss part of enterprise AI risk?
• Why do traditional IAM controls miss browser-based AI risk?
• What breaks when firms use blanket de-risking instead of risk-based AML controls?
• Why do merchant onboarding controls need to be risk based?