How Should AI Agent Access Control Decide Each Tool Call?

On a Friday afternoon, a sales agent asks to export 4,000 customer records to a spreadsheet on the company drive. The person behind it can read those records, the connection allows exports, and the check fires as designed, so now it has to decide. AI agent access control is the practice of deciding, before each action runs, whether an AI agent may take it, based on whose authority it spends, what the call does, what it touches, and what the session has done.

For that export, allow and deny are both wrong answers. Your check can find a better one only if you designed it to.

Roles and scopes can't help, since both already said yes, and the agent will act on whatever the check says next. A plain yes exposes more than the task needs, and a plain no sends the agent looking for another way to finish the job. This article shows how to build that check from seven inputs, three verdicts, and tested rules, and how to prove it keeps working when agents combine duties, call other agents, or get denied.

Is role-based access control enough for AI agents?

Role-based access control isn't enough on its own, because every grant your agents carry was approved before the agent chose what to do with it. Sign-in confirmed the person that morning, an OAuth consent screen approved a connection's reach the day someone set it up, and roles decided long ago which apps that person could reach. Each of those decisions answers whether an identity may get in, and none of them sees which action the agent picks once it's inside. That blind spot is where the risk in AI agent permissions lives.

Scopes are just as coarse. A GitHub token with write access to a repo's code can read a README or push a commit, and nothing in the token says which one a given call will do.

Google's security researchers reach the same conclusion in their paper on securing AI agents. Its second principle says an agent's permissions should line up dynamically with its purpose and the user's current intent, rather than only being minimized once in advance. The paper's example is an agent that switches off file deletion while it helps with creative writing.

Roles and scopes still earn their place as the ceiling on what an agent can reach, and a check on every tool call belongs at the center of AI agent identity governance. The harder question is what makes that check decide well, starting with what it can see.

The seven inputs every AI agent access control decision needs

A check that sees only the person and the tool can't tell the Friday export from the same 4,000 records headed to a personal inbox. A sound decision reads seven inputs, and each one your check can't see is a decision made blind. The prompt isn't one of them, because an injected instruction can rewrite what the model was told. Agentic AI security assumes that will happen, so the decision judges what the call will do and holds even after the model has been talked into something.

Zero trust asked for this shape years ago. In NIST SP 800-207, a policy engine decides access through dynamic policy that weighs the observed state of identity, application, and asset, and the enforcement point can sit on the client. Agents shrink that dynamic access control from a session to a single call, which is what zero trust for AI agents comes down to.

1. The human behind the session

An agent's call spends some person's authority, and the decision has to know whose: their role, their groups, and whether they still work for you. It comes from your identity provider and HR data, and it's the easiest input to lose, because agents often run on shared or long-lived tokens that don't say whose they are. Without it, the decision can't apply the person's own limits, so an agent on a shared team token can do things its own human was never allowed to do.

Because its check runs in each employee's agent client, Lumos MCP Governance stamps every call it covers with the human behind it, and it never sends or stores prompts, model responses, or tool results. Knowing the human also tells you when the agent's access should end, the day that person leaves, which is where AI agent lifecycle management takes over.

2. The agent and its client

The decision also needs to know which agent is calling, through which client, and on which device, since terminal, desktop, web, mobile, and custom clients each bring different controls. Device management vouches for the device, but the agent's identity needs its own proof, such as a signed client or a per-agent credential, because a tampered client can claim to be anything. If the decision can't see this input, two agents running for the same person look identical, and an agent on an unmanaged laptop gets the same latitude as one on a managed device.

Good human access programs already weigh the device: at Intercom, employees request apps from Slack, with device trust-based authentication securing that flow. An agent's client deserves the same weight in the decision that a person's laptop already gets.

3. The delegation chain

When agents hand work to other agents, the decision needs the full chain: every agent that passed the task along, what the task is for, and the person who started it. It comes from delegation tokens or metadata the orchestrator attaches to each call, and when nothing carries it, a call three hops from the person arrives looking like the orchestrator's own. Without it, a sub-agent can act on authority nobody granted it, and nobody can say afterward who asked for the action. It also supports a baseline rule: no call runs unless its chain traces back to a named person.

