A caller-controlled identifier is any value in a request that the user can supply or change, such as an object ID, group ID, or task ID. These values become dangerous when the application uses them to select or modify data without rechecking ownership, assignment, or tenant membership.
Expanded Definition
A caller-controlled identifier is a request parameter whose value influences which record, resource, workflow, or tenant context the application operates on. The security issue is not the identifier itself, but the trust the application places in user-supplied values without independently verifying authorization. In practice, this term is closely related to broken object-level authorization and insecure direct object reference patterns, but it is broader because the same flaw can affect group membership, job queues, API actions, and multi-tenant boundaries.
Usage in the industry is fairly consistent, although some teams still describe the issue only as IDOR or authorization bypass. NHI Management Group uses caller-controlled identifier to emphasize the root condition: the caller gets to influence a selector that should have been derived from server-side context, not trusted input. That distinction matters in identity-heavy systems where object ownership, delegated access, and tenant scoping must be revalidated on every request. The most common misapplication is treating a user-supplied identifier as a harmless lookup key when it actually determines access to another user’s data or a privileged workflow.
Examples and Use Cases
Implementing protections for caller-controlled identifiers rigorously often introduces additional authorization checks on every request, requiring organisations to weigh simplicity and performance against stronger access control.
- An application receives object-level authorization guidance after exposing invoice IDs in a URL and failing to confirm that the requester owns the invoice before returning it.
- A support portal accepts a group ID in a form submission and changes membership based solely on the submitted value, even though the caller should only be able to act on groups they administer.
- A SaaS platform routes requests by tenant ID from the client, but a missing server-side tenant check allows one customer to query another customer’s records if they guess the identifier.
- A workflow API lets a caller submit a task ID to approve or cancel a job, yet the system never verifies whether the caller is assigned to that task or authorised for that queue.
- Identity-centric systems can be affected when a user-controlled subject ID, session-linked resource ID, or delegation reference is accepted without confirming that the request matches the authenticated principal’s scope, a concern that aligns with CWE-639.
In secure design reviews, this term often appears alongside access control testing, API abuse cases, and tenant isolation checks. It also matters in agentic systems where an AI agent can submit tool calls or workflow IDs on behalf of a user, because the agent may amplify a bad selector rather than create it.
Why It Matters for Security Teams
Caller-controlled identifiers are dangerous because they turn authorization into a guessing problem if the application does not revalidate who may act on the selected object. The failure mode is especially severe in APIs, microservices, and multi-tenant platforms, where the same endpoint may serve many users, roles, and service accounts. Security teams should treat any user-supplied selector as untrusted input and pair it with server-side checks for ownership, assignment, tenant membership, and action-specific privilege. This is consistent with the intent of NIST Cybersecurity Framework 2.0, which expects organisations to govern access and protect assets through controlled, verified access paths.
The identity connection is direct: if the system binds a request to an authenticated user but then lets the caller choose a different subject, object, or scope through a parameter, the identity proof is no longer enough to justify the action. In NHI and agentic AI environments, the same weakness can let a workload identity, service token, or agent tool call target the wrong resource if the identifier is accepted at face value. Organisations typically encounter the true impact only after an access review, tenant dispute, or incident response reveals that a simple parameter swap exposed data or changed records, at which point caller-controlled identifier 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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control governance underpins verification of who may act on a selected resource. |
| NIST SP 800-63 | Digital identity assurance depends on binding actions to the authenticated subject, not user-chosen targets. | |
| OWASP Non-Human Identity Top 10 | NHI guidance emphasizes server-side authorization for identities and secrets exposed to request-driven access. | |
| OWASP Agentic AI Top 10 | Agentic systems must not let tool calls or workflow IDs override server-side authorization decisions. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification rather than trusting request parameters or network location. |
Verify each caller-selected object against authenticated identity and enforced authorization before processing the request.
