A tenant-level identity source that is promoted for use across applications rather than being limited to a single app registration. For MCP, this expands the trust boundary because the same identity provider can authenticate multiple connectors, so governance has to cover the source itself as well as the client.
Expanded Definition
Domain connection is the governance pattern that promotes a tenant-level identity source for use across multiple applications or connectors, rather than confining it to one app registration. In MCP environments, that promotion expands the trust boundary because the same issuer can authenticate more than one tool, agent, or connector, so the identity source itself becomes a security object that requires review.
Definitions vary across vendors, especially when teams blur domain connection with federation, application onboarding, or directory sync. In NHI management, the important distinction is operational: a domain connection is not just a technical link, but a reusable trust relationship that can concentrate authentication, authorization, and token issuance risk. That is why practitioners often pair identity-source governance with controls described in the NIST Cybersecurity Framework 2.0 and with application-level review of what each connector can actually do.
The most common misapplication is treating a promoted identity source as a harmless configuration shortcut, which occurs when teams approve broad reuse without revalidating scope, audience, and blast radius.
Examples and Use Cases
Implementing domain connection rigorously often introduces onboarding friction, requiring organisations to weigh connector reuse and faster deployment against tighter approval, testing, and monitoring of the shared trust layer.
- A SaaS tenant promotes a central IdP for three MCP connectors so each agent can authenticate consistently, but security must verify that the same domain connection does not over-broaden permissions across all tools.
- An internal platform team reuses one tenant-level identity source for development and production connectors, then uses DeepSeek breach-style lessons to justify stronger review of what data each connector can reach.
- A governance team maps the connection to NIST Cybersecurity Framework 2.0 access practices before allowing a new AI agent to inherit the same issuer trust.
- A customer support workflow uses one promoted identity source for multiple automation apps, but each app still needs distinct scopes so a compromise in one connector does not cascade into the others.
- An enterprise centralises authentication for many agents, then documents which domain connection belongs to each business unit to avoid shadow trust relationships and unclear ownership.
Why It Matters in NHI Security
Domain connection matters because NHI incidents rarely stay contained to the first app that was intended to use a credential source. Once a tenant-level identity source is reused across several connectors, compromise of the source can create a multiplier effect: token abuse, unauthorized tool access, and difficult-to-trace lateral movement across agents and integrations. This is especially relevant when secrets, client credentials, or certificates are embedded in connector workflows, because identity sprawl and trust sprawl usually develop together.
NHIMG research shows that organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that undermines centralised control and makes shared identity sources harder to govern effectively. In the same research set, the average time to remediate a leaked secret is 27 days, which is long enough for a promoted domain connection to become an exposure amplifier if monitoring is weak. The state of the connection matters as much as the state of the connector, and that is the governance lesson echoed by the The State of Secrets in AppSec findings and the attack patterns discussed in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research. Organisations typically encounter the real impact only after a connector is abused or a secret is exposed, at which point domain connection 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-01 | Domain connections expand shared trust boundaries and NHI reuse risk. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and trust relationships must be reviewed for shared identity sources. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust principles require validating each connection instead of trusting the tenant by default. |
Treat each connector as separately verified and limit blast radius across the shared identity boundary.
Related resources from NHI Mgmt Group
- Why do cross-domain attacks create more risk than single-domain intrusions?
- How should security teams build a cross-domain identity programme?
- How do IAM teams know whether a delegated Notion connection is still valid?
- How should security teams harden domain controllers that still need legacy authentication support?