4. The tool and its server

Each call invokes a capability, and the decision needs to know which one, which server provides it, and which version is running. Your tool registry or the MCP server's tool list supplies it, checked against the servers you've approved, and the version matters because an approved server can change what its tools do after sign-off. A decision that can't see it treats a server an engineer added on a laptop last night like one security reviewed, and malicious servers rank among the AI agent security vulnerabilities no patch catches. One rule depends on it: tools from unapproved servers don't run until someone approves them, since even a read sends that server your arguments and puts its output in front of the agent.

5. The arguments

The arguments say what a call will do: the verb, the records it names, how many rows it touches, and where any output goes. The call payload carries them, and they matter more than the tool's name, since one query tool can read a report or drop a table depending on its SQL. Strip them out and a call that deletes looks exactly like one that reads. In the Friday export, the destination decides whether the call runs, and the row count decides how much comes back.

6. The target

The target says what a call touches: which environment, which app, and how sensitive the data is. Resource tags and your data catalog supply it, and tagging production is the quick half of that work. A decision blind to the target treats staging and production alike, and a delete that's routine in one causes an outage in the other. With it, rules can combine inputs, letting writes to production run only for agents whose human is on call.

7. The session so far

The session so far is the decision's memory: what this run has read, what untrusted content it has taken in, and what it has sent. It comes from the session's call record, backed by the agent's history across earlier runs, which shows when a call is new for this agent. Without it, calls pass one at a time while the sequence leaks, since reading customer records and emailing a file to an outside address are each routine on their own. A session-aware rule closes that gap: once a run reads customer records, nothing else in it sends data outside the company.

Three verdicts for AI agent tool calls besides allow and deny

Denying the Friday export stalls the sales team, and allowing it as asked puts 4,000 records, payment fields included, into a spreadsheet. Three verdicts cover most of what falls between allow and deny: allow with a constraint, route to a person, and allow while watching closely. For the Friday export, the right answer is yes, capped at 500 rows, with payment fields redacted.

1. Allow with a constraint

Constraints carry most of the value, because they let the useful part of a call through. A coding agent can run terraform plan while apply waits for a person, and a build agent can write to a branch instead of main. A reporting agent can read from a replica, return the first 50 rows, or get payment and identity fields redacted. A constraint also has to announce itself, so an agent handed 500 of 4,000 rows knows the list is partial and how to ask for the rest.

XACML 3.0, the OASIS access control standard, settled this long ago: a decision can carry obligations, and an enforcement point that can't carry them all out has to deny access. Apply the same rule to agents: if the client can't apply the constraint, the call doesn't run.

2. Route to a person

Routing to a person only works if the approval doesn't outlive the task, since a standing grant undoes the decision it was meant to protect. In the Lumos Identity Agent Force, the Access Request Agent grants access only as long as it's needed and revokes it automatically, so a person's yes expires with the task. Who should give that yes depends on what the action can break, and the approval matrix for AI agent access management sorts that by reversibility and reach.

3. Allow while watching closely

Watching closely is the verdict most teams forget. A first call to a new server, or a read that's routine for the person but new for the agent, can run with fuller logging and an alert to the agent's owner. The work keeps moving, and a human looks at exactly the calls a static rule can't judge.

AI agent policy enforcement starts with rules you can test

A rule you can't test is a rule you can't trust. A structured rule states exactly which inputs it reads and which verdict it returns, so a reviewer can check it and a test suite can exercise it. Policy written this way is AI agent authorization you can defend in an audit, and it keeps AI agent policy enforcement honest, because the rule a reviewer approved is the rule that runs.

Each rule's tests should prove that known-bad calls fail and known-good calls pass, and each change reruns them before it ships. For the Friday export, the suite confirms that an export to a personal inbox fails and that 4,000 rows headed to the company drive come back as 500, with payment fields redacted. Before a rule blocks anything, replay last month's calls against it, the same log-only rollout a sound MCP governance policy sets for new rules. Record the policy version with every verdict, so a disputed decision traces to the exact rule that made it.

