A permission model that binds an agent or workload to one narrowly defined external integration. Each connection carries its own scope, making it possible to limit what a specific agent can access, reduce blast radius, and revoke access without disturbing unrelated workflows.
Expanded Definition
Connection-scoped access is a pattern for binding an agent, service account, or workload to one specific external integration, so the granted permissions exist only within that connection boundary. In practice, the scope may cover a single API, data store, or partner system, while everything else remains out of reach. That makes it a closer fit for NHI governance than broad token sharing or general-purpose service credentials. It also aligns naturally with least privilege and Zero Trust ideas described in the OWASP Non-Human Identity Top 10, though definitions vary across vendors when they describe connection-level grants, linked credentials, or per-integration auth. NHI Management Group treats the connection as the policy unit, not the workload as a whole, because an agent can legitimately need different rights for different tools. The most common misapplication is treating one broad credential as connection-scoped, which occurs when multiple integrations share the same secret or token.
Examples and Use Cases
Implementing connection-scoped access rigorously often introduces more credential management overhead, requiring organisations to weigh tighter containment against the cost of more policies, secrets, and reviews.
- An AI coding agent gets one scoped connection to a source-control API for pull request comments, while a separate connection handles read-only issue lookup.
- A customer-support workflow uses one integration for ticket creation and another for CRM read access, so revoking one connection does not disable the whole bot.
- A data pipeline is allowed to read from a single object store bucket but cannot reuse the same credential to enumerate adjacent storage services.
- A partner-facing automation is given a narrowly scoped API token that expires independently, reducing blast radius if that external channel is abused.
- For governance mapping, teams often compare connection design to the lifecycle and secret hygiene concerns described in the Ultimate Guide to NHIs and the Ultimate Guide to NHIs — Key Challenges and Risks.
- For protocol-oriented implementations, teams may express the boundary through OAuth-style delegated authorization or similar connector patterns rather than shared static credentials.
Why It Matters in NHI Security
Connection-scoped access matters because NHI compromise is rarely limited to a single happy-path workflow. If a token, API key, or connector secret leaks, the attacker often inherits every permission tied to that credential, which turns one exposed integration into a wider incident. That is especially dangerous in environments where 96% of organisations store secrets outside of secrets managers in vulnerable locations and where 52 NHI Breaches Analysis shows how quickly weak identity boundaries become operational incidents. Connection scoping supports revocation, segmentation, and cleaner offboarding because one failed integration can be disabled without taking unrelated agents offline. It also helps security teams answer a core governance question: which agent can reach which external system, under what authority, and for how long. Organisations typically encounter the full consequence only after a connector is abused or a secret is found in code, at which point connection-scoped access 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 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-02 | Connection-scoped access limits secret exposure and connector sprawl across NHI integrations. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control fits tightly bounded permissions for each external connection. |
| NIST Zero Trust (SP 800-207) | Zero Trust favors per-request, per-resource boundaries instead of broad standing access. |
Assign one credential per integration and revoke or rotate it independently when a connection is no longer needed.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and task-scoped access for AI agents?
- What is the difference between task-scoped access and permanent NHI privileges?
- What breaks when knowledge base access is mis-scoped in ServiceNow?
- What breaks when access across trust domains is not tightly scoped?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
