For Rubrik · Agent Cloud · Agent Rewind · Rubrik Security Cloud

Before Rewind is ever needed:
every agent action independently judged first.

Three agent actions below are shaped exactly as they leave an agent in the estate Rubrik protects — a coding agent’s tool call under a PreToolUse hook, a Rubrik Security Cloud mutation through a governed proxy, an MCP tool call — and each one goes through the live Veridect system on this page. On your side the integration is one hook script, one proxy, or a URL change. Behind it is the whole control plane: consensus from frontier models across independent vendors, deterministic policy classes, risk routing, a hash-chained ledger, and an Ed25519-signed decision record you can verify right here. Rubrik finds, monitors and rewinds what agents did; Veridect decides, before they do it, whether it happens at all — and proves it offline.

Open the full live tour
3 seams
a pre-tool hook, a governed API proxy, or one MCP URL — your agents, policies and models stay exactly as they are
1 judgment
POST /pre-action — behind every path (the MCP gateway makes that call for you); the answer is a verdict plus a signed record
1 record each
every decision — pass, hold or refusal — is a signed record Monitor and Rewind can be pointed at afterwards, and an auditor can verify offline
0 trust required
every decision re-derives from its recorded inputs and verifies against a published key — try it below
Where it sits

Between the agent’s plan and the action — in front of the safety net.

Rubrik runs the safety net: Agent Cloud inventories agents and their identities, monitors their actions and governs them; Agent Rewind reverses the damage when an agent goes wrong; Rubrik Security Cloud protects and recovers the data underneath. Veridect adds the one moment those controls, in Rubrik’s own framing, sit around rather than inside: the instant before an action with consequences executes — a snapshot deleted, retention changed, records exported — when an independent judgment — not the model that proposed the action, not the platform that hosts or restores it — decides whether it goes, waits for a person, or never happens, and signs the record either way. Find-and-undo is theirs. Verdict-before, and the proof an auditor can check offline, is ours. The two compose: ours in front, theirs behind.

Your agent in the Rubrik estate

Proposes an action

  • Coding agents under Rubrik Agent Cloud for Claude Code — any tool call with a pre-execution hook
  • Automation and agents calling the Rubrik Security Cloud API: SLA assignment, retention, exports, recoveries
  • Any agent Agent Cloud watches that reaches tools over MCP
Veridect · live control plane

Judges it before it runs

  • Deterministic scope check against the agent’s configured authority
  • Policy classes in code — money thresholds, protected data, regulated data, cumulative exposure
  • Multi-vendor model consensus with calibrated confidence and a dissent register
  • Risk routing: greenlight, escalate to a named human queue, or block
  • Hash-chained, Ed25519-signed record — written whether it passes or not
Outcome

Three doors, one record

greenlightthe tool runs or the mutation is forwarded; the verdict and record id travel with it
escalateheld for a person in the queue the policy names — there is nothing yet to rewind
blocknever executes — and the refusal is on the ledger too
Three thin paths

The integration is thin. The system behind it is not.

Each path maps the call your agent was already making onto one judgment — POST /api/ai/consensus/pre-action, made by your hook, your proxy, or the MCP gateway on your behalf: the verb, the target object, the fields, which agent is asking, and what that agent is authorized to do. Nothing about the agent, the model, or the tool changes. The verdict decides whether the original action proceeds.

PATH 01 · CODING AGENTS · PRETOOLUSE HOOK

One hook, every tool call a coding agent makes

Claude Code runs PreToolUse hooks before any tool executes, and Rubrik Agent Cloud for Claude Code monitors and rewinds what the agent did. Put Veridect in the hook: it posts the tool call, and exit code 2 stops the tool with the verdict and the record id in the agent’s view — before there is anything to rewind. The same shape fits other coding agents with pre-execution hooks.

~20 lines · one hook script · no change to the agent or its model

Fail-closed by construction: the script exits 2 unless it parsed a greenlight — a non-200, a timeout or a malformed body all stop the tool. Scope the hook to the tools that matter (Bash, Write, Edit, MCP tools) with the matcher; reads never wait. MCP tool names lose their mcp__server__ prefix so the verb the engine sees is the tool’s own.

// .claude/settings.json — the hook fires before Bash, Write, Edit and any MCP tool
{ "hooks": { "PreToolUse": [ { "matcher": "Bash|Write|Edit|mcp__.*",
      "hooks": [ { "type": "command", "command": "veridect-pre-tool-use", "timeout": 60 } ] } ] } }

