Write Guard

Write Guard makes every mutating RUCKUS One API call that Claude composes itself — through call_r1, and call_r1_gql for GraphQL mutations — stop and ask you first. It is opt-in, and if you point R1-MCP at a production tenant you should turn it on.

Enable it under Features in the dashboard.

How it works

Claude attempts a mutating call without a confirmation token.
The call is not sent. Instead the tool returns a confirm_required envelope containing a preview — what would run, and against which tenant — plus a single-purpose token.
Claude shows you the preview and waits for an explicit OK in the conversation.
On your OK, Claude re-sends the identical call with the token, and it executes.

The preview names the target connection — its label and tenant ID — so a confirmation tells you which tenant you’re about to change. With multiple connections configured, that matters.

The token can’t be reused elsewhere

The confirmation token is an HMAC over your user id and a canonical fingerprint of the exact call — method, path, parameters, query, body, headers, and the resolved connection id. Object keys are sorted recursively so a re-send that reorders fields still matches.

The consequences:

Changing anything about the call after the preview invalidates the token — the fingerprint no longer matches, and you get a fresh preview instead of a silent execution of something you didn’t approve.
A token minted for tenant A cannot be replayed against tenant B, because the connection id is part of the fingerprint.
Tokens expire ten minutes after the preview. Confirming an old preview gets you a new one rather than an execution.
A token is not single-use. It stays valid for its ten minutes against that exact call — the guard is a deliberate two-step safety net, not a security boundary. The security boundary is your R1 credential’s own permissions.

So “approve once, then quietly do something else” is not a failure mode available to the model.

What counts as a write

The rule is mechanical:

Call	Treated as
`GET`, `HEAD`	Read — sent without asking
`POST` whose last path segment is `query` or `search`	Read
Any other `POST`, and every `PUT`, `PATCH`, `DELETE`	Write — asks first
GraphQL document containing a `mutation`	Write — asks first

The guard errs toward over-asking. Some operations that are technically non-destructive — exports, comparisons, validations — still ask for confirmation. That’s a deliberate trade: a spurious confirmation costs you a sentence, and a missed one costs you a production change.

What it does not cover

Write Guard gates only call_r1 and call_r1_gql. These have their own safety models and do not pass through it:

device_cli — switch configuration over the live console
mop_replay and autopilot runs — dryRun, the unattended acknowledgement, and armWrites for connection-targeted writes (Live CLI and MOPs)
test-bed swaps and the switch restore tools with apply: true — preview by default
venue copy, element copy, and backup restore — reviewable plans run through mop_replay
Data Studio writes
the web console’s AI chat, where Write Guard is switched off — pin that chat to a read-only connection unless you intend a write

Reading a preview

Before you say yes, check three things:

The tenant — is this the connection you meant?
The operation — the method and path, not just Claude’s summary of it.
The body — the preview lists the body’s field names, not their values. For anything that replaces rather than patches, ask Claude to show the exact body it will send before you say yes.

When you don’t need it

A read-only R1 API client can’t write regardless, so Write Guard adds only friction there. The stronger control is always the credential’s own permissions in RUCKUS One — Write Guard is a second layer, not a substitute for issuing the right API client.

Security model — credentials, tokens, and what Claude can see
Multiple connections — why the preview names a tenant