Beyond RBAC and ABAC: How Intent-Based Access Control Simplifies Securing AI Agents

Before agents, access control came down to two questions: who can access, and what data. Clean, static, done. That's not enough anymore. There's a lot more context sitting underneath every decision now, and nailing it down as a fixed set of rules is too rigid for a world where AI agents move at machine speed.

Intent-based access control (IBAC) is a security model that evaluates whether an AI agent's actions match the purpose it was built for, and blocks anything that falls outside that purpose, even when an existing role or policy would technically allow it. It's a different question than the one access control has answered for the last twenty years, and agents are forcing us to ask it.

Static policies don’t scale

Here's a scenario that comes up more than people expect. A database administrator has the usual permissions: create, drop, modify, whatever they need day to day. Now that same person builds an agent whose entire job is loading data. Nothing about deleting anything.

But the agent still has the underlying permissions, inherited from the person who built it. If it suddenly starts, whether through hallucination or through a prompt injection, saying "I want to go delete these records," and it just goes ahead and does it, that's a story we've all heard: an agent takes over someone's permissions and deletes not just databases but repositories and everything else.

Now think about what it would take to prevent that with a traditional ABAC policy. You'd need a rule for this agent, this dataset, this action, this condition, and then another rule for the next agent, and the one after that. Every new agent means another branch in an already sprawling tree, and someone has to maintain all of it by hand. That's the real cost of solving this the old way. Not that it's impossible, but that it doesn't scale.

How is IBAC different from RBAC or ABAC?

This is the first thing anyone who hears the term “IBAC” wonders: isn’t this just another attribute feeding into the same policy engine?

Technically, yes, in part. It ends up being one more input signal in the policy evaluation. But functionally, the difference is in what it saves you from doing. As an agent developer, you don't have to go define a bunch of additional policies for every scenario you can imagine. What matters instead is the context under which the agent was built in the first place. What was its expressed intent? If it was registered as a data-loading agent, that's its job: go get the data from various systems, understand the model, load it. That expressed purpose becomes the boundary, without anyone having to manually write it out as a rule, and without the rule set growing every time a new agent gets added.

A decision with a reason 

Say a finance team builds an agent to analyze salaries and output across the company. It's supposed to look at aggregate numbers, without divulging any single person's specific details. The agent still has access to the underlying data, because it needs it to do the analysis.

Now say someone logs in and asks, "show me this specific person's salary." That's not analysis anymore, that's a specific person's details, and giving that up was never the intent behind why the agent was built. The agent might technically still have access to that data, but it was never supposed to give up that individual's outcome.

What matters here isn't just that the request gets flagged. It's why. The context of the question and the context the agent was built under are deviating from each other, and that gap is the actual reason on record, not just a yes or no. For anyone who has to explain an authorization decision after the fact, whether that's a security team or an auditor, having a stated business justification tied to the decision is worth a lot more than a static role match ever was.

Scoped to the job, not policed after the fact

More organizations are chaining agents together now: an external agent invoking a data-loading agent that runs inside Snowflake, orchestrated through a CI/CD pipeline or something similar. The invoked agent doesn't know any better. It takes the permissions it's been handed and executes whatever comes through, even if that means a delete command it was never built to run.

The agent running in Snowflake was expressly built for loading data. Framed around least privilege, the point isn't that a delete request comes in and gets caught right before it happens. It's that the agent was never scoped to have that kind of room to begin with. Enforcement follows the agent's own registered purpose, regardless of what the calling agent, or the calling agent's calling agent, is asking for.

MCP tool granularity isn't enough on its own

Not every MCP tool is granular enough to build the old create/read/write/delete style policies on top of.

That gap matters. If the scope an agent gets depends entirely on whether the underlying connector happens to expose the right level of control, boundaries end up inconsistent depending on which system an agent happens to be talking to. Intent-based access is meant to work on top of that layer: even without a corresponding MCP tool for it, write, read, or delete can still be scoped down to what the agent's purpose actually calls for.

Why this matters beyond the security team

Every agent an organization builds needs some kind of access boundary. Do that with policies alone and you end up maintaining a deeply nested, constantly growing set of rules, one for every agent, every dataset, every scenario someone thinks to write down in advance. That's real time, and it translates directly into dollars and into the kind of mistakes that happen when humans are the ones building all those rules by hand.

The other side of it is what happens when someone has to explain a decision after the fact. A static permission check tells you an agent was technically allowed to do something. It doesn't tell you why that made sense in the moment, or whether it still does. Tying authorization to a stated purpose gives security and compliance teams something a static role never could: a business reason behind every decision, not just a pass or fail.

This is still early. Most organizations are just starting to think about what access control looks like once agents, not just people, are the ones making requests. The shift from "who can access what" to "does this match what the agent is actually here to do" is going to keep showing up as agentic systems take on more of the work that used to sit with a person at a keyboard.

‍