#!/usr/bin/env bash
# veridect-pre-tool-use — reads the tool call on stdin; exit 2 = the tool does not run
set -euo pipefail
IN=$(cat)
BODY=$(jq -cn --argjson in "$IN" --arg scope "$VERIDECT_AGENT_SCOPE" '{
  action: ($in.tool_name | sub("^mcp__[^_]+__"; "")),            # mcp__rubrik__rerun_backup_job → rerun_backup_job
  target: ("claude-code:" + ($in.cwd // "repo")),
  parameters: $in.tool_input,
  callingAgent: ("claude-code:" + $in.session_id),
  callingAgentScope: $scope,                                      # its configured authority, in words
  department: "engineering" }')
RES=$(curl -fsS --max-time 60 -H "Authorization: Bearer $VERIDECT_API_KEY" -H 'Content-Type: application/json' \
  -d "$BODY" https://<your-veridect-host>/api/ai/consensus/pre-action) || RES='{}'   # -f: any non-2xx is "unavailable", never a verdict
VERDICT=$(jq -r '.verdict // "unavailable"' <<<"$RES"); RECORD=$(jq -r '.auditBundleId // ""' <<<"$RES")
if [ "$VERDICT" != "greenlight" ]; then
  echo "Not executed — Veridect $VERDICT · record $RECORD" >&2   # the agent sees why; the refusal is on the ledger
  exit 2                                                 # closed until proven open
fi
PATH 02 · RUBRIK SECURITY CLOUD · GOVERNED API PROXY

Agents never hold the mutation token — one proxy does the writing

Automation and agents reach Rubrik Security Cloud through its GraphQL API. Give agents no service account that can mutate. The only way an agent deletes a snapshot, changes retention, exports or restores is a thin proxy that asks Veridect first and forwards the mutation only on a greenlight, with the verdict and the record id in its reply. Every agent, every tool, every agent you add next quarter is covered at the API layer; people and scheduled jobs never wait.

~40 lines · one proxy in front of mutations · humans untouched

Where the authority lives: the scope string is the agent’s configured authority, looked up by the identity your service verified on the call — never a request field; and the proxy sends only the mutations pinned in its own table. A read-only summarizer that proposes to delete snapshots is a categorical no-authority action — the deterministic layer blocks it before any model is asked to weigh in. Watch it below. The policy classes work over field names; send values only for the fields your policy needs.

# rsc_gate.py — the only path from an agent to a Rubrik Security Cloud mutation
import os, httpx
VERIDECT = "https://<your-veridect-host>/api/ai/consensus/pre-action"
RSC      = "https://<your-account>.my.rubrik.com/api/graphql"          # the agent never holds this token

MUTATIONS = {                                                           # the only operations this proxy will ever send — pinned here, never supplied by the caller
    "delete_snapshot":   "mutation DeleteSnapshot($snapshotFid: UUID!) { deleteSnapshot(input: {snapshotFid: $snapshotFid}) { success } }",
    "rerun_backup_job":  "mutation TakeOnDemandSnapshot($input: TakeOnDemandSnapshotInput!) { takeOnDemandSnapshot(input: $input) { success } }",
    "export_snapshot":   "mutation ExportSnapshot($input: ExportSnapshotInput!) { exportSnapshot(input: $input) { id } }",
}
AGENT_AUTHORITY = {                                                     # authority keyed by the agent's identity — your configuration, never a request field
    "spiffe://prod/agents/backup-operator": "may re-run backup jobs and adjust SLA assignments within the standard tier; may not delete snapshots or export data",
    "spiffe://prod/agents/report-summarizer": "read-only: may read job status, SLA compliance and event history; may not modify any Rubrik object",
}

def governed_mutation(caller_identity: str, action: str, variables: dict) -> dict:
    """caller_identity = the identity your service verified on the inbound call (mTLS / OIDC) — not a body field."""
    scope = AGENT_AUTHORITY.get(caller_identity); mutation = MUTATIONS.get(action)
    if scope is None or mutation is None:
        return {"executed": False, "verdict": "unknown_agent_or_action", "record_id": ""}   # never asked, never run
    verdict, record_id = "unavailable", ""                              # closed until proven open
    try:
        r = httpx.post(VERIDECT, timeout=60,
                       headers={"Authorization": f"Bearer {os.environ['VERIDECT_API_KEY']}"},
                       json={"action": action, "target": "rubrik:" + action.split("_", 1)[-1],
                             "parameters": variables, "callingAgent": caller_identity,
                             "callingAgentScope": scope,                     # its configured authority, in words
                             "department": "data_protection"})
        if r.status_code == 200:
            d = r.json(); verdict = d.get("verdict", "unavailable"); record_id = d.get("auditBundleId", "")
    except Exception:
        pass                                                            # network, timeout, parse: all stay closed
    if verdict != "greenlight":
        return {"executed": False, "verdict": verdict, "record_id": record_id}   # the mutation never leaves this process
    out = httpx.post(RSC, timeout=60,
                     headers={"Authorization": f"Bearer {os.environ['RSC_SERVICE_TOKEN']}"},
                     json={"query": mutation, "variables": variables})
    body = out.json() if out.status_code == 200 else {}
    ok = out.status_code == 200 and not body.get("errors")                      # GraphQL answers 200 with "errors": read them
    return {"executed": ok, "verdict": "greenlight", "record_id": record_id, "rsc": body}
PATH 03 · MCP

One MCP URL in front of the tool server

Agents that reach tools over MCP — coding agents, custom agents, the agents Agent Cloud watches — can be pointed at Veridect instead of the tool server. Register the real server as a Veridect upstream once, then change the URL. Every tools/call is judged in flight; tools/list, initialize and everything else pass straight through. A refused call is never forwarded.

0 lines of agent code · one registration, one URL

Identity on the wire: the agent’s identity, workflow id and business context ride in params._meta["veridect/…"] — unsigned, that is the caller’s own claim, and the decision record marks it as such; a tenant can require a signed Ed25519 identity envelope on every call, and an unsigned call is then refused inside the protocol. Both outcomes run live below.

# 1) once — register the real tool server as an upstream (admin call)
POST /api/ai/consensus/mcp/upstreams/{tenant}
{ "upstreamId": "rubrik-tools-prod", "url": "https://<your-tool-server>/mcp", "enabled": true }

# 2) the one change — the MCP server URL in the agent's configuration
before:  https://<your-tool-server>/mcp
after:   https://<your-veridect-host>/api/mcp/gateway/rubrik-tools-prod

# Claude Code — .mcp.json, unchanged except for the URL
{ "mcpServers": { "rubrik": { "type": "http",
    "url": "https://<your-veridect-host>/api/mcp/gateway/rubrik-tools-prod",
    "headers": { "Authorization": "Bearer <VERIDECT_API_KEY>",                # your Veridect tenant
                 "X-Upstream-Authorization": "Bearer <tool-server token>" } } } }  # forwarded to the tool server

# 3) what the agent sees on a greenlight: the upstream's own result, plus
#    result._meta["veridect/verdict"] and result._meta["veridect/bundleId"]
#    on escalate / block: a JSON-RPC error (-32003 / -32004) carrying the
#    verdict and the record id — and the tool server never receives the call.
Run it live

Four Rubrik-shaped actions, through the live system, now.

Each card sends the exact request the hook, the proxy, or the MCP connection would send, to the live Veridect system on a shared sandbox tenant. The verdicts are real multi-model decisions made while you wait; the records are written to the ledger and signed; the Verify button re-derives the verdict from the recorded inputs and checks the signature against the published key. Expected outcomes are stated in advance — the engine decides.

Ready. Each decision takes a few seconds while the model roster deliberates.
LIVE 01 · PATH 01 · PRETOOLUSE HOOK

Re-run a missed backup job

A coding agent on an operations task calls the rerun_backup_job tool of a Rubrik MCP server for ERP-PROD-03 after a missed snapshot window; the hook strips the mcp__rubrik__ prefix and posts the call. Its configured authority: “may read protection status and may re-run missed backup jobs within an SLA domain.”

Expected: greenlight — inside authority, no policy class fires, the roster agrees. The hook exits 0, the tool runs, and the record id is in the session transcript.

Waiting. Request shape: the hook’s JSON, built from the tool call on stdin.
LIVE 02 · PATH 02 · GOVERNED API PROXY

A read-only summarizer tries to delete snapshots

A recovery-report summarizer agent proposes delete_snapshots on FILESHARE-HR-01 — everything older than a week. Its configured authority: “read-only: may read anomaly, threat-hunt and recovery reports to draft summaries.”

Expected: block — a read-only agent proposing to delete snapshots is a categorical no-authority action; the deterministic scope check decides, the models are consulted for the record, and the proxy returns the verdict without sending the mutation.

Waiting. Request shape: the proxy’s JSON, mapped from the mutation’s variables.
LIVE 03 · PATH 02 · GOVERNED API PROXY

Export patient records from a clean snapshot for a legal hold

A legal-hold agent, inside its authority (“may read clean snapshots and may export records for legal hold to the retained e-discovery vendor”), calls export_records from a clean EHR-DB-PROD snapshot with patient_id, diagnosis and lab_result among the fields.

Expected: escalate — the deterministic regulated_health_data_access_transmission policy class fires on the field names alone — the values are never inspected — and routes the action to the queue the policy names. Authorized but consequential actions escalate to a person; they are never silently blocked and never silently allowed.

Waiting. Request shape: the proxy’s JSON, mapped from the mutation’s variables.
LIVE 04 · PATH 03 · MCP

The same tools/call, two tenants, two outcomes

A JSON-RPC tools/call for lookup_policy_limit goes through the live Veridect MCP gateway to a sample tool server that counts what it actually receives. First on the shared sandbox tenant; then on a tenant that requires a signed identity envelope, sent without one.

Expected: first call forwarded, the tool’s own hit counter goes up by one and the result carries _meta["veridect/bundleId"]; second call refused inside the protocol (-32004 identity_not_presented), counter unchanged, refusal on the ledger.

Waiting. Request shape: JSON-RPC 2.0, verbatim.

What on this page is live, and what is illustrative

Live: every verdict, confidence, dissent register, policy class, escalation route, ledger write, hash chain, Ed25519 signature, MCP forwarding decision and verification result above comes from the production Veridect system on a shared sandbox tenant — the same endpoints an integrator calls. The consensus roster is four frontier providers from independent vendors with a decisive-verdict early stop, so a decision on this surface typically records three; the models are named in each record’s dissent register. The protected-data classes are this sandbox tenant’s policy; in your tenant every threshold is yours.

Illustrative: the agent side. No Claude Code session, Rubrik Agent Cloud policy or Rubrik Security Cloud call executes from this page; each card sends the exact request the hook, the proxy or the MCP connection would send, so what you watch is the decision those integrations would receive. The MCP calls in Live 04 leave this browser as a standard MCP client; a coding agent’s MCP connection and Agent Cloud itself were not exercised here. The code above is written against the documented Claude Code hooks contract (PreToolUse stdin JSON, exit code 2) and the public Rubrik Security Cloud GraphQL endpoint; the tool-server URL is a placeholder for your own. The integration is demonstrated wiring, not a Rubrik-certified, listed or endorsed solution.

Verification proves that the enforcement decision re-derives from the recorded inputs and that the record is unmodified and signed by the published key. It does not re-run the models: the consensus summary is attested through the recorded dissent register and verifier-text hash, and disclosed as such in the proof itself.

Rubrik, Rubrik Security Cloud, Agent Cloud, Agent Rewind and other Rubrik marks are trademarks or registered trademarks of Rubrik, Inc. Claude and Claude Code are trademarks of Anthropic, PBC. Veridect is an independent company and is not affiliated with or endorsed by Rubrik or Anthropic.

Five questions, answered for a Rubrik team

The short version.

How does this help?

It lets agents into the actions that carry consequences in the estate you protect — retention, exports, restores, patient and employee records — because an independent judgment stands in front of each action and a signed record stands behind it. The model that proposes the action is never the one that approves it, and the damage Rewind would have reversed does not happen.

How do I integrate it?

One of the three paths above: a hook on the coding agent, a proxy in front of mutations, or one MCP URL. Your agents, policies and models stay as they are. The decision records sit beside Monitor’s view of what happened. It runs where you say, on your keys.

How long does it take?

The system is live today. A private sandbox on your own policy thresholds in a day once you say go; production typically about two weeks, with the pace set mostly on your side — security review, keys, access. Ours is ready on day one.

How does this make money?

Three levers, none of them invented here: revenue held back because agents could not be trusted with the consequential step; cost stopped on human review of actions a signed record now settles; losses not taken on the actions that should never have executed. Your own number comes out of the sandbox.

Why you and not a big well-known company?

Because the judgment has to be independent of the model and of the platform to be worth anything to an auditor — and because undo is not the same as never. Agent Cloud and Agent Rewind find what an agent did and put it back; Veridect decides, before the action, whether it happens, and signs a record an auditor can verify offline. The two compose: ours in front, theirs behind. Validated by an external red team on scope-violation semantics. Try to forge a record on the live tour; the engine refuses it.

Test-drive it yourself.

Run the four actions above, verify the records, then take the full live tour — identity envelopes, delegation chains, cross-agent exposure, the fleet layer, and the forgery the engine refuses. Seven minutes, open access.

Prefer to see it on your own scenarios? Paste one on the pre-action console — or write to lrussell@veridect.ai and a scoped production sandbox on your own thresholds and your own estate follows in a day.

The same control plane, built the same way for Snowflake, Microsoft, AWS, ServiceNow, CrowdStrike, Salesforce, Databricks, Okta and Google Cloud — one engine behind all ten pages, each run live. All ten platforms →