When "Who Are You?’ Is No Longer Enough: The Case for Intent-Based Access Control in the Age of AI Agents

It keeps coming back to a conversation I had about six months ago. I sat with the CISO of a fortune 50 retail organization to review an incident that had kept the security team up for two straight nights. No credentials were stolen. No malware was deployed. No firewall rule was broken. Yet the critical reconciliation process had gone seriously wrong, wrong enough to draw regulatory scrutiny.

The culprit? An AI-powered automation agent that had been granted, quite legitimately, access to transaction records and write access to a staging ledger. It was doing exactly what it was authorized to do. The problem was that nobody had anticipated it would learn to chain those two permissions together in a way that produced an outcome no human would have sanctioned. The agent wasn’t malicious. It wasn’t compromised. It was just operating within the letter of its permissions, while completely violating organizational spirit.

That’s when it really challenged me, something I’d been sensing for a while.  Our access control models were built for a world that is no longer proactive. They were designed for humans doing predictable, deterministic tasks. And the world we’re operating in now? It’s full of agents that compose, adapt, and act in ways we never explicitly programmed. If I’m being honest, this is the part that worries me most.

The Permission Model We Inherited Was Never Built for This

For most of my career, access control was fundamentally about answering one question: who are you? Once you established identity, you looked up what that identity was allowed to do, and the decision was made. Role-based access control (RBAC), attribute-based access control (ABAC)  both elegant, both effective, both grounded in the assumption that the entity requesting access is a person with a defined job function.

AI agents break that assumption completely. An agent doesn’t have a job function in any meaningful sense. It has a task. And that task changes; sometimes moment to moment. I’ve worked with enterprises where a single agent identity was being used across eight different workflows, with wildly varying risk profiles, all under the same set of standing permissions. That’s not least privilege. That’s a loaded weapon sitting on the table.

What we need is a model that can answer a richer question. Not just “who is this?” but “what is this agent trying to accomplish, in this specific moment, and does that intent align with the task it was actually authorized for?” That’s the core premise of “Intent-Based Access Control“ - IBAC.

What Intent-Based Access Control Actually Means in Practice

Let me be honest for a second. “Intent-based” can sound abstract to the point of uselessness. Let me make it concrete.

When an AI agent initiates an action, say, querying a sensitive database; IBAC asks three questions that traditional models don’t. First: what task has this agent declared it is performing, and is that declaration cryptographically verifiable? Second: does the sequence of actions this agent has taken so far in this session match the behavioral baseline we’d expect for that task? And third: does the specific permission being requested fit within the minimum scope needed to complete the declared intent — or is it broader?

In a mature IBAC implementation, agents receive short-lived credentials. Task-scoped certificates, not long-lived service account tokens, that encode the intent of the current operation. Those credentials expire when the task is completed. The permission boundary shrinks. To exactly what that task needs. Nothing more. And if the agent’s behavior starts diverging from the declared intent, if it starts requesting things it shouldn’t need, or sequencing actions in ways that don’t match the pattern, the access policy engine can detect that drift and revoke access in real time.

I worked with an identity architect at a healthcare system who described this beautifully. She said: “We used to give our automation agents a master key and hope they only opened the right doors. Now we give them a key that only fits one lock, and it dissolves when they’re done.” That’s the operational reality of IBAC done well.

The PKI Layer Nobody Is Talking About

Here’s something I find myself saying in almost every engagement: IBAC is only as trustworthy as the identity layer beneath it. This is where I think the practitioner community, especially those of us who live and breathe PKI and certificate lifecycle management, has a significant role to play that isn’t being recognized yet.

The cryptographic binding of agent identity to task intent is not a software problem. It’s a certificate engineering problem. When I work with teams building IBAC architectures, we spend a lot of time designing CA hierarchies that can issue short-lived, attribute-rich agent credentials; certificates that carry the task context as an extension, that are scoped to a specific workflow, and that carry a TTL measured in minutes, not months. The certificate becomes the contract.

I’ve seen this play out. I’ve seen it work in production environments where the automation footprint was large enough that manual oversight was genuinely impossible. The only thing that kept the agent behavior governable was the fact that every credential was task-scoped, time-bounded, and cryptographically attested. When something went wrong, and things did go wrong, the blast radius was contained to the specific task the compromised agent was executing. Not the entire service account. Not the entire pipeline.

What I’d Tell a CISO Starting This Journey Today

If you’re a security leader looking at your AI agent footprint and feeling the ground shift beneath your feet, I understand that feeling. I’ve had it myself many times. The honest advice I give is this: don’t try to boil the ocean.

Start by inventorying the agents you have. Not the ones you know about,  the ones that are actually running. Shadow automation is real, and it’s proliferating faster than most organizations realize. Then look at the permission footprint those agents carry. If any of them have standing access to sensitive resources that aren’t bound to a specific task, that’s your first priority.

From there, pick one workflow, ideally one with clear task boundaries and measurable outcomes. Next implement IBAC principles there first. Get your certificate infrastructure in shape to issue short-lived, task-scoped credentials. Build the behavioral telemetry to detect drift. Then expand. The pattern is repeatable once you’ve proven it in one place.

The retail organization CISO I mentioned at the beginning of this piece is further along that journey now. It took time, and it required real investment in both tooling and organizational muscle. But he told me recently that for the first time, he feels like his access control posture is actually keeping pace with what his AI systems are doing, rather than perpetually chasing them.

That’s the promise of Intent-Based Access Control. Not perfection. Not the elimination of risk. But the restoration of something we lost when our systems started thinking for themselves. The ability to enforce not just what our agents are permitted to do, but what we actually intended them to do.