Coarse API authorisation fails when one policy treats very different actors as if they were the same. Humans, service accounts and AI agents need different privilege boundaries, because each may request different objects, functions and data volumes. If the API cannot distinguish those contexts, broken object and function authorisation becomes much easier to exploit.
How coarse API authorisation turns different actors into the same risk
Coarse api authorisation fails when humans, workloads and agents are all forced through one shared access model. The immediate problem is not just excess access, it is loss of context: a policy that cannot distinguish who is calling, why they are calling, and what level of delegation they hold will inevitably overreach in some places and under-protect in others.
That matters because the access pattern is different for each actor. A human user may need interactive, low-volume access to a narrow object set, a workload may need machine-to-machine access to a bounded service path, and an AI agent may need delegated, task-scoped authority that changes by step and tool.
Authorisation Models Guide is useful here because the answer often depends on whether a coarse role model is being asked to do the work of policy, context and delegation at the same time.
What fails first: object, function and flow separation
When authorisation is too coarse, the first thing to break is separation. Object-level control fails when one caller can read or modify records it should never see, function-level control fails when the same caller can invoke privileged operations, and flow-level control fails when broad access lets an actor chain harmless-looking calls into a harmful outcome.
This is why coarse policy becomes dangerous in mixed human and non-human access. The control may look consistent on paper, but the actual permission shape no longer matches the actor. That creates the classic conditions for broken object level authorisation and broken function level authorisation, especially where APIs expose both data retrieval and state-changing actions.
The right control question is whether the policy is expressive enough to separate subject, action, object and context. If it is not, the API may still authenticate callers correctly while authorising the wrong thing.
OWASP API Security Top 10 is the clearest external reference for this failure pattern because broken authorisation is one of the core API abuse paths it is designed to prevent.
Why mixed human, workload and agent access needs different governance
The design problem is not merely that the actors are different, it is that their trust models are different. Humans can be approved through interactive workflows, workloads should usually carry tightly bounded technical identity, and agents often need delegated authority that is both temporary and observable. Treating those cases as interchangeable creates permission creep, weakens accountability and makes revocation harder when the access path changes.
In practice, coarse policy also obscures auditability. If a single API policy covers people, services and agents, investigators may see a successful request but not the reason the caller was allowed to perform it. That makes exceptions harder to review and makes it easier for overbroad access to survive unnoticed.
AI Agent Authorisation Guide directly addresses the agent side of this problem, where task-scoped access and per-action decisions are needed instead of blanket privileges.
SPIFFE workload identity specification is relevant on the workload side because machine-to-machine access becomes easier to govern when the caller has a strong, distinct workload identity rather than a generic shared credential shape.
Risk and Threat Considerations
Coarse authorisation increases the blast radius of a single credential or policy mistake. An attacker who compromises one human account, workload credential or agent token can often move through object, function and bulk-data paths that were never meant to be equivalent, turning a narrow foothold into broad misuse.
Failure mechanism: the API policy cannot distinguish actor class, delegation state or request intent, so one allowed path can be repurposed into broader data extraction, privilege abuse or unauthorized function execution.
Impact: the result is higher odds of mass data exposure, unauthorized state change, abuse at scale and slower containment because defenders cannot easily see which access path was legitimately intended and which was not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Coarse API policy creates object-level overreach across actors. |
| API5 — Broken Function Level Authorization | Shared policy can let different actors invoke privileged API functions. | |
| API6 — Unrestricted Access to Sensitive Business Flows | Overbroad access can let humans, workloads or agents chain calls into harmful flows. | |
| Recommendation — Enforce object-level checks for every request and bind access to the caller's allowed objects. Gate each sensitive function explicitly and verify the caller's right to invoke it. Constrain end-to-end business flows and require step-up controls for high-impact actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question centers on overbroad access and actor-specific privilege boundaries. |
| IA-9 — Identification and Authentication (Service and Application Accounts) | Workload and service access need distinct authentication and access treatment. | |
| AU-2 — Event Logging | Mixed access paths require logs that show who did what and under which authority. | |
| Recommendation — Limit each actor to the minimum permissions needed for its role and task. Authenticate service and application accounts with controls that separate them from human users. Log API actions with enough context to distinguish humans, workloads and agents. | ||
Practitioner Guidance
What to verify: confirm that the policy can express different rules for human users, service identities and agents, not just one shared allow/deny decision. If the same rule governs read access, write access and bulk export, it is usually too coarse for production use.
Decision rule: if an actor can request different objects or invoke different functions, move to per-action and per-context authorisation before expanding the API surface. Reserve broad access only for narrow administrative cases with explicit review and logging.
Practitioner takeaway: the goal is not identical treatment for every caller, it is consistent control over access that reflects the caller’s real authority, intent and blast radius.