Why do WAFs and API gateways miss broken function level authorization?

Why This Matters for Security Teams

broken function level authorization is a business-logic failure, which is exactly why WAFs and API gateways miss it. Those controls are good at rejecting malformed requests, known bad patterns, and some abusive traffic, but they cannot reliably determine whether a valid caller is allowed to invoke a specific function in a specific context. That gap becomes more dangerous when services expose admin-like actions through ordinary API calls. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats access enforcement as a system responsibility, not just an edge filter.

For NHIs, the problem is amplified because service accounts, API keys, and agents often carry broad privileges and can call functions at machine speed. NHIMG research shows the scale of the issue: Ultimate Guide to Non-Human Identities notes that 97% of NHIs carry excessive privileges, which means a request can look legitimate at the perimeter while still being out of policy at the application layer. In practice, many security teams discover this only after an internal abuse path has already been exercised, rather than through intentional authorization testing.

How It Works in Practice

Function level authorization must be enforced where the business action is decided, not only where traffic enters. A gateway can confirm that a token is present and that the request matches an allowed route, but it usually does not know whether the caller may approve invoices, export customer records, or trigger a destructive workflow. That decision needs application context: user or workload identity, tenant, object ownership, environment, risk score, and sometimes recent behaviour.

For agentic and automated workloads, this becomes even more important. An AI agent may chain tools, switch tasks, or generate requests that were never seen in pre-defined role maps. Static RBAC alone is too coarse when behaviour is dynamic. Current guidance suggests using runtime policy evaluation, with intent-aware rules checked on each action. That often means combining policy-as-code with application-layer checks and a workload identity primitive such as SPIFFE or OIDC, so the system can verify what the agent is, what it is trying to do, and whether that action is permitted now.

A practical control pattern looks like this:

• Authenticate the caller at the edge, but authorize the function inside the service.
• Map each sensitive action to a distinct policy rule, not just an API route.
• Use short-lived credentials and revoke them after the task or session ends.
• Log the decision context, including object, actor, action, and policy result.
• Test for privilege escalation paths, not only injection and schema violations.

This is especially relevant when investigating exposed credentials, such as in McDonald's McHire AI Chatbot Default Credentials, where the issue is not merely whether the gateway accepted the request, but whether the underlying function should have been reachable at all. These controls tend to break down when a monolith hides many business actions behind one endpoint, because the gateway cannot see the difference between safe and unsafe uses of the same request shape.

Common Variations and Edge Cases

Tighter function-level checks often increase latency, engineering effort, and policy maintenance, so organisations have to balance precision against operational overhead. There is no universal standard for this yet, especially for multi-tenant systems, event-driven back ends, and AI agents that generate requests on the fly.

One common edge case is partial authorization: the gateway validates the token, but the service still trusts a role claim without checking object ownership or workflow state. Another is hidden privilege via internal APIs, where low-risk public routes call high-risk internal functions. Best practice is evolving toward layered controls: edge filtering, service-level authorization, and behavioural baselines that can flag unusual sequences, such as a service account suddenly invoking export, delete, and privilege-change functions in one session.

For NHIs, this also means treating secrets and credentials as ephemeral where possible, rather than relying on long-lived static keys that remain valid far beyond the task that created them. When applications do not distinguish between an authenticated caller and an authorized function, broken access control persists even if perimeter controls appear healthy. NHIMG’s Ultimate Guide to Non-Human Identities is clear that excessive privilege and poor rotation are common failure modes, and the same pattern shows up in broken function checks.

Related resources from NHI Mgmt Group

• Why do API gateways struggle with broken object level authorisation?
• Broken Function Level Authorization
• What is the difference between role-based access and API key governance for NHI security?
• How should security teams govern API keys used for generative AI access?