Google Drive is a high-risk tool for enterprise agents because it combines broad read access, easy sharing, and the ability to overwrite source-of-truth documents. For permissioned agents, you should connect Drive via official API with enterprise buildout controls, and run every write, share, move, delete, and permission change behind a Work Policy Contract (WPC) gate.
OpenClaw is a solid baseline runtime for tool execution, but prompt-only “be careful” rules do not hold under prompt injection or plugin mistakes. You need policy-as-code that is verified at execution time, with scoped tokens (CST) and auditable artifacts like gateway receipts and proof bundles.
Step-by-step runbook
Use this runbook to make Drive access useful without giving an agent a “delete the company’s files” lever. The key is to separate discovery from mutation, and to require explicit approvals for anything that changes Drive state.
-
Define a WPC for Drive work. Make the WPC enumerate allowed actions (read, list, export) and a separate section for mutations (create, update, move, delete, share). Keep mutation default-deny, and require an approval gate for each mutation class.
-
Choose the smallest feasible auth model. For enterprise buildout you typically use OAuth or a service account (if applicable to your org’s Drive model) via official API. Map each agent job to a distinct identity or delegated context so you can reason about least privilege and revocation.
-
Issue a CST per job from clawscope. Bind the CST to the job and (optionally) pin the policy hash so the tool can only run under the intended WPC. Treat the CST as short-lived and non-reusable across jobs.
-
Enforce “read-first” workflows. Require the agent to list files and present a plan including file IDs, target folders, and a diff-like summary before any write. Only then request WPC-gated approval for the exact file IDs and operations.
-
Route model calls through clawproxy when the model is involved. When the agent uses a model to interpret file content, classify documents, or generate edits, route those calls through clawproxy to emit gateway receipts for model calls. This makes later dispute resolution possible when someone asks “why did the agent do that?”
-
Bundle evidence at the end of the run. Produce a proof bundle that ties together the CST scope hash, WPC hash, and gateway receipts (plus your run metadata). Store or publish the artifact to Trust Pulse when you need a durable audit/viewing surface.
Threat model
Drive failures tend to be irreversible in human time, even if the API supports recovery, because the damage spreads through sharing, sync clients, and downstream copies. Model behavior plus a permissive token often equals a large blast radius.
| Threat | What happens | Control (permissioned execution) |
|---|---|---|
| Prompt injection from a document | The agent reads a file that contains instructions to exfiltrate content, broaden sharing, or delete competing evidence. | WPC denies share/delete by default; CST is scoped to read-only unless an approval gate is satisfied. Use “read-first” plus explicit file-ID allowlists per job. |
| Overbroad OAuth scopes or delegated access | The agent can access the entire Drive, including sensitive folders unrelated to the task. | Least-privilege scopes and narrow resource targeting in the WPC (folder IDs, shared drive IDs, file patterns). Use a dedicated identity per workflow where possible and rotate access frequently. |
| Accidental destructive writes | The agent overwrites the wrong file, replaces a template, or edits a policy doc in-place. | WPC requires “create new draft” instead of in-place edit for high-value folders; mutation operations require explicit approval and target constraints (specific file IDs only). |
| Permission sprawl via sharing | The agent shares a folder to the wrong domain or makes files discoverable to “anyone with the link”. | WPC blocks public-link sharing and external domains; require an approval gate with a concrete recipient list. Keep a second, stricter WPC for permission changes than for content edits. |
| Replay or cross-job token reuse | A token captured from logs or a prior run is reused to perform actions later. | Job-scoped CST binding (anti-replay) and short TTL; store secrets outside prompt-visible logs. Validate the CST scope hash and (optionally) policy hash pinning on every call. |
| Silent policy drift | Someone updates a prompt or tool config and the agent starts doing broader actions without a clear change record. | WPC is signed and hash-addressed; pin to the policy hash so runs fail closed if the policy changes. Store proof bundles for each job to show what policy was in force. |
Policy-as-code example
This is a JSON-like sketch of the kind of WPC you want for Drive. The point is to make the allowed operations explicit and machine-verifiable, not implied by a prompt.
{
"wpc_version": "1",
"tool": "google_drive_via_official_api",
"policy": {
"default": "deny",
"allow": [
{ "action": "drive.files.list", "constraints": { "folder_ids": ["FOLDER_123"], "max_results": 50 } },
{ "action": "drive.files.get", "constraints": { "file_ids": ["FILE_A", "FILE_B"], "export_formats": ["text/plain", "application/pdf"] } }
],
"approval_gates": [
{
"gate": "human_approval",
"allows": [
{ "action": "drive.files.create", "constraints": { "parent_folder_id": "FOLDER_123", "name_prefix": "agent-draft-" } },
{ "action": "drive.files.update", "constraints": { "file_ids": ["FILE_A"], "require_etag_match": true } },
{ "action": "drive.permissions.create", "constraints": { "file_ids": ["FILE_A"], "allow_domains": ["example.com"], "deny_public_link": true } },
{ "action": "drive.files.delete", "constraints": { "file_ids": ["FILE_TMP_ONLY"], "deny_shared_drives": true } }
]
}
],
"logging": { "redact": ["file_content", "oauth_tokens"] }
},
"cst_requirements": {
"require_job_binding": true,
"require_scope_hash_match": true,
"optional_policy_hash_pinning": true
}
}
In practice you also add folder-level “crown jewels” rules: policies, legal, payroll, and key customer folders should be read-only for agents unless a separate break-glass WPC is used. If you cannot express those rules cleanly, the tool should not be enabled.
What proof do you get?
For model-involved steps, clawproxy emits gateway receipts for model calls. Those receipts let you verify which model was called, when, and under which job context, instead of relying on logs that can be incomplete or tampered with.
At the end of a job, you can produce a proof bundle that packages receipts plus the run metadata you care about, including the WPC hash and CST scope hash. When you need a durable audit/viewing record, store the bundle as a Trust Pulse artifact so reviewers can reference the exact run that made a Drive change.
This matters most for Drive write paths: a change ticket should be able to point to a specific proof bundle, not a screenshot of a chat. If an incident happens, you can answer: what policy allowed it, what token scope permitted it, and what model calls influenced the decision.
Rollback posture
Drive supports recovery patterns, but an agent can still do damage faster than humans can respond. Your rollback strategy should assume partial recovery and focus on preventing unsafe mutations in the first place.
| Action | Safe rollback | Evidence to retain |
|---|---|---|
| Create new files (draft outputs) | Delete drafts, or move them to a quarantine folder; prefer drafts in a dedicated folder to simplify cleanup. | WPC hash, CST scope hash, file IDs created, and the proof bundle for the job. |
| Update existing files | Restore from prior revisions where available; require pre-write snapshotting in your workflow. | Before/after metadata, revision identifiers if captured, and any gateway receipts tied to content generation. |
| Move/rename | Move back using recorded file IDs and previous parent folder IDs; avoid path-based logic. | Move plan, target folder IDs, and the approval record referenced by the WPC gate. |
| Permission changes and sharing | Revoke permissions; re-check inheritance and link-sharing settings; notify affected owners. | Exact recipients/domains changed, timestamped approval context, and proof bundle pointer in Trust Pulse. |
| Delete | Recover from trash if possible; treat as break-glass only and deny by default in the primary WPC. | Deletion intent record, file IDs, and proof bundle showing the specific approval gate used. |
If you want stronger containment, egress allowlists enforced outside clawproxy can be implemented as an extra layer, but you should still assume the agent can make harmful API calls if you grant broad Drive permissions. Keep the WPC as the primary decision point for what the agent is allowed to do.
FAQ
Is this a native Google Drive connector in Claw EA?
No. Google Drive can be connected via official API with enterprise buildout controls, and you should treat it as an integration that is implemented and governed per environment.
Why isn’t a “don’t delete files” prompt enough?
Prompts are not enforcement. Prompt injection, tool bugs, and mis-scoped credentials turn a suggestion into a best-effort, so the execution layer must be permissioned with policy-as-code that is evaluated at the moment of the API call.
What Drive actions should always require approval?
Start with share/permission changes, deletes, moves across shared drives, and edits to high-value folders. In many enterprises, even “update” should be restricted to draft-only workflows unless the file is explicitly allowlisted by ID.
How do CST and WPC work together for Drive?
The CST is the scoped token presented by the job, and the WPC is the signed Work Policy Contract that describes what the job is allowed to do. You validate the CST scope hash and optionally pin the policy hash so a token cannot be reused under a different policy.
What audit artifacts should we expect after a Drive-writing job?
Expect gateway receipts for model calls (when the model is used) and a proof bundle tying together receipts, WPC hash, CST scope hash, and run metadata. If you store it as a Trust Pulse artifact, reviewers can reference a stable record for audits or incident response.