An identity broker is a component that translates a caller’s instruction into action using its own credentials, permissions, or network reach. In NHI and agentic AI environments, the broker’s authority becomes the real security boundary, so both caller identity and downstream destination controls must be explicit.
Expanded Definition
An identity broker is a control point that receives a request from one identity, then performs an action through a different identity with its own credentials, network path, or permissions. In NHI and agentic AI environments, that means the broker, not the original caller, often becomes the effective security boundary.
Usage in the industry is still evolving. Some teams treat an identity broker as a generic gateway for federation or token exchange, while others reserve the term for systems that actively execute downstream actions on behalf of a caller. The distinction matters because a broker that only authenticates traffic is not the same as one that is authorised to write data, call APIs, or trigger workflows. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need to define identity and access boundaries clearly, which is especially important when the broker sits between human operators, AI agents, and service accounts.
The most common misapplication is assuming the caller’s permissions automatically constrain the broker, which occurs when downstream execution is not separately authorised and logged.
Examples and Use Cases
Implementing identity brokering rigorously often introduces extra policy and audit complexity, requiring organisations to weigh simpler orchestration against tighter control over who can act, where, and with what authority.
- A workflow engine accepts a human approval, then uses its own service account to open a ticket, update a database, or call an internal API.
- An AI agent requests a brokered token to retrieve files from a SaaS platform, but the broker enforces destination-specific scopes and short-lived access rather than reusing a broad credential.
- A federation layer exchanges an incoming assertion for a different token format before an application can reach an internal resource, separating authentication from execution authority.
- A platform team uses brokering to mediate access to secrets managers so that the caller never sees raw credentials, only narrowly scoped delegated actions.
- Incident review of patterns described in the 52 NHI Breaches Analysis often shows that the broker was trusted too broadly, letting one compromised integration reach many systems.
For implementation guidance on delegated access and identity boundary design, the NIST Cybersecurity Framework 2.0 is a useful external anchor, while NHIMG’s Ultimate Guide to NHIs places the same problem in the broader context of lifecycle control and visibility.
Why It Matters in NHI Security
Identity brokers matter because they concentrate trust. If the broker is over-privileged, poorly logged, or allowed to reach too many destinations, it becomes a high-value pivot point for lateral movement, secret exposure, and unauthorised automation. This is especially dangerous in NHI estates where service accounts, API keys, and agent permissions already expand faster than most teams can review them.
NHIMG’s Top 10 NHI Issues highlights how excessive privilege and weak visibility repeatedly show up in non-human identity failures. That concern is not theoretical: NHI Mgmt Group reports that Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges, which means a broker built without strict scope boundaries can multiply that risk across every system it touches.
Practitioners should treat the broker as a separately governed identity with explicit destination controls, token lifetimes, and audit requirements, not as a neutral middle layer. Organisations typically encounter the full impact of an identity broker only after a compromised integration starts reaching systems it was never meant to touch, at which point the broker 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 Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity brokers often centralise delegation and thus inherit NHI trust-boundary risk. |
| NIST CSF 2.0 | PR.AC-4 | Brokered execution depends on managed access permissions and least privilege. |
| NIST Zero Trust (SP 800-207) | PA-4 | Zero Trust requires explicit policy for every brokered request and destination. |
| NIST SP 800-63 | Federated brokers rely on identity assertion and token handling concepts. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems commonly use brokers to translate intent into tool use. |
Review broker entitlements regularly and limit each destination to the minimum required access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
