feat(preset): add PATCH method to Outlook preset for Graph API updates

[stevenobiajulu]

Problem Statement

The Outlook network policy preset currently allows only GET and POST on graph.microsoft.com. Microsoft Graph API uses PATCH for common, non-destructive email operations that enterprise email agents need — marking messages as read, flagging emails for follow-up, and updating draft messages. Agents running inside an OpenClaw sandbox with the Outlook preset cannot perform these operations because the PATCH method is denied by policy.

These are standard triage operations, not destructive actions. An email agent that can read and draft emails (GET + POST) but cannot mark messages as read or flag them for follow-up has limited practical utility.

Real Graph API calls demonstrating PATCH requirement

Tested against Microsoft Graph API v1.0:

=== GET /messages/{id} — read email metadata ===
Method: GET
Status: 200 ✓ (allowed by current preset)

=== PATCH /messages/{id} — mark as read ===
Method: PATCH
Status: 200 ✓ (works against Graph API, but blocked by preset)
Body: {"isRead": true}

=== PATCH /messages/{id} — flag for follow-up ===
Method: PATCH
Status: 200 ✓ (works against Graph API, but blocked by preset)
Body: {"flag": {"flagStatus": "flagged"}}

There is no GET or POST alternative for these operations. The Graph API requires PATCH for in-place property updates on messages and events.

Additional operations requiring PATCH

Operation	Endpoint	Method	Use Case
Mark message as read	PATCH /me/messages/{id}	PATCH	Email triage
Flag message for follow-up	PATCH /me/messages/{id}	PATCH	Task management
Update draft message	PATCH /me/messages/{id}	PATCH	Refine draft before send
Update calendar event	PATCH /me/events/{id}	PATCH	Reschedule meeting

Found while testing a Microsoft Graph email/calendar workflow inside an OpenClaw sandbox.

Policy gap

The current outlook.yaml graph.microsoft.com rules:

rules:
  - allow: { method: GET, path: "/**" }
  - allow: { method: POST, path: "/**" }

A unit test loading the Outlook preset and checking for PATCH on graph.microsoft.com confirms the gap.

Proposed Design

Add one PATCH rule to the graph.microsoft.com endpoint in outlook.yaml:

rules:
  - allow: { method: GET, path: "/**" }
  - allow: { method: POST, path: "/**" }
  - allow: { method: PATCH, path: "/**" }   # <-- new

Scope: Only graph.microsoft.com. The other endpoints in the preset (login.microsoftonline.com, outlook.office365.com, outlook.office.com) do not need PATCH — authentication uses GET/POST only, and the legacy endpoints are not used for Graph API update operations.

Not included: PUT (Graph API uses PATCH, not PUT, for updates) and other HTTP methods not needed for standard email/calendar workflows.

A regression test is included to prevent future regressions.

Alternatives Considered

1. Wildcard method: "*" — Rejected. This would permit all HTTP methods including PUT and others not needed for email workflows. The principle of least privilege favors explicit method rules. See also Inference and telemetry policies allow all HTTP methods — wildcard rules permit destructive API operations #1113 re: wildcard concerns.

2. No change — Agents can run email workflows outside the sandbox, but this defeats the purpose of sandboxed execution. The Outlook preset exists specifically to enable Graph API workflows inside sandboxes.

Category

enhancement: feature

Checklist

• I searched existing issues and this is not a duplicate
• This is a design proposal, not a "please build this" request