Risk Function

Expanded Definition

A risk function is a discrete action or permission that becomes risky when paired with another action, condition, or context. In identity governance, the unit matters because toxic combinations are often invisible if teams only review broad roles or titles. Definitions vary across vendors, but the practical use is consistent: break entitlements into their underlying functions so conflicts can be detected before access is granted.

This matters most where service accounts, API keys, CI/CD automation, and agent tool access intersect. A function such as deploying code is not inherently dangerous, but deploying code plus approving production changes plus reading secrets can create a meaningful exposure path. That is why NHI governance teams often map functions against least privilege and separation of duties controls, then review combinations across workflows and applications. The NIST Cybersecurity Framework 2.0 reinforces this kind of access governance even if it does not use the phrase risk function.

NHIMG’s research on Top 10 NHI Issues shows why function-level analysis is essential: excessive privilege and poor visibility are recurring patterns in compromise pathways. The most common misapplication is treating a role name as proof of safety, which occurs when overlapping functions inside that role are never decomposed and tested for toxic combinations.

Examples and Use Cases

Implementing risk functions rigorously often introduces review overhead, requiring organisations to weigh faster provisioning against stronger separation of duties.

• A build service account can publish artifacts, while a release workflow can promote them. Those are separate functions, but together they may allow unreviewed code to reach production.
• An AI agent can read tickets and call internal tools, but if its functions also include secret retrieval, the combination can expose credentials after prompt injection or workflow abuse.
• A developer may have the function to open a pull request and another team member may approve merges. If one identity holds both functions, governance should flag the toxic combination.
• An NHI used for cloud automation may have both infrastructure creation and policy exception functions. That pairing can bypass guardrails unless separated and monitored.
• In Zero Trust design, functions are reviewed at the point of use, not just at account creation, so the key NHI challenge set can be addressed in real workflows rather than only in policy documents.

For identity teams, the useful question is not “who has access” but “which functions, when combined, create an unacceptable path.” That framing aligns with why NHI security matters now and with standard access control thinking in the NIST CSF.

Why It Matters in NHI Security

Risk functions are critical because NHI compromise rarely happens through a single permission. It usually emerges from a chain: a token is exposed, a workflow can be altered, a secret can be read, and a production action can be triggered. If those functions are never decomposed, toxic combinations remain hidden inside service accounts, CI/CD pipelines, and agentic workflows. NHIMG research indicates that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which underscores how often function-level weaknesses are operationalised by attackers.

This is why governance must extend beyond inventory and into action-level analysis. Function mapping helps teams identify where JIT access, PAM workflows, or agent tool permissions create intersecting exposure. It also supports stronger incident response because responders can revoke the exact function chain that enabled the abuse rather than disabling every adjacent account. Industry practice is still evolving here, but the direction is clear: function decomposition is becoming essential to NHI visibility and control.

Organisations typically encounter the real consequence only after a production incident or secret exposure, at which point risk function analysis becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why is DevOps such a significant source of NHI risk?
• What is the biggest long-term risk of unmanaged NHIs multiplying at exponential rates?
• What is secrets sprawl and why does it create security risk?
• What is credential injection risk and how does it occur?