Google Workspace admins love Trust Rules. They give granular, per-OU control over who can share Drive files with whom, using conditions like domain allowlists, organizational unit scoping, and content labels. For tenants that need more than a single global sharing switch, trust rules are the right answer.
But there is a problem. If you audit your tenant with any automated tool, trust rules are invisible. Your report says you are failing Drive sharing checks that you have already solved. The admin knows the finding is wrong, but the tool cannot see the evidence. This is the trust rules gap.
What are Trust Rules?
Trust Rules are a Google Workspace feature found under Admin Console > Apps > Google Workspace > Drive and Docs > Trust rules. They let admins define per-OU sharing conditions: who can share with whom, based on organizational unit, target domain, and content conditions.
Trust rules operate at a layer above the global Drive sharing settings. Even when the global setting says "sharing with external users is allowed," a trust rule can block external sharing entirely for a specific OU, or require a warning before sharing outside the organization. They supersede, not supplement, the base settings.
A concrete example
A company sets its global Drive sharing to "Anyone with the link" for collaboration convenience. But a trust rule with a BLOCK_SHARE action is applied to the Finance OU, preventing any external sharing. Another trust rule on the Sales OU allows external sharing but only to a list of partner domains. Both OUs behave differently from the global setting, and both are invisible to the API.
The audit problem
Here is the specific scenario that generates false positives. This applies to gws-auditor before v1.4.0 and to every other Google Workspace audit tool.
Admin configures trust rules
A trust rule with BLOCK_SHARE blocks external sharing for every OU.
Global policy still looks permissive
The Cloud Identity Policy API returns the global Drive sharing policy as "external sharing allowed." This is technically accurate: the base setting has not changed.
Audit tool reports a failure
The auditor sees "sharing allowed" and flags CIS-3.1.2.1.1.1 (external sharing warning) and CIS-3.1.2.1.1.2 (public publishing) as FAIL. The admin knows this is wrong, but the tool has no way to verify it.
Root cause
Google does not expose trust rules through any public API. Not the Cloud Identity API, not the Admin SDK, not Access Context Manager. Unlike Context-Aware Access (which at least leaves evidence in audit logs), trust rules silently modify sharing behavior with no programmatic trace.
Why Google does not expose trust rules via API
Trust rules are a relatively recent addition to the Workspace sharing model. Their policy surface area is complex: conditions can reference CEL expressions, DLP labels, domain lists, and organizational units in combination. Google has not yet built a public API representation for this complexity. This is a known gap in the Workspace API ecosystem, and admins have asked for it. Until it ships, automated tools are blind to trust rule behavior.
How to export trust rules
Since there is no API and no export button, the only way to capture trust rules is through browser developer tools. Here is how.
1. Open the Trust Rules page
Navigate to Admin Console > Apps > Google Workspace > Drive and Docs > Trust rules.
2. Open browser developer tools
Press F12 or Ctrl+Shift+I. Go to the Network tab.
3. Filter for trust rule requests
Filter network requests for trustrules or trust_rules. Reload the page if needed.
4. Copy the JSON response
Click the matching request, go to the Response tab, and copy the JSON payload. You may need to click into individual rules to capture their full details.
5. Save as a JSON array
Compile all rules into a single JSON array and save as trust_rules.json alongside your config.yaml.
Each trust rule in the JSON array looks like this:
{
"name": "policies/akajj264ao44de54dq",
"displayName": "Block external sharing for Finance",
"status": "ACTIVE",
"targets": {
"includedEntity": [
{ "ouId": "03ph8a2z12getl8" }
]
},
"trigger": [
"DRIVE_SHARE_TRUST",
"DRIVE_RECEIVE_TRUST"
],
"action": [
{ "actionName": "BLOCK_SHARE" }
],
"ruleType": "TRUST"
}
Then add one line to your config.yaml:
options: trust_rules_file: "./trust_rules.json"
How gws-auditor uses trust rules
When the auditor starts, it loads the trust rules file (if configured) and maps OU paths to OU IDs from the organization's directory data. During Drive sharing checks, it looks up whether any active trust rules apply to each OU being evaluated.
BLOCK_SHARE rule applies
The OU is treated as safe. The trust rule provides stronger protection than the warning or restriction the check evaluates. The false positive is suppressed. Result: PASS.
ALLOW_SHARE or ALLOW_SHARE_WITH_WARNING rule applies
The trust rule exists but does not fully block sharing. It may allow sharing with conditions or show a warning. The tool cannot parse the full CEL condition to determine if this is sufficient, so it returns MANUAL with the rule details for human review.
No trust rule applies
No trust rule covers this OU for this trigger type. The check evaluates the global policy as before. Result: FAIL if the global setting is permissive.
This logic is currently integrated into two Drive sharing checks: CIS-3.1.2.1.1.1 (ensure users are warned when sharing outside domain) and CIS-3.1.2.1.1.2 (ensure users cannot publish files publicly). More Drive checks will follow in future releases.
Limitations and what is next
This is a pragmatic workaround, not a clean solution. The limitations are real.
Manual export is required
There is no API to automate this. The export must be repeated every time trust rules change. A stale file means stale results.
CEL conditions are not parsed
The tool checks the actionName field (BLOCK_SHARE, ALLOW_SHARE, etc.) but does not evaluate the CEL expression in the condition. Complex trust rules with specific domain or label conditions are treated conservatively.
Only 2 of ~15 Drive checks are integrated
The same trust rule logic should apply to checks for domain allowlists, access checkers, non-Google sharing, and more. This will expand in future releases.
The ideal future: a Trust Rules API
If Google ships a public API for trust rules, all of this complexity disappears. The auditor would read the rules directly, evaluate them against each OU, and report accurately without manual intervention. That day is not here yet.
What admins should do now
- 1 Check if you use trust rules. Admin Console > Apps > Drive and Docs > Trust rules. If you have active rules, they are probably causing false positives in your audit.
-
2
Export the rules. Use browser dev tools to capture the JSON. Save as
trust_rules.json. -
3
Configure and re-run. Add
trust_rules_fileto your config.yaml and run the audit. The false positives on CIS-3.1.2.1.1.1 and CIS-3.1.2.1.1.2 should resolve. - 4 Re-export when rules change. Trust rules do not auto-sync. Update the JSON file whenever you modify rules in the Admin Console.
Trust rules represent one of the hardest audit gaps in Google Workspace. They are the right security control, but they are invisible to automated tools. This integration is a pragmatic step until Google provides API access. If you are dealing with false positives on Drive sharing checks, load your trust rules and see the difference.