Treat the policy repo like code you ship: each rule gets an owner, changes go through review, and a rollback is one commit away when a new rule blocks something it shouldn't. No agent gets write access to that repo, its own client settings, or the hooks that check its calls.

Writing those rules by hand doesn't scale, and handing the call to a model doesn't hold up. Albus writes a policy from a plain-language description, drawing on observed usage and what it knows about your servers and tools, and you review it before it takes effect. Our CEO, Andrej Safundzic, has argued that in security, "getting it 95% right is the same as getting it wrong," since finding one bad grant among 100,000 takes 99.99% accuracy. So AI drafts the rule, and the rule, which you can test and explain, makes the call.

Write five tests for each of your three highest-consequence rules before you turn any of them on. A rule that can't pass its own tests isn't ready to block anything.

How does separation of duties apply to AI agents?

Your separation-of-duties report counts what each person can do, and it doesn't count what their agents can do. Creating a vendor and approving its payment is the classic conflict, harmless apart and fraud together. Now picture a buyer who can create vendors and whose agent is wired to a finance integration that can release payments. The pair holds the conflict, and each one's report comes back clean.

Albus, at the center of Lumos's agentic AI security work, already answers separation-of-duties questions about human access in plain language, such as "Show me all SoD violations in Finance." That analysis has to treat every connection a person's agents hold as that person's access, or the most dangerous pairs never show up. At call time, the same logic becomes a rule: deny a payment release when the vendor was created by the same person or by that person's agent. Write that rule into your AI agent access policies first, so the call-time check enforces something a person signed.

Lumos gives Roku built-in support for SOX compliance, segregation of duties, and audit trails. Agent-held access belongs in that record too, certified in the same campaigns your user access review software already runs for people.

Some conflicts live inside a single session. Meta's Agents Rule of Two says an agent should combine no more than two of three properties per session: processing untrustworthy input, reaching sensitive data or internal resources, and changing state or communicating externally. A task that needs all three needs supervision, such as a person's approval, or a fresh session. Read with an identity team's eyes, that's separation of duties for a session, and it matches the AI agent access security best practices that split agents reading outsider text from agents that act.

‍

Rerun your SoD report with agent connections attributed to their humans, then list the sessions that can hold all three properties today. Those two lists are your first separation-of-duties rules for agents.

How should access control work when AI agents call other agents?

Authority should shrink at every hop of an agent chain. When a support lead asks an orchestrator to merge duplicate tickets and notify the customers, the sub-agent sending notices acts two hops from the person who asked. The decision at that call needs the person at the start, every agent in between, and the overlap of what each of them is allowed to do. Anyone working out how to secure AI agents should test the chain as a whole and count the orchestrator as holding everything its sub-agents can reach.

Three rules keep a chain honest. Each hop can only narrow what the next agent may do, so a sub-agent never holds a permission its caller lacks. The original purpose travels with the request, so the notice sub-agent can send on those threads and edit nothing in the CRM, and the whole chain expires when the task does. In practice, each call should carry a delegated token limited to what its caller could do, since an agent acting on its own standing access is an escalation path.

Standards bodies are building the plumbing. The IETF's OAuth working group has a Transaction Tokens draft, written for chains of service calls, that carries the requester's identity and authorization context through each hop inside one trust domain. Its tokens last minutes or less, and it isn't a finished standard yet. Where a chain crosses into another company's service, OAuth token exchange can carry that authority across the boundary and record the agent as an acting party.

Lumos Labs calls for audit trails that capture complete action trajectories, and a delegation chain is exactly that kind of trajectory. Labs also plans to interoperate with emerging standards such as Cross App Access (XAA), which lets a company's identity provider approve connections between apps. The audit record should read as one story, from the person to the last tool call.

Design denials that neither AI agents nor engineers route around

To an agent, a failure is a problem to solve, and a deny is a failure. In April 2026, a coding agent on a staging task at PocketOS, which makes software for car rental operators, hit a credential mismatch and set out to fix it. Assuming a database volume belonged to staging without checking, it deleted the production volume and its volume-level backups in one API call under a fully permissioned token, according to Decrypt. It took about nine seconds.

