Domain restricted sharing is an organisation-level Google Cloud policy that limits which domains can be granted IAM access. It does not revoke existing permissions, but it blocks new role assignments to unapproved domains. Security teams use it to prevent a compromised external account from expanding its access inside a project.
Expanded Definition
Domain restricted sharing is a Google Cloud organisation policy that constrains which external domains can receive new IAM grants. In practice, it acts as a guardrail on future access delegation rather than a retroactive cleanup mechanism. That distinction matters: if an identity already has access, the policy does not remove it, but it can stop additional role assignments from being made to an unapproved domain.
In NHI governance, the control is most relevant where service accounts, automation users, and collaborative cloud workflows cross organisational boundaries. It is a preventive control, but not a complete authorisation model, so it should be paired with NIST Cybersecurity Framework 2.0 access governance practices and local IAM review procedures. Definitions vary across vendors because some platforms describe similar behaviour as domain allowlisting, external sharing restriction, or tenant boundary enforcement, but the operational aim is the same: reduce unintended privilege spread across domains.
The most common misapplication is treating domain restricted sharing as a removal control, which occurs when teams assume blocked future grants also clean up existing cross-domain access.
Examples and Use Cases
Implementing domain restricted sharing rigorously often introduces collaboration friction, requiring organisations to weigh tighter external access control against the administrative overhead of exception handling.
- A cloud security team allows IAM grants only to company-owned domains, preventing a contractor’s account from being added to a production project after onboarding is complete.
- An NHI platform team uses the control to stop an AI agent from granting a service account access to a partner domain during automated deployment workflows.
- A merger integration team temporarily opens approved domains for a limited migration window, then tightens the policy once shared workloads are moved.
- A security reviewer finds that existing external users still retain access, so they pair the policy with access recertification and revocation workflows.
- In a breach response, investigators use the policy to ensure compromised external identities cannot expand into additional projects while containment is underway, a pattern echoed in DeepSeek breach analysis of how exposed access can scale quickly when guardrails are missing.
This control is also easiest to understand alongside NIST Cybersecurity Framework 2.0 principles for least privilege and access management, especially in environments where automated tooling issues IAM changes at speed.
Why It Matters in NHI Security
Domain restricted sharing matters because NHI risk often emerges from uncontrolled delegation, not just from stolen credentials. A compromised external identity can be limited in one project yet still become highly damaging if it can be granted new roles elsewhere. For organisations operating at cloud scale, the control narrows the blast radius by reducing the number of domains that can be introduced into IAM relationships.
NHIMG research shows that the average time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities, underscoring how slow containment can be once access sprawl begins. That lag makes preventive boundaries more valuable, especially when automation, federated identities, and third-party collaboration all intersect. The policy does not replace monitoring, but it does reduce the chance that a single exposed identity can cascade into broader project access. This is particularly relevant when secrets, tokens, or service account keys are already under pressure from cross-team sharing practices, as explored in The State of Secrets in AppSec.
Organisations typically encounter the operational importance of domain restricted sharing only after an external account has been misused, at which point the inability to extend that access further 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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Limits external IAM grants to approved domains to support least privilege. |
| NIST Zero Trust (SP 800-207) | JIT | Supports zero trust by limiting standing pathways for external privilege expansion. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Reduces the blast radius of compromised NHIs by constraining new role assignment targets. |
Pair domain restrictions with NHI inventory and secret governance to prevent access sprawl.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
