Managing Drive Sharing: Classic Settings vs Trust Rules, and gws-auditor v1.4.0

Drive sharing is the control most likely to be both over-restricted and under-restricted in the same tenant. The classic sharing settings force a trade-off: lock down external sharing globally and break legitimate collaboration, or leave it open and hope warnings are enough. Trust rules resolve that trade-off, and with gws-auditor v1.4.0, released this week, your audit results finally reflect how you actually manage sharing.

The short version

Without trust rules, Drive sharing is managed through per-OU sharing settings: one external-sharing level per OU, inherited down the tree, with exceptions requiring OU restructuring.
Trust rules layer conditional sharing policies on top: who can share, who can receive, scoped to OUs or groups, with explicit block / allow / warn actions. They are the recommended way to implement the restrictive defaults that CIS and Google's security best practices call for, without breaking collaboration.
gws-auditor v1.4.0 loads an exported trust rules file and resolves rules per OU during Drive sharing checks: blocking rules turn false-positive FAILs into PASS, permissive rules trigger MANUAL review, and designated external-sharing OUs downgrade FAIL to PARTIAL.

Part 1: Managing Drive sharing without trust rules

The classic model lives under Admin console > Apps > Google Workspace > Drive and Docs > Sharing settings. You pick an organizational unit in the left-hand tree, and every setting you change applies to that OU and everything below it unless a child OU overrides it. There are no conditions and no second dimension: the OU you selected is the entire targeting model.

The settings themselves map directly onto the CIS Google Workspace Foundations Benchmark's Drive controls (section 3.1.2), which is also exactly what gws-auditor evaluates:

Setting	What it controls	CIS check
Sharing outside the organization	On / off / allowlisted domains only, per OU	CIS-3.1.2.1.1.3
Warn on external sharing	A confirmation dialog before sharing outside the domain	CIS-3.1.2.1.1.1 / .4
Publish files on the web	Whether users can make files public to anyone	CIS-3.1.2.1.1.2
Access Checker	Who a user can grant access to when a recipient lacks it	CIS-3.1.2.1.1.5
Content distribution	Whether non-members can move content outside the org	CIS-3.1.2.1.1.6
Link-sharing defaults	The default visibility of newly created files	CIS-3.1.2.1.2.x
Shared drive settings	Creation, manager overrides, member access, viewer downloads	CIS-3.1.2.2.x / .3.x

This model works, and for small tenants it is enough. But it strains as soon as reality gets more granular than your OU tree. The pain points are predictable:

Exceptions require restructuring

The only targeting unit is the OU. If Legal needs external sharing but sits inside an OU that must not have it, you either move Legal to a new OU (with every side effect that carries for other policies) or you weaken the parent OU for everyone. Many tenants end up with OUs named External Sharing or Contractors that exist purely to carry a sharing exception.

One direction, one dial

The classic settings blend sharing out and receiving in into a single external-sharing level. You cannot say "Finance may receive files from partners but never share out": the setting is one dial per OU.

The allowlist is global

Domain allowlisting is all-or-nothing: one list of trusted domains for the whole tenant. Sales' partner domains and Engineering's vendor domains end up in the same list, and every allowlisted OU trusts all of them.

Inheritance drift

Every override breaks the inheritance chain silently. Two years and three admins later, nobody can say which OUs override what without clicking through the tree OU by OU, which is precisely why automated auditing of these settings matters.

Part 2: Why trust rules are the recommended model

Trust rules (Admin console > Apps > Google Workspace > Drive and Docs > Trust rules, available on Enterprise Standard and Plus, Education Standard and Plus, and Enterprise Essentials Plus) replace the single dial with a rule engine. Each rule has a scope (OUs or groups it applies to), a trigger (sharing out via DRIVE_SHARE_TRUST, receiving in via DRIVE_RECEIVE_TRUST), and an action: block, allow, or allow with a warning.

Crucially, trust rules supersede the classic sharing settings rather than supplementing them. That changes how you architect sharing policy:

Default-deny with surgical exceptions

The CIS benchmark's Drive controls all push in one direction: external sharing restricted, warnings on, public publishing off. The classic model makes you choose between that posture and collaboration. With trust rules you keep the restrictive baseline everywhere and open exactly the flows you mean to: a blocking rule tenant-wide, then narrow allow rules for the teams and partner domains that need them. That is the least-privilege pattern CIS codifies and Google's own security best-practice guidance for managing external sharing recommends for enterprise tenants.

Group scoping ends OU gymnastics

Rules can target groups, not just OUs. The "external collaborators" population becomes a group membership instead of an OU relocation, and the exception follows the person, not the org chart.

