An intermediary control that sits between an identity and the target system, mediating each request so the caller never receives the live credential in reusable form. This pattern is critical for agent security because it preserves central control over access while still allowing action at runtime.
Expanded Definition
A connection-path broker is a control point that mediates runtime access between an agentic workload or service identity and the target resource, so the requester never handles a reusable live credential. Unlike a simple proxy, the broker is identity-aware: it can enforce policy, scope access to a single action, record the transaction, and remove standing exposure after use. In NHI environments, this pattern is used to keep secrets out of code, prompts, and agent memory while still allowing systems to act on demand.
Definitions vary across vendors, especially on whether the broker also performs credential minting, session brokering, or request translation. In practice, the important distinction is that the broker remains the policy-enforcing intermediary rather than handing the caller a token it can reuse later. That makes the pattern closely aligned with least privilege and NIST Cybersecurity Framework 2.0 principles for controlled access and traceability.
The most common misapplication is treating a basic reverse proxy as a connection-path broker, which occurs when the proxy relays traffic without enforcing identity-specific policy or preventing credential reuse.
Examples and Use Cases
Implementing a connection-path broker rigorously often introduces added latency and orchestration overhead, requiring organisations to weigh tighter control and auditability against the complexity of routing every request through a policy gate.
- An AI agent requests database access through a broker that issues a narrowly scoped, time-bound session instead of exposing the database password.
- A CI/CD job reaches a cloud API through a broker that validates workload identity, checks policy, and records the action in a tamper-evident log.
- A support automation agent uses a broker to open a ticketing-system session only when a specific approval path has been satisfied.
- An enterprise places third-party service access behind a broker so the external caller never receives a reusable API key, reducing blast radius if the integration is abused. This risk is consistent with the exposure patterns described in the Ultimate Guide to NHIs.
- A secrets platform integrates with a broker to translate workload identity into just-in-time access, rather than storing static credentials in the application runtime, which aligns with the access-control intent described by NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Connection-path brokers matter because NHI compromise is rarely limited to a single account. Once a reusable credential is exposed, attackers can move laterally, automate misuse, and persist far longer than defenders expect. NHI Management Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why brokered access is more than an architectural preference. It is a containment control.
The pattern also supports better governance when organisations have weak visibility into service accounts, secret sprawl, or overprivileged workloads. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility makes direct credential distribution especially dangerous. Brokering access centralises policy decisions, narrows credential lifetime, and gives defenders an audit trail for every path taken to a target system. It also supports a Zero Trust posture by refusing to assume that a workload should inherit reusable trust just because it authenticated once.
Organisations typically encounter the operational necessity of a connection-path broker only after a leaked token, agent misuse, or unauthorized integration attempt reveals that direct credential handoff was too difficult to govern.
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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Brokered access reduces secret exposure and supports controlled NHI credential handling. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous policy checks for each connection, which this pattern enforces. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and controlled authorization are core to brokered connection paths. |
Place every agent and service request behind policy evaluation instead of trusting prior authentication.
Related resources from NHI Mgmt Group
- Why do leaked secrets need a different reporting path than ordinary software bugs?
- How should security teams prevent hardcoded secrets from becoming a breach path?
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- How should organisations respond when a privileged SSH certificate path is flawed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
