Dora NodaOn September 15, 2026, a backup vendor did the thing every platform team has been nervous about: Rubrik announced an MCP server that gives customer AI agents a programmable path into its Security Cloud — the same system that holds backup inventories, identity context, and recovery workflows. The agents on the other end aren't Rubrik's demos, either. They're yours: Claude, Copilot, and whatever custom agents your team already runs. And the controls Rubrik says wrap that access — RBAC parity with the human console, configurable per-tool permissions, guardrails aligned to the OWASP MCP Top 10 — read less like a feature list and more like a template for how any infrastructure MCP server should treat state-changing tools. This post turns that template into a five-rule checklist you can apply to your own deploy, rollback, and failover tools, starting with the blast-radius table that motivates every rule.
The announcement in 30 seconds
Rubrik MCP, announced September 15, 2026 from Palo Alto and co-engineered with Anthropic's teams, exposes the Rubrik Security Cloud API schema directly to an organization's AI agents. Connected agents get governed access to Rubrik's data, identity, and application intelligence, and teams can save multi-step recovery or compliance workflows for reuse across AI clients. The framing is "agentic cyber resilience": a multi-step reasoning agent, powered by Claude, engineered for critical incident response at machine speed rather than ticket-queue speed.
Two numbers set the context. Rubrik AI — the product line MCP now extends — is already used by one-third of Rubrik's global customers, so this is distribution into an installed base, not a cold launch. And Futurum's analysis of the launch notes that 55.3% of data-security decision makers are already conducting vendor security assessments of AI platforms, which explains why the announcement leads with governance instead of capability. Availability matters too: private preview for existing customers now, with general availability targeted for October 2026. Everything below about the control set should be read with that preview status in mind — more on that in the stated-vs-verified box below.
The same day brought a sibling launch worth one paragraph: Rubrik Code Guardian, a harness built on Anthropic's Claude Mythos 5 that red-teams code and validates multi-step vulnerability chains against an air-gapped copy of the customer's repository, pushing confirmed criticals into Jira or GitHub Issues with recovery workflows to restore a known-good codebase. Code Guardian is in private preview with select design partners. Its architectural lesson — do the dangerous analysis against an isolated copy, never the live system — is the same blast-radius instinct the MCP server applies to recovery state, and it resurfaces in rule 3 of the checklist.
Why backup state is the hardest agent-access problem
A deploy tool's MCP surface and a backup vendor's MCP surface look similar until you sort their tools by blast radius. Reads are forgiving: a mistaken query returns wrong data, and the agent retries. State-changing operations on recovery infrastructure are not forgiving. A restore that targets the wrong snapshot overwrites production data with last month's version. A retention-policy change that an agent "helpfully" applies can age out the only clean copy standing between you and a ransomware note. Failover moves real traffic. These aren't hypothetical failure modes; they're the ordinary semantics of the underlying APIs, now invocable by a model that cannot be paged.
That asymmetry is why the table below is the post's core artifact. It sorts a recovery platform's agent tools the way the platform's own threat model must: by what happens when the call is wrong.
| Tool class | Example tools | If the agent gets it wrong | Governance it demands |
|---|---|---|---|
| Read-only inspection | List snapshots, query backup telemetry, check job status | Wrong answer, wasted turn | Scoped read access, redaction of sensitive fields |
| Planning / dry-run | Preview restore plan, simulate failover, estimate recovery time | Misleading plan acted on later | Clearly labeled non-executing tools, plan output reviewed before execution |
| Scoped state change | Restore one file, restart one job, quarantine one host | One object wrong, bounded damage | Per-tool permission grants, target scoping, confirmation for production targets |
| Fleet-wide state change | Full-site restore, retention-policy change, mass failover | The resume-generating kind | Multi-step approval, break-glass audit trail, reversible-by-default design |
The uncomfortable row is the last one. A raw API passthrough — the naive MCP server that maps one endpoint to one tool with an admin token — hands an agent all four rows with identical friction. The governed alternative makes friction proportional to blast radius: reads flow freely, scoped writes carry confirmations, and fleet-wide mutations route through approvals and immutable audit logs. That proportionality principle is the entire design lesson of this launch, and it transfers directly to any platform whose agents can roll back a deploy, drain a node, or flip traffic.
What Rubrik actually wrapped around the tools
Per the announcement coverage, Rubrik MCP's control set has four named elements, each mapping to a row in the table above:
- RBAC parity. Agents operate under the same role-based access controls as the human console, so "what can the agent touch" is answered by the identity system teams already audit — not by a parallel permission model invented for the MCP layer. This kills the most common MCP anti-pattern: a server-side service account with broader access than any human who would approve the action.
- Configurable permissions. Beyond inherited roles, teams can configure which capabilities each agent connection may invoke — the per-tool grants that let an incident-triage agent read telemetry while only the recovery-runbook agent may trigger restores.
- OWASP MCP Top 10-aligned guardrails. Rubrik states its guardrails align to the OWASP MCP Top 10, the community catalog of MCP-specific risks (prompt injection via tool output, excessive tool permissions, unvalidated input at the server boundary, missing audit trails). Alignment here means the threat model is borrowed from a shared, reviewable list rather than asserted ad hoc.
- Saved reusable workflows. Multi-step recovery and compliance workflows can be saved and reused across AI clients, which moves dangerous sequences out of free-form agent planning and into reviewed, versioned runbooks — the agent invokes the workflow rather than improvising twelve API calls at 3 a.m.
Stated vs. verified. Rubrik MCP is in private preview until its targeted October 2026 GA, so each control above is vendor-stated, not independently verified. Honest scorecard: RBAC parity is stated — GA evidence would be documentation showing agent calls evaluated against the same policy engine as console sessions, plus a customer-visible audit log entry per call. OWASP Top 10 alignment is stated — verifiable when Rubrik publishes which Top 10 items map to which enforced control, or when a third-party assessment says so. Saved workflows are stated — confirmed when preview customers describe the review/versioning flow in public. Treat the checklist in the next section as derived from the design, which is sound whether or not any single control survives GA contact with customers.
One more pattern worth naming comes from Code Guardian rather than the MCP server: the air-gapped copy. Running frontier-model analysis against an isolated replica of the repository instead of the live system is blast-radius reduction by architecture — the dangerous operation cannot touch production because production isn't in the room. Any infrastructure MCP server can steal this shape: dry-run restores against a cloned namespace, failover simulations against mirrored traffic, policy changes previewed against a copied policy engine. Isolation beats permissioning when both are available.
The 5-rule checklist for your own infrastructure MCP server
Whether your agents deploy apps, roll back releases, or drain nodes, the same five rules fall out of the Rubrik design. Each is stated as a check you can run against your own tool surface this week.
Rule 1: Split reads from writes at the tool boundary, not in documentation. Separate tool names, separate permission grants, and ideally separate MCP servers or endpoints for inspection versus mutation. An agent that only needs deploy status should never receive a tool list containing the rollback trigger. Rubrik's read-mostly telemetry path versus its gated recovery actions is this split made product.
Rule 2: Inherit the human permission model; never mint a parallel one. Agent calls should evaluate against the same RBAC policy as console and API users, with the agent's identity visible in every decision. If your platform has roles for "can view" versus "can deploy to production," the MCP server enforces those roles — it doesn't bypass them with a shared service token. This is RBAC parity, and it's the single highest-leverage control on this list.
Rule 3: Gate by blast radius, and prefer isolation over permissioning. Single-object mutations get target scoping and confirmation prompts; fleet-wide mutations get multi-step approval and reversible-by-default semantics (blue-green restores, restorable retention changes). Where you can run the dangerous operation against a copy first — Code Guardian's air-gapped pattern — do that instead of merely asking "are you sure."
Rule 4: Log every tool call as an auditable security event. Not application debug logs: an immutable record of who (which agent identity), what (tool + arguments), when, and under which policy decision. Agent operations at machine speed are unreviewable in real time, which makes the after-the-fact trail the actual control. If you can't reconstruct an incident's agent turns from logs alone, the server isn't governed yet.
Rule 5: Promote repeated multi-step sequences into reviewed workflows. When agents keep improvising the same twelve-step recovery dance, capture it as a saved, versioned, human-reviewed workflow the agent invokes by name. Free-form planning is where 3 a.m. creativity meets production state; runbooks are where that creativity gets reviewed at 3 p.m. instead.
Run the checklist against the naive alternative — one server, one admin token, every endpoint a tool — and the gap is the work. Most teams will find rules 1 and 4 are an afternoon's effort with outsized payoff, while rules 2 and 5 are the architectural commitments that pay off across every agent you onboard next year.
What this signals for agent-operated infrastructure
Step back from the feature list and the launch reads as a market signal with three components. First, the buyer has arrived: when one-third of a backup vendor's customers already run its AI product and a majority of data-security decision makers are formally assessing AI platforms, "agents touching production state" is no longer an experiment to be contained but a deployment to be governed. Second, the governance bar is being set by vendors who cannot afford to get it wrong — a backup company's entire value proposition is that your worst day goes well, so its agent-access design inherits worst-day rigor by necessity. Third, the co-engineering pattern matters: Rubrik built this with Anthropic's teams rather than bolting a protocol adapter onto an existing API, which suggests the model provider and the infrastructure vendor both consider the tool/governance boundary a first-class design surface, not integration glue.
For self-hosted platforms the implication is direct. Your agents will want the same path into deploy state, node lifecycle, and traffic configuration that Rubrik's customers now have into recovery state — rollback is restore by another name, and failover is failover wherever it runs. The question is whether that path arrives as raw API passthrough with an admin token or as a governed surface with RBAC parity, blast-radius gating, audit trails, and reviewed workflows. Rubrik just showed what the second option looks like from a vendor whose customers measure trust in recovered data. Steal the shape early; retrofitting governance onto a fleet of agents that already expect root is the harder project.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.
