The Agent Does Not Get the Permission Until It Tries to Act.

Rubrik picked Black Hat USA, on 4 August 2026, to introduce Agent Identity. Moona Intelligence is verifying it three weeks later, against Rubrik's own documented mechanism rather than against how the announcement was covered at the time. The date that matters for what follows is 4 August, when Rubrik says the mechanism was introduced. Nothing here describes it as new today.

What Rubrik says Agent Identity actually is

Rubrik's own material frames Agent Identity as one of four pillars inside Rubrik Agent Cloud, the agent governance platform Rubrik has been building out since late 2025: Agent Observability, described as monitoring every agent and every Model Context Protocol connection at runtime; Agent Identity, described as controlling access per tool call; Agent Runtime Security, described as SAGE driven, intent based policy enforcement and error detection; and Agent Rewind, described as undoing an agent's mistakes after they happen. This record is about Agent Identity specifically, and deliberately does not treat the other three pillars as part of the same canonical claim, because each answers a different question.

The claim Rubrik makes for Agent Identity is specific enough to check. Rather than an agent holding a standing set of permissions it can exercise whenever it likes, Rubrik describes every supported MCP tool call as passing through a fixed sequence of checks before it is allowed to run at all, and only receiving credentials scoped to that one call once those checks pass.

Three checkpoints, and which one actually decides

Rubrik's own technical material names the sequence directly, and the order is the part worth reading carefully, because it is not the order marketing language would suggest. Behavior is first. SAGE, which Rubrik brands as its Semantic AI Governance Engine, is described as a small language model that reads the intent behind a proposed call, along with its parameters and values, against policy, rather than matching against a static list of blocked keywords or tool names. Access is second. Rubrik's MCP Gateway is the component that actually decides whether the call is allowed, at the infrastructure layer, and Rubrik describes that decision as enriched with the intent and risk context SAGE already produced, not replaced by it. Identity is third, and it runs only once Access has already said yes: the agent's session is authenticated, and a token scoped to that specific tool call is minted.

What this sequence describes, on Rubrik's own account, is closer to the third of three distinct things worth telling apart: a short lived identity credential, which only proves who is asking; a short lived delegated credential, which proves who is asking and on whose behalf; and authorization scoped to one specific, already proposed action. Rubrik's documented design is the third kind. The token Rubrik describes is not minted when a session starts and then reused for whatever the agent decides to do next. It is minted after a specific call is already known, already evaluated for intent, and already cleared by policy, scoped to that call and, on Rubrik's account, to nothing else.

The worked example, read as what it is

Rubrik illustrates the mechanism with a worked example: an agent calling listAccounts, then getTransactions, each receiving its own freshly scoped, short lived token. The same agent then attempts updateAccount, a write operation, and Rubrik states this is denied because no applicable policy grants that scope. The call does not execute. Rubrik states the denial is logged against the specific human and the specific agent involved.

Treat this precisely as what it is. It is a vendor documented product example, illustrating how the mechanism is designed to behave. It is not independent evidence of a customer's production deployment behaving this way, and Moona Intelligence has not observed a running Rubrik Agent Cloud deployment to confirm the sequence holds outside Rubrik's own account of it. What is genuinely useful about the example is not that it proves adoption. It is that Rubrik chose to illustrate the mechanism with a denial as well as two allows, which is the more informative half of any access control claim to demonstrate.

Federation, on behalf of a person, and what is not documented

Rubrik describes Agent Identity as federating with Okta and Microsoft Entra ID, extending an organization's existing enterprise identity system to autonomous agent actions rather than requiring a separate directory. The stated effect is that an agent acts on behalf of a specific human, with access policy incorporating that person's user and group context, rather than acting under a shared service account or an API key embedded in the agent's configuration.

