Access brokering

Expanded Definition

Access brokering is an architectural control that inserts an intermediary between an operator and a target system so the operator never directly handles the destination credentials or network path. In NHI and privileged-access programs, that intermediary can enforce session start, policy checks, command filtering, recording, and forced termination while keeping secrets hidden from the user. It is closely related to privileged session management, but the term is broader because it can also broker access for service accounts, automation workflows, and agentic tools that need controlled reach into sensitive systems. Definitions vary across vendors on whether brokering includes credential checkout, reverse proxying, or full session control, so practitioners should treat the term as a control pattern rather than a single product category. The OWASP Non-Human Identity Top 10 frames the underlying risk as excessive exposure of secrets and overprivileged identities, which access brokering is designed to reduce. The most common misapplication is assuming any jump host is access brokering, which occurs when direct credentials are still exposed or session control is not actually enforced.

Examples and Use Cases

Implementing access brokering rigorously often introduces latency and operational friction, requiring organisations to weigh tighter control and auditability against faster operator workflows.

• Privileged administrator access is routed through a broker that injects credentials at session start and prevents the administrator from ever seeing the secret.
• An NHI used by an automation job reaches a database only through a broker that allows approved commands and records the full session for review, aligning with guidance in the Ultimate Guide to NHIs.
• A third-party support engineer connects through a broker so the organisation can enforce just-in-time approval, session time limits, and immediate revocation after the task ends.
• An internal service account accesses a cloud console via a broker that masks the underlying API key and prevents direct use outside approved workflows.
• Security teams use brokered access to create a controlled path for incident response, especially when evidence from a live session must be preserved for later analysis, a pattern reflected in the 52 NHI Breaches Analysis.

Why It Matters in NHI Security

Access brokering matters because it reduces the number of places where a secret can be exposed and creates a policy enforcement point around high-risk identity use. That is especially important in environments where 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and where overprivileged NHIs can silently expand blast radius. When brokering is absent, incident response often depends on finding and rotating credentials after misuse has already occurred. When brokering is present but poorly governed, it can become a false sense of control if sessions are not logged, approvals are weak, or direct paths still exist around the broker. The practical security value is not just masking credentials, but making access revocation and forensic review operationally reliable. Organisations typically encounter the necessity of access brokering only after a privileged account leak, an abused automation token, or a contractor session reveals that direct access paths were never truly contained.

Related resources from NHI Mgmt Group

• Privileged access brokering
• What is Just-in-Time (JIT) access and why is it important for NHI security?
• When is it crucial to implement least-privilege access for AI agents?
• How should security teams run access reviews for non-human identities?