Agent IBAC: When Your AI Agent Decides the Weather Report Includes a Database Migration
There's a specific kind of chaos that only happens when an AI agent is left unsupervised: it doesn't just get the wrong answer, it does something entirely different from what you asked for, and you only notice when your production database shrinks by two-thirds. That's the story Varonis is trying to solve with Agent Intent-Based Access Control, or IBAC, announced today as part of their Atlas platform.
Here's the mechanic that actually matters. Agent IBAC sits inline between the agent and the model it's calling. Every prompt, response, and tool call flows through it before reaching its destination. An LLM evaluator, the same engine behind Varonis's other Atlas guardrails, reads the agent's loop, the reasoning the agent produces, the tools it selects, and the parameters it passes to them. Then it asks one question: do these steps align with the original request? If you asked an agent to check the weather and it invokes a database migration tool, IBAC can catch that and either block it, log it, or flag it for human review. You get three sensitivity levels, lenient, balanced, and strict, so a dev agent can improvise while a finance agent stays on a leash.
What's interesting about this approach is the emphasis on drift rather than binary violations. Agents don't usually go rogue in one dramatic leap; they accumulate small deviations across a session. Ask for a customer summary, and the agent starts pulling records for every account in the region. One action doesn't look alarming. Across ten turns, it's an exfiltration. IBAC evaluates the entire session, tracks conversation IDs, and can even detect multi-turn jailbreaks where each prompt looks benign individually but together they assemble a path to data the agent wasn't meant to touch. When it decides enough has drifted, it can quarantine the identity behind the session, blocking everything for a configurable window from minutes to a full day.

The thing that strikes me is how this reframes the access control problem. Role-based access control was designed for humans who need to reach into specific data stores. Agents need broad access to be useful, which makes them risky precisely because they're capable. The question shifts from "can this entity access this data" to "in this context, should this agent be allowed to take action on this data?" It's a subtle distinction, but it changes the entire security model from static permissions to runtime evaluation. Whether it's good enough to replace the shotgun approach of giving agents everything and hoping remains to be seen, but at least now there's something between blind trust and locking agents out of everything. So when your agent starts being a little too helpful, who's going to pull the leash first: the tool vendor or the security team?
Comments
Post a Comment