Brokered identity is a model where a central control point issues, scopes, and records access for a runtime actor instead of allowing direct uncontrolled connections. For AI agents, it helps bind each action to a session, policy, and audit trail.
Expanded Definition
Brokered identity is a control pattern, not a single product feature. It sits between a runtime actor, such as an application service, workload, or AI agent, and the resources it needs to reach. Instead of giving that actor broad, persistent credentials, a broker issues access in a scoped, time-bound, and auditable way. In identity operations, this is often used to reduce direct trust in the calling component and to make each transaction attributable to a specific session.
For NHI and agentic AI use cases, the broker can bind permissions to context such as workload identity, policy, and approved tool access. That makes brokered identity closely related to principles in the NIST Cybersecurity Framework 2.0, especially around access control, governance, and auditability. Usage in the industry is still evolving because vendors describe similar ideas with different labels, including token exchange, delegated authorization, and identity mediation. The important distinction is that the broker becomes the point where access is authorized, constrained, and logged, rather than being inherited indefinitely by the caller.
The most common misapplication is treating brokered identity as a proxy layer only, which occurs when teams forward traffic without enforcing session scoping, policy checks, or identity binding.
Examples and Use Cases
Implementing brokered identity rigorously often introduces extra orchestration and latency, requiring organisations to weigh tighter control and traceability against added complexity in service flows.
- An AI agent requests a broker-issued token for one specific tool action, then loses that privilege when the session ends.
- A cloud workload authenticates to a broker that exchanges its upstream identity for a downstream credential with narrowly defined scope.
- A privileged automation job receives access only after policy evaluation, rather than carrying a standing secret that can be reused elsewhere.
- A developer platform records every identity exchange so security teams can trace which runtime actor accessed which service and when.
- An identity fabric uses brokered access to isolate partner integrations, avoiding direct trust between external systems and internal applications.
These patterns are especially relevant where direct machine-to-machine trust is too broad for the risk profile. The idea overlaps with delegated authorization, but brokered identity is broader because it emphasises the operational control point, the evidence trail, and the ability to revoke or narrow access dynamically. For organisations building AI systems, the broker can also help ensure that an agent’s access is tied to policy rather than to a reusable secret stored in the application layer.
Why It Matters for Security Teams
Security teams need brokered identity because uncontrolled runtime access tends to expand quietly. Once a service account, API key, or agent credential is reused across systems, it becomes difficult to know which action came from which actor, and revocation often breaks more than intended. Brokered identity gives defenders a way to reduce standing privilege, improve segmentation, and create a stronger audit trail across human and non-human actors.
For NHI governance, the value is especially clear: the broker can become the policy gate that decides whether a workload, pipeline, or AI agent should receive a token at all, and under what conditions. That supports stronger access reviews, better containment, and cleaner incident response. It also aligns with the governance intent behind the NIST Cybersecurity Framework 2.0, where access decisions should be controlled, monitored, and recoverable. In practice, the concept becomes essential after secrets are discovered in logs, an agent starts calling tools outside its intended scope, or a workload compromise exposes too much downstream access. Organisations typically encounter lateral movement and overbroad automation only after an incident, at which point brokered identity 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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Brokered identity operationalizes controlled access decisions for runtime actors. |
| NIST SP 800-63 | AAL2 | Identity assurance concepts inform how strongly a runtime actor is authenticated. |
| NIST AI RMF | GOVERN | AI governance expects accountability, traceability, and controlled access for AI systems. |
| OWASP Non-Human Identity Top 10 | NHI guidance emphasizes scoped, monitored, and revocable non-human credentials. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance stresses bounded tool access and traceable agent actions. |
Use brokered identity to centralize access decisions and reduce standing trust.
