A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
Expanded Definition
Broken Function Level Authorization is an application-layer access control defect where an authenticated caller can reach an administrative or peer-level function without the server validating that the caller is entitled to use that function. The weakness is not about whether the session is valid, but whether the action itself is authorised.
In NHI and API environments, this often shows up when service accounts, API keys, or agentic workflows can invoke endpoints that were intended for operators, tenants, or higher-trust roles. That makes it distinct from authentication failures and from simple role assignment mistakes. It is also closely related to OWASP API Security Top 10 concerns, especially where object-level and function-level checks are split across different services or gateways. No single standard governs this yet, so vendor and team usage can vary between “function level auth,” “endpoint authorization,” and “privilege enforcement.” The control expectation, however, is consistent: every sensitive function must enforce server-side authorization on every request.
The most common misapplication is assuming login state implies permission, which occurs when engineers protect a route with authentication middleware but skip a function-specific authorization decision.
Examples and Use Cases
Implementing function-level authorization rigorously often introduces more policy checks and test cases, requiring organisations to weigh operational simplicity against the risk of privilege escalation.
- An internal API lets a billing service account invoke NHI Mgmt Group-sensitive admin actions because the token is valid, even though the caller should only read invoices.
- An AI agent can trigger deployment rollback or secret rotation endpoints because the platform checks the agent’s session but not whether that specific function is allowed for autonomous execution.
- A partner integration can change tenant-wide settings through an endpoint exposed in the API gateway, while the backend never revalidates that the partner’s role permits global configuration changes.
- A help desk workflow can call user deprovisioning functions, but the service account behind the workflow is also able to disable privileged accounts because the function lacks a dedicated authorization rule.
- Teams align these checks with guidance from the NIST Cybersecurity Framework 2.0 by treating function access as an enforceable protection outcome, not a UI convenience.
Why It Matters in NHI Security
For NHIs, broken function level authorization can turn a narrowly scoped token into a broad administrative foothold. That matters because machine identities often operate continuously, integrate across many systems, and accumulate permissions faster than human review cycles can keep up. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which makes any function-level gap more dangerous: an over-entitled service account does not need many weaknesses before it can reach critical actions.
The governance impact is practical as well as technical. If a secret leaks, if an API key is shared across environments, or if an agent is delegated too much autonomy, attackers often look for the highest-value function the identity can reach rather than the most obvious resource. That is why function authorization should be tested with the same seriousness as secret storage, rotation, and offboarding. It also fits the layered access model described in zero-trust programs and in identity guidance from NIST Cybersecurity Framework 2.0.
Organisations typically encounter this issue only after a compromised service account or agent successfully performs an action that was assumed to be reserved for administrators, at which point function-level authorization 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-04 | Directly maps to NHI privilege and authorization failures for service identities. |
| NIST CSF 2.0 | PR.AC-4 | Addresses least-privilege access enforcement for users and machine identities. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous, explicit authorization for each requested action. |
Enforce server-side authorization on every sensitive NHI function and test it per role.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
