The gap between what an identity can see in an interface and what it can actually execute in the backend. In API security, this mismatch is dangerous because attackers can discover functions through traffic analysis, then manipulate requests to trigger actions that should be restricted.
Expanded Definition
Function access mismatch describes a control gap between what an identity can discover in a client, portal, or API schema and what it should be allowed to execute in the backend. In NHI and agentic AI environments, this often appears when interfaces expose more actions than policy actually intends, or when backend handlers trust the caller’s route, method, or hidden parameters instead of enforcing authorization on the function itself.
This is closely related to broken object and function level authorization, but the NHI context makes the risk sharper because service accounts, API keys, and agents can operate at machine speed and chain requests across systems. The OWASP Non-Human Identity Top 10 helps frame this as an authorization design problem, not just an input validation issue. Definitions vary across vendors on whether the term belongs under API security, IAM, or application security, but the operational meaning is consistent: visibility and execution are not aligned.
The most common misapplication is assuming that hiding a button, route, or menu item prevents misuse, which occurs when backend authorization is not enforced on the actual function.
Examples and Use Cases
Implementing function-level authorization rigorously often introduces latency and design overhead, requiring organisations to weigh stronger control separation against faster development and simpler client logic.
- An internal agent can enumerate admin-only endpoints from an OpenAPI document, then call a privileged action because the backend checks only whether the request is authenticated, not whether the function is authorized.
- A service account used for billing can view report-generation controls in a UI, but a manipulated request reaches a deletion or export function that was never intended for that identity.
- A third-party integration can observe hidden verbs during normal traffic and replay them later, which is why NHI exposure to third parties remains a governance concern in the Ultimate Guide to NHIs.
- In an AI workflow, a model-enabled agent may see tool descriptions for multiple actions, but only a subset should be executable under the policy boundary described in Ultimate Guide to NHIs — Key Challenges and Risks.
- API testing teams use the NIST SP 800-53 Rev 5 Security and Privacy Controls to map least privilege, then verify each function requires explicit authorization rather than relying on interface hiding.
Why It Matters in NHI Security
Function access mismatch matters because NHI compromise rarely starts with a dramatic break-in; it often starts with an overexposed capability that should never have been callable in the first place. When an API key, service account, or autonomous agent can infer backend behavior and then invoke it out of role, the result is privilege escalation, unauthorized data movement, or destructive automation at machine speed.
This is especially relevant given NHIMG research showing that 97% of NHIs carry excessive privileges and that only 5.7% of organisations have full visibility into their service accounts, as reported in the Ultimate Guide to NHIs. The control lesson is simple: if execution is not checked where the function is invoked, hiding it in the interface provides no meaningful protection. Practitioners should also align function checks with the expectations in the OWASP Non-Human Identity Top 10 so that every callable action has an explicit policy decision.
Organisations typically encounter this failure only after an incident review reveals that a benign-looking identity was able to trigger a privileged backend action, at which point function access mismatch 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 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-01 | Covers authorization and access-control failures that expose callable NHI functions. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance requires permissions to match actual allowed operations. |
| NIST SP 800-63 | AAL2 | Assurance is weakened when authentication strength is not matched by function authorization. |
| NIST Zero Trust (SP 800-207) | 3e | Zero Trust requires continuous, explicit authorization for each resource and action. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems must restrict tool use to the minimum set of permitted actions. |
Enforce function-level authorization for every NHI action, not just interface-level hiding.
