Bundled APIs often separate authentication from downstream processing, which creates room for the server to trust different context fields at different stages. That split can let an attacker authenticate as one tenant while influencing policy or schema evaluation for another. The risk is highest when request preparation, authorization, and persistence do not all use the same verified identity.
Why This Matters for Security Teams
Bundled workflow APIs are risky because they compress multiple trust decisions into one request path. Authentication may happen at the front door, but tenant selection, schema resolution, job routing, and persistence often occur later using different fields. That creates a classic confused deputy condition: the service becomes the deputy that is tricked into acting on behalf of the wrong tenant. NIST’s NIST Cybersecurity Framework 2.0 emphasizes consistent governance and access control, but multi-step API designs still fail when identity context is not preserved end to end.
This is not just a coding defect. In multi-tenant systems, a single mismatch between the authenticated principal, the requested tenant, and the object being written can expose data, route tasks to the wrong workspace, or grant unintended authority to downstream services. NHIMG research shows how often identity controls fail in practice: the Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which makes any context split more dangerous. In practice, many security teams encounter confused deputy flaws only after a tenant boundary has already been crossed, rather than through intentional review of the request flow.
How It Works in Practice
The bug usually appears when a workflow API accepts a high-level request, then decomposes it into internal steps that do not all rely on the same verified identity. For example, a user from Tenant A submits a job that references a project, template, or callback URL. The gateway authenticates the caller correctly, but a later worker trusts a tenant ID embedded in the payload, a header injected by a proxy, or a record looked up from a mutable session store. The service becomes a deputy because it is legitimate and privileged, but it is being steered by attacker-controlled context.
Current best practice is to bind the authenticated identity to every downstream authorization decision. That means the service should:
- derive tenant scope from verified identity, not from user-supplied fields;
- carry signed or otherwise integrity-protected context through the workflow;
- re-check authorization at each sensitive step, especially when fan-out or retries occur;
- ensure write operations, schema selection, and policy evaluation all reference the same principal;
- log the original identity, resolved tenant, and final action for each stage.
This aligns with the control themes in the Top 10 NHI Issues and the NIST CSF 2.0 function of access control, but implementation detail matters more than slogans. If the API hands off work to a queue, serverless worker, or LLM-backed orchestration layer, the deputy risk increases because the original request context can be diluted, transformed, or replayed across tenants. These controls tend to break down when asynchronous retries and shared worker pools re-evaluate tenant scope from mutable payload fields instead of the original authenticated token.
Common Variations and Edge Cases
Tighter tenant binding often increases implementation overhead, requiring organisations to balance safety against developer friction and operational latency. That tradeoff is most visible in systems that support cross-tenant administration, delegated support workflows, or bulk automation. Guidance is still evolving for these cases, and there is no universal standard for how much downstream context may be trusted without revalidation.
Common edge cases include admin consoles that legitimately act across tenants, batch jobs that process many customer records in one run, and webhook pipelines where the callback target is chosen after initial authentication. In each case, the safe pattern is to separate “who is allowed to initiate” from “which tenant is affected,” then require explicit, auditable approval for cross-boundary actions. The Ultimate Guide to NHIs — Why NHI Security Matters Now is a useful reminder that excessive privilege and weak revocation are what turn small context bugs into tenant-wide incidents. For workflow APIs, the practical test is simple: if any internal step can infer tenant scope from a different source than the first authenticated step, the confused deputy risk remains.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers overbroad privileges that make tenant confusion easier to exploit. |
| OWASP Agentic AI Top 10 | AI-03 | Covers request-time authorization for autonomous or chained actions. |
| CSA MAESTRO | IAC-2 | Addresses identity and access control for multi-step agentic workflows. |
| NIST CSF 2.0 | PR.AC-4 | Directly applies to access permissions and identity lifecycle enforcement. |
| NIST AI RMF | GOVERN | Governance is needed where automated workflows can misapply identity context. |
Evaluate every delegated action at runtime using the original verified identity and context.