PocketOS restored operations from a three-month-old backup, and its founder said significant data gaps remained. A token scoped to the task and backups stored apart from the volume would have limited the damage. A rule keyed to the target, such as "no agent deletes production volumes or backups, whatever the credential," adds a check on every path your decision layer can see. Had that rule stopped the call, the agent would have faced a deny, which is one more failure to solve, so the deny must tell it what to do next.

A good deny has two readers. The agent learns what would pass, such as a query capped at 50 rows or the staging replica, while the detection logic stays private so an injected instruction can't learn how to rephrase. The person sees the rule that fired, who owns it, and a path to a grant that expires, confirmed with a fresh sign-in in case the session behind the request is compromised. Meanwhile, the decision layer flags any retry against the same target through a different tool, shell command, or credential.

Engineers route around denies too, which is why AI agent governance best practices start with making the governed path the fastest one. When a rule blocks an agent with no explanation and no path forward, the fastest fix is a broader token or an MCP server the check can't see, which makes the next decision worse. Read your last 20 denies the way an engineer would, and fix any that don't say what to do next.

Speed decides whether the path to a grant gets used. At Chegg, approvals route to managers through a delegated framework, so IT no longer sits between requester and approver, and Lumos logs every request. Self-service requests resolve in about a minute, and manager approvals land within minutes to hours. A deny that turns into a request that fast leaves engineers no reason to hunt for a broader token.

Seven metrics that show whether AI agent access control works

A dashboard that counts how many calls your check sees and how many it blocks can't tell you whether the verdicts were right. Coverage, attribution, and approval rates prove the control exists, and the six control metrics for MCP security cover that ground. Decision metrics show whether access control for AI agents gets the answers right.

Seven of them cover most of what can go wrong, and all seven come from the decision record. If your check logs the human, the inputs, the verdict, and the policy version for each call, each number is a query, and if it doesn't, fix the record before any rule.

• False-deny rate: denies later approved as legitimate.
• Deny-to-grant time: how long a legitimate request waits after a deny.
• Retry-after-deny rate: the same target attempted through another tool, command, or credential.
• Override rate: how often people set a verdict aside, and who does it.
• Rule fire pattern: how often each rule fires against what you expected, since a backstop should stay silent and a row cap may fire all day.
• Version regressions: verdicts that changed after a policy update when nobody meant them to.
• Share decided by policy: decisions made with no person in the loop.

We treat the false-deny rate as the hardest, since judging what an action will do without blocking useful work is still a research and engineering problem. That rate shows where your rules stand on it.

The share decided by policy is the number to push. Tekion handles more than 1,500 requests a month from its employees and resolves 95% of its tickets without manual intervention, which shows policy can carry most of the load for people. Agents need a higher bar, since 5% of thousands of calls an hour still leaves 100 or more decisions an hour waiting on a person. In the Identity Agent Force, when an agent escalates an edge case, the person's decision becomes a rule the agents apply afterward, so the share decided by policy keeps rising.

Review the seven numbers weekly for the first quarter, then monthly. The best identity governance software should report all seven for agents alongside the review and approval numbers it already tracks for people. Put rules that come from escalations through the same tests and review as any rule you write by hand, and retire any rule nobody can explain.

Agentic AI access control starts with decisions you can explain

Access was designed for people who act a few times a day, and your agents act thousands of times an hour. That shifts the weight of your access program onto the decision at each call, and a decision you can't explain, test, or improve won't carry that weight for long. Treat every decision your agents trigger as code you'd ship.

Start this sprint with the agents that touch customer data: map their seven inputs, write and test your three highest-consequence rules, and rewrite the denies they hit most. Lumos runs the parts that don't scale by hand: MCP Governance checks agent tool calls against your policy before they run, and Albus drafts that policy from what your agents already do. The Identity Agent Force gives every agent and the non-human identities it runs on a human owner, so each call can name the person behind it. Book a demo and bring your own Friday export.

‍