That is a meaningful design choice, and it is worth being precise about what Rubrik's available material does and does not specify beneath it. AWS documents its own comparable pattern, an on behalf of token exchange inside Amazon Bedrock AgentCore, down to the exact OAuth 2.0 mechanism, RFC 8693 token exchange, and the specific grant types available alongside it. Rubrik's own material, as available to this session, describes the federation and the on behalf of relationship in outcome terms rather than in that level of protocol detail. Moona Intelligence is not asserting a specific token exchange standard or a specific identity intersection algorithm on Rubrik's behalf, because Rubrik's own documentation does not state one. The same caution applies to three further questions Rubrik's material does not resolve as precisely as the mechanism's headline claim: whether a minted, scoped token can be reused for more than the one call it was issued against, whether the audit trail Rubrik describes as retaining both human and agent context is cryptographically signed or simply logged, and whether the three checkpoint sequence described here governs every surface Agent Identity supports or specifically the MCP tool call surface Rubrik's own technical material frames it around. Rubrik's language, read closely, is scoped to MCP tool calls specifically. This record does not extend that claim further than Rubrik's own material supports.

What Rubrik is not yet claiming

Rubrik's own newsroom material carries standard forward looking statement language common to vendor press releases, stating that unreleased services or features referenced are not currently available and may never become generally available. That boilerplate appears on vendor announcements regardless of what has or has not shipped, and its presence alone does not establish that Agent Identity is unavailable. What does narrow the claim is more specific: independent trade coverage of the announcement noted that Rubrik did not disclose a general availability date or pricing for Agent Identity as its own line item, distinct from its description as available within Rubrik Agent Cloud. Moona Intelligence reads Agent Identity as an announced, documented capability positioned inside a product Rubrik already sells, and stops short of treating it as a confirmed, universally shipped feature with its own independent availability date, because Rubrik's own material does not supply one.

Kept separate on purpose: Agent Rewind

Rubrik shipped Agent Rewind roughly a year before Agent Identity, introduced on 12 August 2025 following Rubrik's acquisition of Predibase, as a mechanism to trace, isolate and undo a destructive action an agent has already taken. It is a real and separate product, and it answers a different question from the one this record is about. Agent Identity, on Rubrik's own account, determines whether an action executes at all. Agent Rewind determines what happens to the environment after an action, authorized or not, has already run. Keeping those two questions apart matters because conflating them would credit Agent Identity's authorization claim with a recovery capability it does not itself provide, and credit Agent Rewind with a prevention capability it was never built to offer.

Where this sits against what else has been verified

GitLab's composite identity answers a related but different question: it authorizes the intersection of a standing human role and a standing service account role, decided once access is checked, not a token minted fresh for one specific proposed call. AWS's AgentCore architecture documents an on behalf of token exchange that is scoped to a user and a session, with a separate, named control that pauses a consequential write for a human to approve, rather than an automated policy layer minting a fresh token for each individual call the way Rubrik describes. TrueFoundry's MCP Gateway holds a matched call at a shared boundary for a human to approve or deny, with validity windows a policy configures, which is a human gated design rather than an automated intent and policy pipeline deciding without a person in that specific loop. Rubrik's distinct contribution, on its own documented account, is narrower and more specific than any of those three: a token scoped to one tool call, minted only after that exact call has already been evaluated for intent and cleared by infrastructure policy, with no standing grant sitting in the agent's session in between calls.

The sharper version of the question this raises is not whether an agent and a human have a relationship, every one of these systems assumes that they do. It is whether the agent needs to hold, in advance, every permission it might eventually use while it is still reasoning about what to do next, or whether authority can wait until the system knows the one specific thing the agent is actually trying to do. Rubrik's own documented design answers that question by withholding the credential until the action is already known. Whether that holds up at the scale and under the adversarial pressure a live enterprise deployment applies is not something Rubrik's own material, or this record, can settle. What can be settled is what Rubrik documents, and it documents a narrower, more specific claim than a generic identity or approval feature: authority minted after the fact, not carried in advance.