Access brokered blast radius is the amount of infrastructure a user can reach once a session is established through a broker or gateway. The smaller the reachable set, the less damage a compromised session or overbroad entitlement can cause.
Expanded Definition
Access brokered blast radius describes the reachable infrastructure set that an agent, service account, or human obtains after authenticating through a broker, gateway, or access proxy. In NHI security, the term is less about the login itself and more about what the authenticated session can actually touch, invoke, or modify.
Definitions vary across vendors because some products measure network reachability, while others emphasize tool permissions, application scope, or downstream API paths. The practical NHI interpretation aligns with least privilege and segmentable trust boundaries: a broker should reduce exposure by narrowing session scope, not simply concentrate access behind another control point. Guidance in the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce that access scope must be bounded, reviewable, and revocable.
The most common misapplication is treating the broker as the control outcome, which occurs when teams assume gateway authentication alone prevents lateral reach across overly broad routed resources.
Examples and Use Cases
Implementing access brokered blast radius rigorously often introduces routing and policy complexity, requiring organisations to weigh tighter containment against added operational overhead and troubleshooting effort.
- A CI/CD runner connects through a broker that only exposes deployment APIs for one namespace, reducing the impact if the runner token is stolen.
- An AI agent is allowed through a gateway to query one ticketing system and one knowledge base, but not production databases or cloud consoles.
- A privileged vendor session is brokered into a jump environment with time-limited reach to a single host group, rather than the full subnet.
- An NHI monitored in the Ultimate Guide to NHIs is segmented so that token compromise cannot automatically extend into secrets stores or admin APIs.
- A service account authenticated through a zero-trust access layer is restricted to one workload path, consistent with the session containment logic described in 52 NHI Breaches Analysis.
Why It Matters in NHI Security
Brokered access can create a false sense of safety if organisations focus on authentication and ignore session scope. When a compromised token, API key, or AI agent credential is accepted by a broker, the resulting blast radius determines whether the incident is a contained event or a broad operational outage. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes unreachable scope difficult to prove and harder to audit.
This term is especially important for NHI programs because NHIs frequently outnumber humans and often carry excessive privileges, so a single overbroad broker rule can expose multiple systems at once. Broker logs, entitlement review, and path-specific allowlists should show not just who connected, but what was reachable during the session. The most effective containment models pair brokered access with short-lived credentials, narrow resource mappings, and explicit deny rules for lateral movement. Organisations typically encounter the consequences only after a stolen session is used to enumerate adjacent systems, at which point access brokered blast radius 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 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Addresses overbroad NHI access paths and session scope containment. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access should constrain what a session can reach after authentication. |
| NIST SP 800-63 | Identity assurance is separate from the scope of what a session may access. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, resource-specific authorization for each session. |
Limit brokered sessions to the smallest reachable resource set and review path exposure regularly.
