Security model

R1-MCP holds credentials to your RUCKUS One tenant, so how it handles them is a fair question to ask before you connect it.

Your R1 client secret

• Encrypted at rest with AES-256-GCM using a key derived via HKDF from a Worker secret. The stored value is ciphertext.
• Write-only in the dashboard — once saved, it is never displayed again, not even to you.
• Decrypted only at token-mint time, server-side, to obtain a RUCKUS bearer token.

What Claude can see

Claude writes the program that runs inside code_mode, but that program executes on Cloudflare, not in Claude. It calls call_r1, and R1-MCP attaches the bearer token server-side.

So Claude sees API responses. It does not see your client secret, and it does not see the RUCKUS bearer token.

list_connections returns id, label, tenant id, region, and the default flag — deliberately never secrets.

RUCKUS token lifecycle

Tokens are obtained with the OAuth2 client_credentials grant against your region’s token URL, and cached with a TTL set just under their real expiry. A 401 triggers exactly one refresh-and-retry before the error surfaces.

Caching is keyed per user and per connection, so tokens for different tenants are never interchangeable. See Multiple connections.

Two authentication flows, one identity

• Web dashboard — Google sign-in; the session cookie is stored as a hash, never in the clear.
• MCP connector — OAuth 2.1 with Dynamic Client Registration and PKCE. Claude registers as a client, your Google session authorizes it, and the issued access token is stored hashed and bound to your user id.

Both resolve to the same account. Every MCP request is authenticated per user before anything else happens; R1-MCP never holds a raw copy of a token it issued.

The connector’s access token also authenticates R1-MCP’s HTTP APIs for native clients and the r1-mcp companion extension (Console chat, floor maps, VLAN probe). It grants what your account can do, nothing more. Floor map pages the extension embeds use a separate launch token instead: read-only, one venue, valid for 15 minutes.

Your R1 permissions are the ceiling

R1-MCP can do exactly what your RUCKUS One API client is allowed to do — no more. If you want a read-only experience, the reliable way to get one is to issue a read-only API client in RUCKUS One, not to hope the model behaves. (A read-only client cannot open AP CLI sessions — RUCKUS One issues AP console tokens only to read-write clients.)

Write Guard is a useful second layer on top of that, not a replacement for it.

Configuration R1-MCP stores for you

Some features keep a copy of your RUCKUS One configuration server-side: venue snapshots, backups, and the captured switch running-configs behind test beds.

A venue’s configuration is not innocuous — it can carry DPSK passphrases and RADIUS shared secrets. So:

• Snapshots and backups are encrypted at rest, with the same envelope used for your client secret, and are decrypted server-side only to diff them while compiling a plan.
• Test-bed configs are not in that envelope. They are stored as full text in a private storage bucket, under a per-account key prefix, because a restore has to put back exactly what was captured.
• No tool returns a configuration wholesale. venue_snapshot_get, backup_list, and backup_get return metadata only — venue, label, captured domains, object counts, sizes. config_diff returns the changed lines of a test-bed config (at most 400), and any line that looks like a credential is replaced with <redacted: …> — for example <redacted: password>.
• One export exists, and it bypasses Claude. A test bed’s archive download carries each switch’s full config text. It is served only to your signed-in browser session and never passes through the model. Snapshots and backups have no export path.
• They are private to your account and bounded — see Limits and quotas. Snapshots age out after 30 days; backups are retained until you delete them.

Write-only secrets are a related case worth knowing: where R1 masks a value on read, R1-MCP never captured it in the first place. That is why a copy or restore asks you to supply it at run time rather than reproducing it.

What R1-MCP stores, and for how long

Everything R1-MCP keeps is tied to your account. This table lists what is stored, whether it is encrypted, and when it goes away.

What	Where	Encrypted	Kept
Your R1 client secret	Database	Yes (AES-GCM)	Until you delete the connection
RUCKUS API bearer token (minted from your secret)	Cache, keyed per connection	No	Until shortly before RUCKUS One expires it; dropped at once when you edit, disable or delete the connection
Device CLI login token (switch or AP console)	Cache, keyed per connection and device	No	At most 15 minutes, regardless of the token’s own lifetime
Venue snapshots	Private storage bucket	Yes	30 days
Venue backups	Private storage bucket	Yes	Until you delete them
Test-bed switch configs	Private storage bucket, per-account prefix	No	With the test bed — deleted after 365 days untouched
Floorplan images mirrored from RUCKUS One	Private storage bucket, per-account and per-connection prefix	No	Not aged out. The oldest are deleted once you pass 50 per connection
Floor-map client list (client MACs, hostnames, OS type, SSID, AP, signal)	Cache, per connection and venue	No	15 minutes
Webhook events and derived client data	Database	No	7 to 365 days depending on the event class — see Webhooks and analytics and Limits and quotas
VLAN probe run records	Database	No	30 days, longer while anything the run created is not yet confirmed deleted

Some things are never stored:

• The VLAN probe’s temporary WLAN passphrase. A random passphrase is generated for each run, used once when the WLAN is created, and never written anywhere.
• Write-only secrets R1 masks on read — see Your configurations above.

Code execution

The TypeScript Claude writes runs in a sandboxed V8 isolate on Cloudflare, with no filesystem and no network access beyond the r1 primitives R1-MCP provides: outbound fetch() and connect() are blocked by the Workers runtime. It cannot reach anything you haven’t given it a tool for.

Revoking access

• Disconnect all Claude connectors on the dashboard revokes every access and refresh token issued to your Claude clients — effective immediately; the next request fails the bearer check. Removing the connector in Claude stops Claude calling, but a token it already holds stays valid until it expires (access tokens last one day).
• Disable or delete a connection to cut off a specific tenant. Deleting removes the stored secret permanently, and deleting your last connection also disconnects every Claude connector. A disabled connection is not used anywhere — including by device_cli when it is your default and no connection is named, which is refused instead. See Multiple connections.
• Rotate the R1 client secret in RUCKUS One and update the connection. The old secret stops working wherever it was.

Notes and shared data

Endpoint notes you save with save_endpoint_note are private to your account. An administrator can promote a note to global visibility — so treat notes as API knowledge, not as a place for tenant-specific detail.