Directional control

Separate triggers for sharing and receiving mean Finance can receive external documents while being blocked from sharing out, a policy the classic settings simply cannot express.

Policy as intent, not side effect

A named rule like "Block external sharing for Finance" is auditable intent. An OU whose inherited settings happen to produce the same behavior is an accident waiting for a reorg. When your sharing posture is a list of explicit rules, reviews, change control, and audits all get easier.

The catch

Trust rules are not exposed by any public Google API: not the Cloud Identity Policy API, not the Admin SDK. The moment you adopt them, every automated audit tool starts reporting on the classic settings you just superseded. We covered this gap in depth in our trust rules deep dive, including how to export your rules to JSON with browser dev tools. Version 1.4.0 is where that export starts paying off.

Part 3: gws-auditor v1.4.0: trust-rule-aware scanning

Version 1.4.0, released August 3, makes the auditor trust-rule-aware. Point the new options.trust_rules_file config key at your exported JSON:

options:
  trust_rules_file: "./trust_rules.json"
  # optional: OUs that intentionally share externally
  external_sharing_ous:
    - "/External Collaboration"
    - "*Contractors*"

The provider loads the file on live runs and on --cached re-scoring alike, so you can re-evaluate an existing audit cache against a fresh rules export without re-collecting anything, and without credentials on the machine. During Drive sharing checks, the auditor maps each OU path to its OU ID and looks up active rules whose scope includes that OU for the DRIVE_SHARE_TRUST trigger. Inactive rules, rules for other triggers, and rules for other OUs are ignored.

How check outcomes change

Two checks integrate the logic in this release: CIS-3.1.2.1.1.1 (warn when sharing outside the domain) and CIS-3.1.2.1.1.2 (users cannot publish files publicly). For each OU that would previously have failed, the verdict now depends on what actually governs sharing there:

What applies to the OU	Before 1.4.0	With 1.4.0
Trust rule with `BLOCK_SHARE`	FAIL	PASS; the rule is stronger than the warning the check asks for
`ALLOW_SHARE` or `ALLOW_SHARE_WITH_WARNING`	FAIL	MANUAL; the result names the rules so you can judge their conditions
Designated external-sharing OU (name pattern or config)	FAIL	PARTIAL; intentional exceptions stay visible but stop tanking the score
Nothing, just a permissive classic setting	FAIL	FAIL; a real finding stays a real finding

Precedence matters here: an explicit trust rule always wins over the external-sharing OU naming heuristic, because a rule is a deliberate control while an OU name is only a convention. And if any OU still fails outright, the check fails as a whole; trust-rule and exception OUs are then listed alongside the failures in the details rather than hiding them.

The external-sharing OU logic works even without a trust rules file. With no configuration, a built-in pattern set applies (*External*, *Contractors*, *Vendors*, and similar), and options.external_sharing_ous accepts your own OU paths or fnmatch patterns.

Also in 1.4.0

Human-readable report values

127 per-OU failure lists now render as readable /Sales → Enabled lines instead of raw dicts, and roughly 400 expected values moved from bare booleans to phrases like "Enabled for all OUs". Calendar sharing enums are humanized too.

PARTIAL fully wired in

The PARTIAL status introduced in 1.3.0 now counts as a half-failure in the posture score (previously the score and pass rate disagreed) and appears across the HTML report, dashboard, console output, and AI analyst.

Stricter super admin ceiling

CIS-1.1.2 now FAILs at 4 or more super admin accounts instead of warning, matching the benchmark's "fewer than four" guidance.

Admin console deep links re-verified

Every remediation deep link was re-checked against the live Admin console (June 2026). Per-app settings pages use customer-specific paths that cannot be hardcoded, so app links now land one click away on the apps list instead of 404ing.

Getting started

1 Upgrade: pip install --upgrade gws-auditor, or let the built-in version check prompt you.
2 Export your trust rules to JSON using the step-by-step dev-tools walkthrough in the deep dive.
3 Add trust_rules_file (and, if it fits your tenant, external_sharing_ous) to your config.yaml.
4 Re-run the audit, or re-score an existing cache with gws-auditor --cached ./cache/audit.json to see the delta immediately.
5 Re-export when rules change. Until Google ships a Trust Rules API, the JSON file is a snapshot, so keep it current.

If you are on an Enterprise edition and still managing Drive sharing purely through the classic settings, trust rules are worth the migration: they let you hold the restrictive posture the benchmarks ask for while giving the business the exceptions it needs. And now, for the first time, adopting them will not cost you your audit accuracy.

Managing Drive sharing: classic settings vs trust rules