Photo by Taylor Vick on Unsplash
What's on the Table
A retrieval agent runs at 3:14 a.m. It has a valid service token, a legitimate reason to query the finance data warehouse, and no human in the loop. It pulls 400,000 rows, summarizes them, and posts the summary into a Slack channel that contains two contractors. Every single step passed authentication. Nothing was breached. And yet something clearly went wrong.
That gap — between "authenticated" and "authorized to do this specific thing, right now" — is the market Rubrik Inc. just walked into. According to Google News coverage of the announcement, originally reported by SiliconANGLE, Rubrik has introduced Agent Identity, a security product built to govern AI agents at the level of the individual tool call rather than at the level of the session or the service account.
The thesis of this post: tool-call-level governance is the correct architectural unit for agent security, but the vendors selling it are quietly asking enterprises to accept a latency and cost tax that almost nobody has budgeted for.
The Pattern: Identity Was Built for Sessions, Agents Run in Loops
Start with the pattern, because the product only makes sense once you see the shape of the problem.
A traditional application does something like this: a human authenticates once, receives a token, and that token scopes what the app can touch for the next eight hours. Identity and access management was designed around that shape — a long-lived principal, a bounded set of permissions, an audit log of logins.
An agent running a ReAct-style loop (reason, act, observe, repeat) does not have that shape at all. It reasons about a goal, picks a tool, calls it, reads the result, and then — critically — decides what to do next based on data it just ingested. The tenth tool call in a loop may bear no resemblance to the first, and the reasoning that produced it was influenced by content the agent read at step seven. A session token issued at step zero has no opinion about any of that.
This is why Rubrik's framing matters more than the product announcement itself. Per the reporting, Agent Identity governs each tool invocation, applying policy to what an agent can call, when, and under what conditions. That is a deliberate rejection of session-scoped identity as the control unit. As one line of expert argument summarized in the research puts it, AI agents constitute a new attack surface that conventional tooling was never designed for, and the shift from human-driven to agent-driven workflows demands fundamentally different security and compliance frameworks.
The non-obvious part: this is not really an identity problem. It is a control-flow problem wearing an identity costume. The dangerous property of an agent is not that you don't know who it is — you do, it has a service account. The dangerous property is that its next action is a function of untrusted input. Which means the useful policy question is never "is this agent allowed to call the database?" It is "is this agent allowed to call the database with this argument, in this step of this plan, after having read that document?"
Most products marketed as agent governance answer the first question and let you believe they answered the third.
Implementation: What Per-Call Governance Actually Costs
Here is the number nobody puts on the slide.
If governance happens at the tool call, then every tool call incurs a policy check. Consider what that means arithmetically. A modestly complex agent task — research a customer, cross-reference two systems, draft a response — runs somewhere in the range of 10 to 20 tool calls. Under session-level identity, that task triggers exactly one authorization decision. Under call-level governance, it triggers 10 to 20. That is a 10x to 20x increase in policy-evaluation volume for the same unit of business work, and it is a direct consequence of choosing the finer-grained control unit. You do not get the security benefit without the multiplier.
Whether that multiplier hurts depends entirely on where the policy engine sits. An in-process check against a cached policy bundle costs single-digit milliseconds and effectively disappears. A network round trip to a centralized decision point at, say, 40ms adds 400 to 800ms to a task that already takes several seconds — annoying but survivable for a batch workflow, and genuinely disqualifying for anything a human is waiting on. A policy check that itself calls a model to evaluate intent is a different animal entirely: now you have added an LLM call per tool call, and your agent's token spend roughly doubles while its latency budget evaporates.
Chart: Authorization decisions triggered per agent task. Session-scoped identity evaluates once; tool-call-level governance evaluates once per invocation. Illustrative, based on typical 10–20 call agent workflows — not vendor-published figures.
The comparison worth drawing is between the three governance layers enterprises are actually being sold in parallel, because they are not substitutes. Cloud-native agent controls — the frameworks AWS, Azure, and Google Cloud rolled out across 2024 and 2025 — govern agents inside their own platform, which is excellent until your agent needs to touch an on-prem file share. Model-provider safety tooling from OpenAI, Anthropic, and others governs the agent's reasoning and outputs, which catches a different failure class entirely and knows nothing about your data classification. A data-security vendor like Rubrik enters from the third direction: it already knows what is in the backup, which files are sensitive, and what "normal" looks like in your estate.
Who wins under which condition? If your agents live entirely inside one hyperscaler and touch only that hyperscaler's data, the native controls are cheaper and you should not buy a fourth product. If your agents are reading unstructured enterprise data across systems — the messy, cross-boundary case — the data-classification context is the thing the cloud-native and model-provider layers structurally cannot supply. That is Rubrik's actual argument, and it is a reasonable one.
The skeptic's pushback, which deserves a straight answer: isn't this just a backup company bolting "AI" onto its roadmap? Partly, yes — Rubrik went public in April 2024 at a valuation of roughly $5.6 billion, and every security vendor at that scale has an incentive to plant a flag in the agentic category. But the counter is structural. Policy without data context degrades into allow-lists, and allow-lists are exactly what an agent with a legitimate token walks straight through. Knowing that a document is sensitive is the input a policy engine needs, and that knowledge lives in the data layer, not the identity layer.
Where This Breaks in Production
Three failure modes, in the order teams tend to hit them.
The policy engine becomes the bottleneck, then gets bypassed. This is the oldest story in enterprise security. Governance adds latency; latency makes the demo feel slow; someone adds a fast path "just for the internal agents." Six months later the fast path handles most of the traffic. The tell to watch for during evaluation is whether the vendor can articulate a cached or in-process enforcement mode, or whether every decision requires a network hop.
Policy authoring does not scale to agent behavior. Writing rules for ten agents is tractable. Writing rules for two hundred, each with a drifting tool inventory as developers add MCP servers, is not. Enterprises will start with hand-written policies and discover within a quarter that the policies are stale. The realistic path is behavioral baselining — learn what an agent normally does, alert on deviation — which is a detection posture, not a prevention posture, and teams should be honest with themselves about which one they are actually buying.
The audit trail explodes. Twenty authorization events per task, times thousands of tasks per day, is a logging volume nobody sized for. This is the same governance-gap dynamic surfaced in the IBM breach data that Cybersecurity's analysis of AI access controls examined — the controls exist on paper long before anyone can afford to read the logs they generate.
And a fourth, quieter one: tool-call governance stops an agent from calling a tool it shouldn't. It does not stop an agent from calling a tool it should — with an argument it constructed after reading a poisoned document. Prompt injection routed through a fully authorized tool call remains outside the blast radius of any of this.
Bottom Line: Who Should Move Now
Our read: tool-call-level governance is directionally correct and will become table stakes, but the category is early enough that most organizations are better served spending the next two quarters on inventory than on procurement. As of August 5, 2026, tool call governance is a genuinely new product category — analyst firms including Gartner have only recently begun publishing agent security frameworks, and enterprise agent adoption is still projected to grow through the 2026–2027 window rather than having already peaked. Buying a control plane before you can enumerate what it must control is how shelfware happens.
Move now if agents in your environment already touch regulated or customer data across system boundaries and you cannot currently answer, from a log, which agent read which record last Tuesday. That inability is the real trigger, not the vendor announcement.
Wait if your agent deployments are single-platform, read-only, or still in pilot. Native cloud controls plus disciplined scoping will get you further, for less, until the fleet grows past what a spreadsheet can track.
Either way, the useful work is the same and starts this week: enumerate every agent, every tool it can reach, and every credential it holds. That inventory is the prerequisite for any governance product on the market — and building it will tell you, faster than any vendor demo, whether you have a problem worth $5.6 billion companies solving.
Frequently Asked Questions
What does tool-call-level AI agent governance actually mean?
It means the security decision is made at each individual tool invocation an agent performs, rather than once at the start of a session. Instead of granting an agent broad access for the duration of its run, the system evaluates policy every time the agent tries to call a database, an API, or a file system — checking what it is calling, when, and under what conditions.
Why can't existing identity and access management tools handle AI agents?
Traditional IAM assumes a long-lived principal with a stable set of permissions, typically a human logging in. An agent's next action is generated dynamically based on content it just read, so a token issued at the start of a session carries no information about whether the agent's tenth action is appropriate. The research framing on this is direct: agents are a new attack surface that conventional tooling was not designed to handle.
How much latency does per-tool-call authorization add to an agent workflow?
It depends entirely on where the policy engine runs. An in-process check against cached policy is typically negligible. A network round trip to a centralized decision point multiplies across every call in the workflow — a 10-to-20-call task incurs 10 to 20 checks instead of one. Any evaluation should test enforcement latency under realistic call volume, not on a single-call demo.
Does agent governance stop prompt injection attacks?
Not directly. Tool-call governance restricts which tools an agent may invoke and under what conditions. If an agent is legitimately authorized to call a tool but constructs a harmful argument after ingesting poisoned input, the call can still pass policy. Injection defense is a separate control layer, typically handled at the model-provider or input-sanitization level.
Disclaimer: This article is editorial commentary based on publicly reported information and does not constitute financial, security, or purchasing advice. No independent product testing was conducted. Research based on publicly available sources current as of August 5, 2026.