One task. Multiple systems. Multiple access relationships.
By Phill Parry, Pre-Sales Consultant, Intragen
Key Highlights
AI agent access control should be scoped to the task, not the role, and should expire when the task is done. Getting there starts with finding the agents you already have.
AI agent access control is the set of rules and checks that decide what an AI agent can reach, not just whether it can log in. Identity is the starting point. The harder question is what the agent can touch once it's running, across every system a task needs, and whether it still has that access after the task is done.
Before you can scope an agent's access, you need to know it exists. Agents built by business teams, in low-code tools or inside the SaaS platforms they already use, often never reach IT. They still connect to real systems with real credentials. So the first step isn't tightening permissions. It's finding the agents, and seeing what each one is connected to.
Take an HR agent asked a single question by an employee: why does my payslip look different this month? To answer well, it may need payroll to see the figures, the benefits platform to check a change in pension or salary sacrifice, and the employee's personal record to confirm their contract details.
One question. Three systems. Three access relationships, each holding sensitive personal data. Data minimisation says the agent should reach only what that single query needs: this employee's records, for this question, and nothing else.
The same shape shows up everywhere an agent is useful. A customer service agent resolving one complaint may need order history, billing and the shipping platform. A travel agent booking one flight may need the expense system, a payment method, the traveller's calendar and the airline. From the outside, each is one task. Underneath, it's a small web of access.
People pick up extra access over time too. It's why access reviews exist. What's different with agents is that they act on their own, at a speed no person can match, and they can be steered by the instructions they're given, including malicious ones hidden in an email, a document or a web page. So access that's too broad does more damage, faster, and often before anyone notices.
This isn't a fringe concern. OWASP, the open security community, lists it as "Excessive Agency" in its Top 10 for LLM Applications: giving a model more functionality, permissions or autonomy than its task requires.
Role-based access control, assigning access by job function, is a sensible starting point and most identity platforms already do it well. For agents it's necessary but not sufficient. A person's role is fairly stable day to day. An agent's need can change task by task, and a role broad enough to cover everything it might ever do is broader than any single task needs. Role-based access control tells you what an agent may do in general. It doesn't tell you what it should be able to do for the thing it's doing right now.
Our view: scope access to the task, not the role, and make it expire.
In practice, a right-sized HR agent reads only the records of the employee who asked, can't change payroll data, and has no standing access to anyone else's file. A right-sized booking agent sees only free or busy on the calendar rather than meeting details, pays with a capped virtual card rather than a company card, and loses access once the booking is confirmed.
None of this makes the agent less useful. It makes the blast radius of a mistake, or a manipulated instruction, small enough to live with.
Four are worth asking, whether you're reviewing an agent you already have or adding a new one:
Answering these well for even one agent usually tells you something true about the rest, since agents tend to be set up the same way across a business.
If you want a straight answer on where your agents stand against those questions, download "The Agent Blind Spot" or book the free 30-minute Agentic Identity Readiness Assessment. No product pitch, no fixed scope.