On August 3, Varonis announced a product feature with a boring name and an interesting premise. They call it Agent Intent-Based Access Control. The pitch, in their own words: “The question is no longer ‘Can a user access this data?’ but ‘In this context, should this agent be allowed to take action on this data?’”
Read the two halves of that sentence again. The first is the question access control has answered for forty years. The second is a different question, and I do not think most audit functions have noticed that it changed.
Let me be clear about what is fact and what is my read.
Fact: Varonis, a data security vendor, released a capability that watches an agent’s reasoning, tool calls, and data access, compares them to the instruction the agent was given, and blocks or flags the actions that drift from it. It has a quarantine function that shuts down an identity after a violation, and it keeps a log of every prompt, response, and tool execution. The announcement was timed to Black Hat, which tells you it is a marketing moment as much as a technical one. The product is one company’s answer, and I have not tested it.
My read: the specific product matters less than the problem it exists to solve. Somebody built this because role-based access control ran out of room.
Four days before that announcement, Okta signed a definitive agreement to acquire Permiso Security, a platform built to detect threats across human, non-human, and agentic identities, for a price reported at just under $200 million. When one of the biggest names in identity management buys that capability rather than builds it, the gap the vendors are pointing at is not theoretical.
Why the old model held for so long
Access control has always been a question about a subject. Who are you, and what are you allowed to touch. We built decades of audit practice on top of that assumption, and it was a good assumption, because the subject sat still.
A person has one job, one set of entitlements, and a manager who recertifies them. A service account does one thing. You can snapshot the entitlements, compare them to a role, flag the exceptions, and call it an access review. The IIA’s Global Internal Audit Standards ask us to evaluate whether controls address the risks to the organization’s objectives, and for access, the risk was stable enough that a point-in-time review addressed it well.
The subject sitting still is the load-bearing assumption. An agent does not sit still.
One identity, a hundred jobs
Give an agent broad access, which is the only way to make it useful, and that single identity now does whatever the last instruction told it to do. It reads the general ledger for a reconciliation in the morning and, if someone phrases a prompt cleverly enough, exports the same ledger somewhere it should never go in the afternoon. Same identity. Same entitlements. The access review would pass both times, because the entitlements never changed. What changed was the intent, and intent is exactly what the entitlement snapshot cannot see.
This is not hypothetical drift. A 1Password survey of 1,000 security and engineering professionals at US firms with at least 250 employees, fielded between May 26 and June 3 this year, found 27% reported a breach or security incident from overprivileged identities, rising to 33% among the developers who actually use AI agents. It is a vendor survey, so weight it accordingly. A separate Akeyless release put it more bluntly: two-thirds of enterprises suspect their agents have already reached data nobody approved.
I have written before about the version of this that shows up in your logs, when an agent clicks through your ERP inside a human’s session and the audit trail records the person, not the machine. Intent-based control is the same problem seen from the other side. The log question was “who did this.” The access question is “should this thing have been allowed to, given what it was trying to do.”
What this does to the access review
Here is the part that warrants examination in your own function.
If your access review is a periodic recertification of entitlements, it was designed for a population of subjects that hold still. The moment agents enter that population, the review is testing the wrong attribute. It confirms the agent is allowed to reach the data. It says nothing about whether the thousand things the agent did with that access were consistent with its purpose. You can have a clean access review and a rogue agent at the same time, and the two facts will not contradict each other on paper.
That is not a finding. It is a scoping observation, and a specific one: I would test whether the access model applied to non-human identities evaluates action-in-context, or whether it still assumes a static entitlement is sufficient evidence of control. If it is the latter, the gap is not a misconfiguration. It is a control designed for the wrong kind of subject.
The new control needs auditing too
Suppose your organization does adopt something like intent-based control. Good. Now audit it, because it is a control built out of model judgment, and model judgment has settings.
Varonis exposes lenient, balanced, and strict sensitivity levels, and lets customers write session policies in plain language. That is a configurable control with a dial on it, and every dial is a governance question. Who chose the sensitivity for the agents that touch regulated data. Is “strict” actually enabled where it matters, or did someone quietly loosen it because the false positives were annoying the developers. When the system quarantines an identity, who can lift it, and is the human approving flagged actions reading the reasoning or rubber-stamping the queue.
None of those are new audit questions. They are the same configuration, override, and monitoring questions we ask of any detective control. What is new is that the criterion the control enforces is “consistency with stated purpose,” evaluated continuously and probabilistically, rather than “matches an entitlement,” evaluated once. Your testing has to follow the criterion. Sampling a point in time does not test a control that operates across a whole session.
Where I would start
You do not need to buy anything to begin. You need to know whether your current access model can even see the problem.
Ask your identity team one question: for our AI agents, does anything evaluate whether an action is consistent with the agent’s purpose, or do we only check whether the identity is permitted. If the answer is only the second, you have a scope for next cycle.
Then pull one agent that touches sensitive data and trace a week of what it actually did against what it was told to do. Not its entitlements. Its actions. If nobody can reconstruct that from the logs, that absence is itself worth reporting, because the drift the vendors are selling against would be invisible to you if it happened.
And keep the vendor framing at arm’s length. The idea underneath, that authorization has to become continuous and context-aware once the subject stops holding still, is sound and probably permanent. The specific product making that case this week is doing so from a Black Hat booth. Both things are true. Our job is to take the durable half and leave the marketing.
The uncomfortable part is that this is not a future problem to schedule. If your organization is running agents against real data, the population your access review was built for already changed underneath it. The review just has not told you yet.