Security teams should authorize API requests using both user context and application context. The API needs to know who initiated the action, which application is calling, and whether the request is expected in that runtime situation. If policy only checks the user, delegated access and automated workflows can overreach their intended scope.
Why This Matters for Security Teams
Authorizing API requests on behalf of users is not the same as authorizing a user session. The API must validate the human request origin, the calling application, and the runtime context of the action. If policy only checks who the user is, delegated access can drift into unintended data access, tool use, or automation. That becomes more dangerous when applications carry their own privileged secrets or when the same workflow is reused across environments.
This is a core Non-Human Identity problem as much as it is an application security problem. Modern guidance in the Ultimate Guide to NHIs emphasizes that identity decisions for machine actors need lifecycle, visibility, and revocation, not just login checks. The risk is not hypothetical: Astrix Security & CSA research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly where delegated access often starts to sprawl. Practitioners should treat every on-behalf-of flow as a compound trust decision, not a single user grant. In practice, many security teams encounter overreach only after delegated tokens have already been used beyond their intended scope.
How It Works in Practice
The safest pattern is to authorize at request time using both the user context and the application context, then compare both against the expected action, resource, and runtime conditions. That usually means the API should evaluate who initiated the request, which workload is presenting the token, whether the token is meant for delegation, and whether the specific operation matches current policy. This is where role-based access control alone falls short, because RBAC can describe entitlement but not the immediate intent of the request.
Current guidance suggests combining these checks with short-lived credentials, strong workload identity, and policy evaluation that can read contextual signals. For example, a service can present cryptographic workload identity, while the delegated user token carries the user’s consent and scope. The policy engine then decides whether the application is allowed to act on that user’s behalf for that specific API call. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward governed access and continuous oversight rather than one-time grant decisions. For broader NHI governance, the Ultimate Guide to NHIs is the clearest reference for lifecycle and revocation discipline.
- Bind the delegated token to the specific application identity, not just the user identity.
- Check scope, audience, and expiry on every request, not only at issuance.
- Use policy-as-code so runtime conditions can block unexpected tool use or data access.
- Prefer short-lived delegation and revocation hooks over long-lived refresh paths.
Where this guidance breaks down is in legacy architectures that cannot distinguish user intent from application authority because every request is flattened into a session token.
Common Variations and Edge Cases
Tighter authorization often increases engineering and operational overhead, requiring organisations to balance stronger delegation controls against latency, integration complexity, and support burden. That tradeoff is real, especially in environments with older API gateways, mixed SaaS integrations, or service-to-service chains that were never designed for per-request context evaluation. Best practice is evolving here, and there is no universal standard for this yet.
One common edge case is batch or background processing. A user may start a job, but the actual API calls occur later, from an automated worker, after the original session has expired. In those cases, security teams should avoid “forever delegation” and instead use JIT or ephemeral grants that are tied to the task, the workload, and a narrow expiry window. Another edge case is third-party integrations that rely on refresh tokens or vendor-managed OAuth apps. The Ultimate Guide to NHIs highlights how quickly these connections can become over-privileged when offboarding and rotation are weak.
For policy clarity, many teams pair NIST Cybersecurity Framework 2.0 principles with governance controls from the Astrix Security & CSA research, especially where visibility into third-party OAuth usage is poor. These controls tend to break down when vendor apps can refresh access silently across multiple tenants because the original user context is no longer available at decision time.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Delegated access still depends on NHI token scope and misuse prevention. |
| CSA MAESTRO | A3 | MAESTRO addresses runtime control for agentic and delegated machine actions. |
| NIST AI RMF | AI RMF supports governance for autonomous or semi-autonomous decision paths. |
Bind delegated API calls to least-privilege NHI scopes and reject tokens that exceed the task.
