Workspace AI access policy — a playbook

The File Access Control guide explains the mechanics: sources, the pooled predicate, deny-wins, enforcement points. This page is for the security / IT team deciding what your organization's policy actually is — which shared drives, folders, and labels are approved or denied, who controls each lever, how to roll it out, and what to tell employees. Fill in the template at the end and you have your Workspace AI access policy plus a ready-to-send staff communication.

The three levers

Everything reduces to three ways to say "an AI agent may (or may not) see this file." An operator combines them freely; each has a different owner and grain.

Lever	Who sets it	Grain	Best for
Shared drive (by drive ID)	Security team (config)	Whole drive, transitive — every file at any depth	A team/project's entire AI-usable corpus; the clean "subtree" boundary
Folder (by folder ID)	Security team (config)	The folder itself + its direct children only (one level, no tree walking)	A specific folder whose immediate contents should be reachable
Label (by label ID)	Taxonomy: Workspace admin. Applying: any employee with edit access	A single file, anywhere	Per-file opt-in by the file's owner; hard exclusions (restricted labels)

Two properties decide how you combine them:

• Approvals are OR. A file is reachable if it's in an approved shared drive or an approved folder or carries an approved label. Adding a lever widens reach.
• Deny always wins. A restricted label, blocked folder, or blocked drive denies the file no matter how many approvals it also has. These are your hard guardrails — use them for content that must never reach an agent.

Who owns what: central vs. self-service

This split is the heart of the policy, and worth stating explicitly to both teams:

• Security team (central, by ID in config): approves/blocks shared drives and folders, defines the label taxonomy in the Workspace Admin console, and sets the restricted labels and blocked folders/drives. Folder and drive governance is admin-only — an employee cannot approve a folder for the agent.
• Employees (self-service, by label): apply the approved label to opt one of their own files in, anywhere in Drive, without moving it or changing sharing. Employees cannot create labels or approve folders.

Why this split: a per-file label is a contained grant the file's owner understands; approving a whole folder or drive can over-expose everything inside it, so it stays with the security team. Design your policy so the default corpus comes from a small set of approved drives/folders the security team controls, and labels are the employee-driven exception path.

Design decisions to make

1. What is AI-usable by default? Identify the shared drives / folders that hold content agents should be able to read. Prefer a dedicated shared drive ("AI Working Set") over scattering approved folders — it's transitive, so nested content is covered, and membership (a Drive-native, self-service action) then controls reach.
2. What must never be reachable? Pick the restricted label(s) (e.g. Confidential, Restricted) and the blocked drives/folders (e.g. an HR or Legal Hold drive). These win over every approval.
3. How do employees opt a file in? Choose one approved label (e.g. AI-Available) and publish it so staff can apply it.
4. Which surfaces are governed? List the connector resource types to govern (google-drive, google-docs, google-sheets, google-slides, confluence). A surface you omit is ungoverned.
5. Folders vs. shared drives for a team. If a team's content spans nested folders, put it in a shared drive and approve the drive (one entry, whole tree). Reserve folder approval for a single folder's direct contents.
6. What do agent-created files get? Set a default label (one of the approved labels) so files an AI assistant creates are auto-labelled and immediately usable — otherwise the assistant can't read back its own output. This is also a provenance signal: everything AI-authored carries it.

Rollout in stages

1. Inventory & define. List candidate drives/folders; create + publish the approved and restricted labels in the Admin console (see Google file access setup).
2. Pilot (observe). Govern one connector with one approved drive/label and a restricted label. Confirm expected files return and restricted ones don't.
3. Communicate. Send staff the communication below before enforcing broadly, so opt-in labelling and expectations are in place.
4. Enforce & expand. Add the remaining approved drives/folders and governed resource types. Restricted labels and blocked drives/folders are your standing guardrails.
5. Audit. When a file is withheld, the audit reason names the deciding rule (blocked_match or not_in_required) over the pooled sets — so "why did this file vanish?" traces to the exact restricted label / blocked folder or the missing approval.

Policy template (fill this in)

<Org> Workspace AI Access Policy — complete each row, then translate into the operator config below.

Decision	Your value(s)
Approved shared drive(s) — AI-usable corpus	<drive name → drive ID>
Approved folder(s) — direct contents reachable	<folder name → folder ID>
Blocked shared drive(s) / folder(s) — hard deny	<name → ID> (e.g. HR, Legal Hold)
Approved label — employee opt-in	<label name → label ID> (e.g. AI-Available)
Restricted label(s) — hard deny	<label name → label ID> (e.g. Confidential)
Default label for agent-created files	<one of the approved labels> (e.g. AI-Available)
Governed surfaces	<resource types> (drive, docs, sheets, slides, confluence)

Resulting operator config (pbac.operator.controls.file_access) skeleton — IDs go in required / blocked, resource types in governed; see File Access Control for the write call:

{
  "sources": {
    "org-labels":   { "type": "label",    "required": ["<AI-Available id>"], "blocked": ["<Confidential id>"], "default": { "label_id": "<AI-Available id>" } },
    "org-location": { "type": "location", "required": ["<approved drive/folder ids>"], "blocked": ["<blocked drive/folder ids>"] }
  },
  "governed": {
    "urn:connector:identos:google-drive":  ["org-labels", "org-location"],
    "urn:connector:identos:google-docs":   ["org-labels", "org-location"],
    "urn:connector:identos:google-sheets": ["org-labels", "org-location"],
    "urn:connector:identos:google-slides": ["org-labels", "org-location"]
  }
}

Employee communication (template)

Using AI assistants with our Google Workspace files

Our AI assistants can only open files you've made available to them. A file is available to AI if any of these is true:

• it lives in an approved shared drive (currently: <drive names>), or
• it lives in an approved folder we've designated, or
• you've applied the AI-Available label to it.

A file is never available to AI — even if the above is also true — if:

• it carries a Confidential (restricted) label, or
• it lives in a blocked drive/folder (currently: <e.g. HR, Legal Hold>).

Deny always wins, so restricted labels and blocked locations are safe hard stops.

To let an assistant use one of your files: apply the AI-Available label to it (Drive → right-click → Labels). To keep something out: apply Confidential, or keep it out of the approved drives/folders.

A few things to know:

• This only controls the AI assistant's access. It does not change who can open the file normally — your own and colleagues' Drive access is unchanged.
• Labels are visible in Drive and are audited; applying one is a separate permission from editing the file, on purpose.
• Approving a folder covers files directly in it — a file in a sub-folder isn't automatically covered. For a whole project tree, we use a dedicated shared drive instead.

Limitations to plan around

• Folder approval is one level (the folder itself + its direct children). Use a shared drive for a whole subtree.
• Folder/drive approval is admin-only and by ID — there's no employee self-service for locations, and no path-based matching (Drive has no paths). Labels are the self-service lever.
• Label matching is by label ID. Distinct approve/deny outcomes need distinct labels; matching on a single label's field values (public/internal/confidential) is a planned enhancement.
• Read / agent-path only. This governs what an agent retrieves through the gateway; it is not a Drive ACL and doesn't change normal human access.

Related docs

• File Access Control — the control's mechanics, predicate, and config schema.
• Google file access setup — creating labels, getting bare label/folder/shared-drive IDs, and the required OAuth scopes.