Google Calendar is a high-impact tool for enterprise agents because it touches real schedules, meeting links, attendees, and sometimes conferencing details. Claw EA treats Calendar access as permissioned execution: a Work Policy Contract (WPC) is verified before any write or admin action, and runs are bound to a CST and auditable with gateway receipts and a proof bundle.
This is different from “prompt-only” controls. Prompts can be rewritten or bypassed, but policy-as-code is enforced at the execution layer where the tool call and its authorization context are checked before it can affect a user’s calendar.
Step-by-step runbook
Use this runbook when you want OpenClaw as the baseline agent runtime, with Google Calendar connected via official API and enterprise buildout controls. The goal is to keep read access easy while gating writes, bulk operations, and admin-like behavior.
-
Define the business intent and blast radius. Decide which calendars the agent may touch, what time horizon it can operate on, and whether it can invite external attendees. Treat conference links, attendee lists, and event descriptions as sensitive data.
-
Author a WPC for Google Calendar actions. Encode allowed operations (read vs create vs update vs delete), scope limits (calendar IDs, organizer constraints), and approval gates for write/admin actions. Publish the signed WPC so it can be fetched and verified at runtime.
-
Issue a CST with policy hash pinning. Mint a CST (issued by clawscope) that is scoped to the Calendar tool and optionally pinned to the WPC hash. Use a short TTL and bind the CST to a specific job where possible to reduce replay risk.
-
Connect Google Calendar via official API with least-privilege OAuth scopes. Use explicit Google Calendar OAuth scopes appropriate for the WPC, and avoid broad scopes that enable silent escalation. For service accounts or delegated access, keep the delegation path documented and reviewable.
-
Route model calls through clawproxy for gateway receipts. Keep model traffic proxied so each model call emits gateway receipts. This gives you verification material when an event is created or modified due to a model decision.
-
Run in a constrained OpenClaw tool profile and sandbox. Use OpenClaw tool policy to expose only the Calendar tool and the minimum supporting tools (for example, text processing). Enable sandboxing for tool execution so a compromised plugin has less access to the host.
-
Store and verify the proof bundle after each run. Generate a proof bundle that ties together gateway receipts, policy hash, CST scope hash, and run metadata. Persist it for audit, and optionally publish it to Trust Pulse for review.
Threat model
Calendar is risky because it is both an action surface (creating and changing commitments) and a social surface (invites can trigger emails, chats, and external exposure). The table below lists common failure modes and the control you should enforce in Claw EA.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection causes unintended event creation | The agent schedules meetings the user did not ask for, possibly with external attendees. | WPC gates create/update actions, with explicit constraints (allowed calendars, domains, attendee limits). Use CST policy hash pinning so writes fail if the policy changes or is not the approved one. |
| Silent escalation via broad OAuth scopes | The tool can edit or delete across calendars beyond the intended set. | Least-privilege OAuth scopes mapped to WPC permissions. Treat any scope expansion as a policy change that requires a new WPC hash. |
| Bulk modification or deletion | A misconfigured loop edits hundreds of events or cancels recurring meetings. | WPC includes rate and count limits per run (can be implemented), plus mandatory approval gates for delete and series-level edits. |
| Data leakage through event bodies and attendee lists | Model prompts or logs inadvertently contain sensitive event text or guest emails. | OpenClaw logging redaction and minimal tool exposure. Proof bundles should record hashes and metadata, not raw sensitive bodies unless you explicitly choose to retain them. |
| Replay of an older “approved” action | An attacker reuses credentials or a captured token to repeat a prior write. | Marketplace anti-replay binding with job-scoped CST binding, plus short token TTLs. Verify the CST and job binding before executing any write. |
| Malicious or compromised plugin | The plugin attempts to exfiltrate credentials or pivot to host execution. | OpenClaw sandboxing and tight tool allowlists. Permissioned execution via WPC reduces what the plugin can do even if it can ask the model for harmful steps. |
Policy-as-code example
This is a simplified, JSON-like example of a WPC that constrains Google Calendar. The key idea is that writes are not “a good idea in the prompt”; they are explicitly enumerated and gated in the policy artifact that is verified before execution.
{
"wpc_version": "1",
"tool": "google_calendar",
"connection": "official_api",
"allowed_calendars": ["primary", "calendars/ops-team@company.example"],
"time_window_days": 30,
"permissions": {
"read": { "allowed": true },
"create_event": {
"allowed": true,
"approval_gate": "required",
"constraints": {
"max_attendees": 10,
"external_attendees": "deny",
"conference_links": "allow"
}
},
"update_event": {
"allowed": true,
"approval_gate": "required",
"constraints": { "series_edits": "deny" }
},
"delete_event": {
"allowed": false
}
},
"token_requirements": {
"cst_scope_hash": "must_match",
"policy_hash_pinning": "enabled"
}
}
In practice, the approval gate is enforced before tool execution, not after the model drafts a plan. If the agent attempts a write outside the policy, the run fails closed and you still get proof artifacts for review.
What proof do you get?
For model calls, clawproxy emits gateway receipts that can be verified later. These receipts let you show which model was called, when, and under what scoped context, without relying on “trust me” logs.
Each job can produce a proof bundle that packages the gateway receipts plus the run metadata needed for audit and verification. Typical metadata includes the WPC hash used, the CST scope hash, and the job binding used to reduce replay.
If you need a place to store and review an audit artifact, you can publish the resulting artifact to Trust Pulse. This is useful when security teams want a stable reference for a specific run, including the policy identity that governed it.
Rollback posture
Calendar automation needs a rollback plan that assumes the model will eventually do something surprising. The safest posture is to make rollback operationally cheap: revoke tokens, disable writes by policy, and keep the local runtime constrained.
| Action | Safe rollback | Evidence |
|---|---|---|
| Suspect token misuse | Revoke the CST and re-issue with narrower scope and shorter TTL. | CST issuance and revocation records, plus proof bundles showing the last authorized jobs. |
| Writes are behaving incorrectly | Update policy to deny create/update, publish a new signed WPC, and pin the CST to the new WPC hash. | WPC hash history and proof bundles showing which WPC governed each run. |
| Plugin or tool code is suspect | Remove the tool from the OpenClaw allowlist and re-run with sandboxing tightened (or disable the agent). | OpenClaw configuration state, plus proof bundles showing tool usage before disablement. |
| Need to explain a specific calendar change | Use the proof bundle and gateway receipts to reconstruct the decision path and authorization context. | Gateway receipts for model calls and the run’s proof bundle identifier. |
FAQ
Is this a native Google Calendar connector in Claw EA today?
No. Google Calendar can be connected via official API with enterprise buildout controls, and you should treat it as an integration project with explicit scoping, approvals, and verification requirements.
Why is policy-as-code required instead of prompt-only instructions?
Prompt-only controls are not enforceable at the tool boundary, so a misled or malicious prompt can still trigger a write. A WPC is verified before execution and can fail closed when the agent attempts an action that is not allowed.
What do you gate for “write and admin actions” on Calendar?
Creation, updates that change time or attendees, modifications to recurring series, deletions, and any operation that affects external recipients should be treated as gated. The WPC should encode those gates, and the CST should be scoped so the tool cannot silently expand permissions.
How do gateway receipts and proof bundles help in an audit?
Gateway receipts provide verifiable evidence of model calls made through clawproxy. The proof bundle ties those receipts to the job context, including which WPC and CST constraints were in force when the agent attempted Calendar operations.
Can we restrict egress so the agent only talks to Google APIs?
Egress allowlists enforced outside clawproxy are optional and can be implemented. If you need it, treat it as part of the enterprise buildout and ensure it is tested with failure modes that default to deny.