Microsoft Calendar can be connected to permissioned agents via the official API (Microsoft Graph) with enterprise buildout controls, but it should not be treated as a “simple tool” you hand to a model. Calendar write access is an operational control surface: it can move meetings, leak attendee lists, and create social-engineering leverage.
In Claw EA, run the agent in OpenClaw as the baseline runtime, and make calendar actions pass through policy-as-code gates: a WPC, CST issuance, and verified logging via gateway receipts and proof bundles. Prompt-only constraints are not sufficient because prompts are editable, bypassable, and do not bind to identity, scopes, or an audit trail.
Step-by-step runbook
-
Define the calendar blast radius. Decide which mailboxes/calendars are in scope (service mailbox vs human mailbox), what time horizon is allowed (for example, “next 30 days”), and what actions are permitted (read-only, create tentative holds, invite-only, or full edits).
Write this down as operational rules first, then encode it as policy so enforcement does not depend on model compliance.
-
Choose an identity pattern in Entra ID. Prefer a dedicated non-human identity, and plan how consent and Microsoft Graph permissions/scopes will be granted and reviewed. Use Conditional Access and PIM where applicable so privileged approvals are time-bound and visible.
This step is where most deployments fail: excessive scopes or ambiguous ownership turns calendar access into “tenant-wide scheduling powers.”
-
Attach a WPC to the job. Publish a WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols) that defines allowed tool actions (calendar read vs write), required approvals, and logging requirements. The agent run should pin the policy hash so the job cannot silently drift to a different policy version.
This is the core difference from prompt-only: the WPC is enforced outside the model, and is stable under adversarial prompts.
-
Issue a CST for this run. Get a CST = scoped token (issued by clawscope) that is job-scoped and includes a scope hash that matches the WPC constraints. If you use policy hash pinning, bind the CST to the exact WPC hash used by the job.
This prevents “token reuse” across jobs and reduces the value of any leaked credential material.
-
Execute calendar calls via official API with explicit scope checks. Implement the Microsoft Graph calls in your enterprise buildout, and force the agent to request actions in structured form (for example: create event, list free/busy). Before executing, validate that the request matches the WPC and that the Graph permission being used is least-privilege for that action.
When in doubt, start with read-only and only allow create events with “tentative” status and limited attendee domains.
-
Route model traffic through clawproxy for receipts. Send the model calls through clawproxy so you get gateway receipts = signed receipts emitted by clawproxy for model calls. Store a proof bundle = harness artifact bundling receipts and related metadata for audit/verification for each run.
This creates an after-action record you can verify later, instead of relying on application logs that can be incomplete or altered.
Threat model
Calendar tools are attractive targets because they combine identity, presence, and influence. A malicious or misconfigured skill/plugin can do real damage without touching code repos or production infrastructure.
| Threat | What happens | Control |
|---|---|---|
| Over-broad Microsoft Graph permissions | Agent can read or modify calendars beyond the intended mailbox, or enumerate users/attendees at scale. | Least-privilege Graph permissions/scopes, Entra admin consent reviews, and a WPC that denies actions outside a mailbox allowlist. |
| Prompt injection via meeting content | Meeting descriptions or attendee emails instruct the agent to reschedule, cancel, or exfiltrate details. | WPC gates for write actions, structured tool requests, and separation between “read context” and “execute change.” |
| Social engineering amplification | Agent invites external attendees, adds phishing links, or creates meetings that appear legitimate. | WPC rules on attendee domains, link handling, and a required human approval step for external invites (implemented in enterprise buildout). |
| Replay and cross-job token reuse | A captured token or job artifact is reused to perform calendar writes later. | Job-scoped CST binding (anti-replay) and short TTL issuance; deny long-lived tokens for agent runs. |
| Undetected tool drift | Agent behavior changes because the “policy in the prompt” changed, or the tool implementation changed, but no one notices. | Pin the policy hash in the CST and require WPC fetch/verify before execution; store proof bundles per run for audit diffs. |
Policy-as-code example
This example shows the shape of a policy you would package into a WPC and pin for a job. It is intentionally narrow: read availability, create tentative holds, and forbid cancel/reschedule without approval.
{
"policy_name": "m365_calendar_permissioned_agent_v1",
"tool": "microsoft_calendar_via_graph_api",
"allowed_mailboxes": ["scheduling-bot@corp.example"],
"allowed_actions": [
{ "action": "calendar.read.freebusy", "constraints": { "horizon_days": 30 } },
{ "action": "calendar.event.create", "constraints": { "show_as": ["tentative"], "max_duration_minutes": 60 } }
],
"denied_actions": [
"calendar.event.cancel",
"calendar.event.update.attendees",
"calendar.event.update.time"
],
"approval_gates": [
{ "action_prefix": "calendar.event.", "require": "human_approval_for_external_attendees" }
],
"auth": {
"entra_id": {
"token_type": "app_or_delegated",
"graph_permissions_scopes": ["least_privilege_required"]
}
},
"run_controls": {
"require_cst": true,
"cst_scope_hash_required": true,
"optional_policy_hash_pinning": true
},
"audit": {
"require_gateway_receipts_for_model_calls": true,
"emit_proof_bundle": true
}
}
What proof do you get?
For the model side, clawproxy emits gateway receipts for each model call routed through it. Those receipts let you later verify what the model was asked, what it returned, and which run the call belonged to.
Claw EA packages receipts into a proof bundle, along with run metadata needed for audit and verification. If you store the resulting artifact in Trust Pulse, you get a stable place to view and review the evidence across runs, including job-scoped anti-replay binding via the CST.
For Microsoft Calendar actions, you should also retain your enterprise buildout logs (Graph request metadata, mailbox targeted, and resulting event IDs). The key operational point is correlation: the proof bundle anchors the model decisions, while Graph logs anchor the external side effects.
Rollback posture
Calendar changes are partially reversible, but the safest posture is to design actions that create minimal harm by default. Use tentative holds, avoid cancellations, and keep all writes attributable to a dedicated mailbox so you can quarantine and review quickly.
| Action | Safe rollback | Evidence |
|---|---|---|
| Agent created a tentative hold | Delete the event from the service mailbox; notify internal attendees if any were invited. | Proof bundle for the run; Graph event ID and timestamps from enterprise logs. |
| Agent invited external attendees (should be gated) | Cancel the event, rotate the CST issuance rules for the next runs, and require approval for external domains. | WPC that should have denied it (or proof of missing gate); proof bundle showing the model request path. |
| Agent rescheduled or canceled a real meeting | Restore from mailbox audit data where possible and re-issue corrected invites; temporarily disable calendar writes. | Run-level CST binding, proof bundle to trace why it happened, and Entra sign-in/audit trails. |
| Suspected token misuse | Revoke the CST, rotate underlying app credentials if applicable, and reduce Graph permissions/scopes. | CST issuance and revocation records; proof bundle showing which job the CST was bound to. |
FAQ
Is Microsoft Calendar support a native Claw EA connector today?
No. Microsoft Calendar can be connected via official API with enterprise buildout controls, and the run can still be permissioned and audited with WPC, CST, gateway receipts, and proof bundles.
Why is prompt-only control not enough for calendar agents?
Prompt rules are not an enforcement layer: they can be overridden by injection, model error, or tool drift. A WPC and CST make permissions machine-checked, job-scoped, and verifiable even when the model output is adversarial.
What Microsoft security controls matter most for calendar agents?
Use Entra ID as the identity boundary, and be strict about Microsoft Graph permissions/scopes and consent. Conditional Access and PIM help reduce standing privilege and make elevated access visible when you need it.
Can you prove what the model did during scheduling?
You can prove the model-call side when routed through clawproxy because you get gateway receipts and a proof bundle per run. For the external calendar side effects, you should correlate with Graph request logs from your enterprise buildout.
How do you prevent replay of a previous “approved” run?
Use job-scoped CST binding (anti-replay) and keep token TTL short. Pin the policy hash so an old token cannot be reused under a different WPC.