AI Governance & Ethics

21 MIN READ

Role-Based Access Control for AI Systems and Agents

A role check won't stop an AI agent's confused-deputy attack. Role-based access controls for AI need information flow governance and intent-scoped grants.

Assign an AI agent a role, and most security teams treat Role-Based Access Controls for AI as solved. That single assumption drives 126 rising reader questions on identity and access management, because a role built for a human employee cannot bound what an autonomous agent does with what it retrieves.

Where this article sits

Journey stage 7 of 7: Scale

readiness → use-cases → roi → pilots → kpis → operationalize → scale

this articlelinkedjourney stagepillarrelated (no direct link)

Your trail so far

The articles you visit light up on this map.

Role-Based Access Control for AI: Definition and the Identities It Covers

Role-based access control (RBAC) for AI grants permissions to roles rather than to individual subjects, then assigns every human user, AI model service, and AI agent to one of those roles, so no subject ever holds a permission directly. The definition sounds settled until the assigning stops at the label and never asks where the model came from.

David Ferraiolo and Richard Kuhn’s paper, “Role-Based Access Controls” Role-Based Access Controls (Ferraiolo and Kuhn), frames RBAC as a non-discretionary access control: a control more central to the secure processing needs of non-military systems than discretionary access control (DAC). Non-discretionary means the organization sets each permission at the role level; no individual data owner grants or withholds access case by case. That distinction carries more weight for AI than it did for the systems Ferraiolo and Kuhn originally described, because an AI system touches thousands of resources no single data owner reviews one at a time.

RBAC for AI has to cover three distinct kinds of subject. People who use AI systems need roles the same way they need roles for any application: a support agent’s role should not let them export a customer database just because a chat tool happens to carry that capability. AI systems themselves, running as services, need roles that scope what data and functions they may reach on the organization’s behalf. AI agents that call tools, chain actions, and act without a human confirming each step need roles too, and for a reason the first two subjects do not share: an agent belongs to the broader class of non-human identities: it is a distinct principal with its own credentials, scopes, and lifecycle, not a delegated extension of whichever employee triggered it. Which team owns that lifecycle, and how its credentials get issued and retired, is a governance procedure of its own: the mechanism belongs here, the operating steps sit further on.

Pages that rank for role-based access control tend to describe it as a product configuration: connect the identity provider, define the roles, assign the users. That framing treats RBAC as an IAM setting. The non-discretionary principle says otherwise. When the organization, not the individual system owner, decides which permissions attach to which role, and an AI agent is one of the subjects that role binds, the decision governs what an autonomous system may do in the organization’s name before any single interaction happens. Treating it as a configuration task hides the governance question inside a settings screen.

How Does RBAC Differ from Attribute-Based Access Control?

Attribute-based access control (ABAC) grants or denies a request by evaluating attributes of the subject, the resource, and the environment at request time, rather than checking membership in a predefined role. RBAC’s advantage for AI governance is auditability: a reviewer can list every role and see exactly which permissions attach to it, where an ABAC policy’s effect on a given request only becomes clear by evaluating the rule against that request’s attributes. Most AI governance programs keep RBAC as the outer layer for that reason, then let context-aware controls like the ones covered next narrow what a role permits at the moment of use, rather than replacing the role with a pure attribute-matching system.

Can an AI Agent Hold More Than One Role?

An agent that serves more than one workflow often ends up assigned to more than one role, and the permissions from every role it holds combine unless the system explicitly resolves conflicts between them. A support agent handling both order lookups and refund processing might hold a read-only role for the order system and a write-enabled role for the payments system, and if those roles are not modeled separately, the combination can leave the agent able to write to systems no single task justifies. Treating each task’s role assignment as its own scoped grant, rather than folding every capability an agent might ever need into one broad role, keeps the combination from becoming a standing excess of privilege.

Why Static Roles Fall Short for LLM-Based Agents: Information Flow and New Attack Surfaces

Static, rule-based role assignments cannot secure large language model agents on their own, because a role bounds which tools an agent may call, not what the agent does with the information it retrieves once a task is underway. Two research groups working through 2025 and 2026 trace that gap to specific, nameable mechanisms rather than to a vague sense that agents are riskier.

From Permission to Information Flow: The Agent Access Control Framework

Multi-Dimensional Contextual Evaluation

Contextual evaluation is the first module of Xinfeng Li and colleagues’ Agent Access Control (AAC) framework Agent Access Control (Xinfeng Li et al.), and it assesses more than the identity a role check would examine. The module reads the relationship between the agent and the resource it is about to touch, the scenario the request sits inside, and the norms that govern that scenario for that organization. Where a role check answers one question, does this principal hold this permission, contextual evaluation answers several at once, and it re-answers them for every request instead of settling the question once at assignment time.

The distinction matters because an agent’s role rarely changes mid-task, but its context does, constantly. The same support agent that reads a customer’s order history to process a refund reads the same table minutes later while drafting a marketing segment, and only one of those reads matches the scenario the role was granted for. Contextual evaluation catches the mismatch a static role cannot see, because the underlying permission never changed; only the relationship between the request and the task did, and that relationship is exactly what a role assignment leaves unrecorded.

Adaptive Response Formulation

Adaptive response formulation is AAC’s second module, and it replaces the binary allow-or-deny decision a role check produces with a shaped response: redaction, summarization, or paraphrasing of the information the agent would otherwise receive whole. Instead of blocking a request outright, the system returns a version of the answer that fits the context the first module evaluated: a redacted record, a summarized set of fields, or a paraphrase that omits the specific values a role was never meant to expose in full.

That shift matters for agents in particular, because a hard deny breaks a chained task in a way a human rarely tolerates: an agent mid-workflow that hits a flat refusal often retries, escalates its own request, or routes around the block rather than stopping to ask. Shaping the response instead of refusing it keeps the task moving while withholding exactly the fragment the context flagged, closing a gap that neither a role assignment nor a simple allow-or-deny gate closes by itself.

What Is Information Flow Governance?

Contextual evaluation and adaptive response formulation are both instances of a broader pattern researchers call information flow governance: tracking not just whether a principal holds a permission, but where a piece of information travels after an agent retrieves it, and what the agent does with it next. A role check answers a question about the principal; information flow governance answers a question about the data itself, following it through summarization, retrieval, and hand-off to another tool or agent. That shift in what gets tracked is why AAC’s two modules work together; contextual evaluation decides how a specific flow should be treated, and adaptive response formulation carries that decision out, rather than each module answering an unrelated question in isolation.

Attack Surfaces a Role Does Not Close: Injection, Confused Deputy and Cascading Failures

Ninghui Li, Kaiyuan Zhang, Kyle Polley and Jerry Ma map the attack surfaces a role assignment does not close: tools, connectors, hosting boundaries, and multi-agent coordination Kaiyuan Zhang (Ninghui Li et al.). Their account, adapted from Perplexity’s response to a 2026 NIST and CAISI request for information and drawing on Perplexity’s experience running agentic systems for millions of users and thousands of enterprises, describes how agent architectures change code-data separation, authority boundaries, and execution predictability all at once. Inside those changed surfaces, three failure modes dominate: indirect prompt injection, confused-deputy behavior, and cascading failures across long-running workflows.

Confused-deputy behavior is the plainest of the three to explain: the agent uses its own legitimate role to carry out an action an attacker requested through content the agent merely read. The role check passes, the agent holds that permission, and the failure stays invisible to any system watching only for permission violations.

Recognizing confused-deputy behavior in a running agent takes tracing, not scanning. The sign is an action the role permitted but the task’s documented business purpose, allowed tools, and data domains do not cover. The test is to trace the instruction behind each sensitive action back to its origin; an origin in content the agent read, a document, an email, a web page, a connector response, or another agent’s output, rather than in its own principal, marks the deputy as confused. The method is to record the tool called, the data touched, and the instruction’s origin for every sensitive action, then check each high-consequence action against the documented boundary before it runs: the deterministic policy enforcement Li, Zhang, Polley and Ma call for, laid out as an operating step further on.

Cascading failures compound the same blind spot across a multi-agent workflow: one agent’s confused-deputy action becomes the next agent’s trusted input, and the role checks along the chain keep passing because each individual permission was, in isolation, granted correctly. The role says what the agent may touch; it says nothing about what the agent then does with it, or who reads that output next.

How Does Indirect Prompt Injection Exploit a Role a Human Never Sees?

Indirect prompt injection does not touch the agent’s role at all, which is what makes it the hardest of the three failure modes to catch with access control alone. An attacker hides an instruction inside content the agent is expected to read anyway, a web page, an email, a document, or a connector’s response, and the agent’s own role never changes; only the instructions the model follows do. The role check that runs before the agent calls a tool has nothing to flag, because the call itself is one the role permits; the compromise happened earlier, when the model treated attacker-supplied text as if it carried the same authority as the user’s own request. Catching it requires the same origin-tracing method that exposes confused-deputy behavior: treating instructions that arrive inside retrieved content as untrusted input, distinct from the instructions the authenticated user issued, no matter how fluently the retrieved content reads.

Least Privilege for AI Agents: From Standing Permissions to Just-in-Time, Intent-Scoped Access

Least privilege for AI agents replaces standing, broadly scoped credentials with short-lived, intent-scoped grants that narrow an agent’s authority to the specific request in front of it, then let that authority expire when the request completes. The role from earlier still sets the outer boundary; least privilege narrows what an agent can reach inside that boundary at the moment it acts.

The Standing-Permission Problem: Integration Credentials That Exceed the Request

Genliang Zhu and Chu Wang open their account of AI agent authorization with a plain observation: tool-using agents commonly operate under integration credentials whose static permissions exceed whatever the user actually asked for in the current request (Genliang Zhu and Chu Wang). An agent connected to a calendar, a repository, and a payments API typically holds all three integrations’ full scope at all times, whether the task in front of it needs one of them or all three.

That gap between held authority and needed authority is what standing privilege means in practice, and it is also what turns a single confused-deputy moment into a wide-reaching one: an agent tricked into a single unwanted action can reach every resource its standing credentials cover, not only the resource the legitimate task required. Zhu and Wang’s framing treats this excess as the default state of most deployed agents rather than an edge case, which is why they build a mechanism to narrow it at the point of use instead of trying to shrink the standing grant itself.

Intent-Governed Access Control: Short-Lived Certificates Inside Static Policy

Intent-Governed Access Control (IGAC) is Zhu and Wang’s answer to the standing-permission problem: a server-side authorization layer that converts a trusted request into a short-lived intent certificate, narrows the statically authorized tool manifest to what that certificate covers, and checks the proposed tool and payload effects before anything executes.

IGAC carries one safety property worth stating precisely: it cannot grant authority outside static policy. The role assigned earlier remains the outer bound; the intent certificate only narrows what an agent may reach inside that bound for the current request, and confinement to the request depends further on certificate fidelity and sound effect bounds. Zhu and Wang tested a reusable IGAC path across 306 end-to-end model-task runtime trials and report no completed unsafe executions in that combined path; the deterministic runtime comparison reduced their archived composite exposure-or-path indicator from 1.0000 to 0. Unsafe accepted authority still appeared in 0.0909 to 0.2727 of trials, but every one of those residual cases was a non-executed draft rather than a completed action, and the authors identify certificate precision, not the underlying architecture, as the remaining bottleneck.

Just-in-Time Grants in Practitioner Frameworks: Cloud Security Alliance, Microsoft and Zylos AI

Three practitioner frameworks published in 2026 make the same underlying move IGAC makes in research: grant access only at the moment of use, scoped to the declared task, and let it expire when the task ends. The Cloud Security Alliance’s Agent Identity Governance Framework replaces standing privilege with just-in-time, intent-declared, time-bound, scope-limited grants issued per category of agent identity rather than per agent individually. Microsoft’s guidance for AI agent identity pairs a stable, long-lived agent identity for lifecycle management with just-in-time elevation that grants narrowly scoped privileges only for the duration of a specific workflow; task-scoped authorization layered on top of an identity that itself does not change task to task. Zylos AI’s authorization pattern treats each agent as a first-class principal and issues a per-task OAuth token whose scope is narrowed to that single task, rather than reusing one broad token across every call an agent makes.

The three frameworks differ in mechanism but converge on the same shape:

Framework	Grant trigger	Scope	Duration	Mechanism
Cloud Security Alliance Agent Identity Governance Framework	Declared intent for the task	Time-bound, scope-limited grant per identity category	Expires with the task	Just-in-time issuance replacing standing privilege
Microsoft AI agent identity guidance Per-task OAuth (Microsoft)	Task-scoped authorization request	Role modeling gated to the specific workflow	Elevation held only for the workflow’s duration	Just-in-time elevation on a stable agent identity
Zylos AI authorization pattern	Per-task OAuth token issuance	Token scope narrowed per tool call	Token valid for the single task	Per-task tokens with scope narrowing

Reading the three side by side matters more than any single one: an agent identity that stays stable for lifecycle purposes, paired with authority that narrows and expires at every task boundary, is what “least privilege” now means for an AI agent: not a smaller standing role, but a standing identity with almost nothing standing about its authority.

Does Just-in-Time Access Slow Down Legitimate Agent Tasks?

Issuing a fresh grant for every task adds a round trip that a standing credential does not need, and that latency is the most common objection raised against just-in-time access for agents. In practice the round trip is small relative to the model inference time the same request already spends, and IGAC’s own trial results show the added enforcement step did not stop legitimate tasks from completing: the residual unsafe-authority cases were non-executed drafts, not tasks blocked outright. The trade a team is actually making is a few milliseconds of certificate issuance against the blast radius of a standing credential an attacker only has to compromise once; for most agent workloads, that trade favors just-in-time access even before counting the audit trail each fresh grant leaves behind.

How to Govern AI Agent Identities: Ownership, Credential Lifecycle, Enforcement and Audit

Governing AI agent identities means assigning a named, accountable owner to every agentic identity, running a full credential lifecycle of issuance, rotation and decommissioning, enforcing high-consequence actions deterministically, and keeping an audit log of what each agent was authorized to do.

Discover Every Agentic Identity and Assign an Owner

Governing agent identity starts with discovery: a full inventory of every agentic identity running in the organization, organized around the seven pillars the Oasis Security Agentic Access Management Framework names; discovery, ownership, credential lifecycle, access security, vendor trust, monitoring, and continuous risk management.

Ownership is the pillar most governance procedures skip past, and it needs named roles, not a department name. The accountable owner of each agent identity is its human sponsor: a named person, or a well-defined team inside the business function that deploys the agent, who answers for what that agent may do. The AI governance lead owns the written permission policy that states who may grant, change, and revoke a role. Executive leadership answers for the AI risk decision itself, a responsibility the NIST AI Risk Management Framework Playbook’s Govern function documents under its guidance on roles, responsibilities, and accountability for AI risk across the organization. The IAM team and the security team run issuance, enforcement, and logging, but neither one owns the agent; ownership sits with the business sponsor who deployed it.

Run the Credential Lifecycle: Issuance, Rotation and Decommissioning

The credential lifecycle for an agent identity runs through three stages, issuance, rotation, and decommissioning, and skipping any one of them is what produces privilege creep and shadow access months later, long after the original deployment decision is forgotten.

Issuance sets the starting scope and should mirror the intent-scoped, just-in-time grants described earlier rather than a broad, permanent credential handed out once. Rotation replaces credentials on a schedule tied to risk rather than convenience, closing the window a leaked or copied credential stays useful. Decommissioning retires the credential the moment the agent it belongs to is retired, repurposed, or replaced: a step organizations reliably defer because no single team is paged when an old agent quietly stops running but its credential does not. An inventory built during discovery is what makes decommissioning possible at all: an agent identity nobody tracked cannot be retired on schedule, because nobody notices it needs to be.

Externalize Authorization: Policy Enforcement Point and Policy Decision Point

Externalized authorization separates the policy enforcement point, which intercepts each request an agent makes, from the policy decision point, which evaluates that request against policy and returns the allow-or-deny decision the enforcement point then carries out.

Separating the two matters specifically because it keeps authorization logic outside the agent’s own code and outside its own runtime state. An agent whose authorization logic lives inside itself can, in principle, be manipulated into rewriting or bypassing that logic the same way a confused-deputy attack manipulates its task instructions; an agent whose every request passes through an external enforcement point that queries a separate decision point cannot grant itself authority no matter what its own reasoning concludes. This separation is also where runtime enforcement of the just-in-time grants from the least-privilege discussion actually happens: the enforcement point is the component that checks whether an intent certificate or task-scoped token still covers the specific call being made, request by request, for as long as the agent runs.

Enforce High-Consequence Actions Deterministically and Keep the Audit Log

High-consequence actions need deterministic policy enforcement rather than model judgment, layered with input-level and model-level mitigations and sandboxed execution: the defense stack Ninghui Li, Kaiyuan Zhang, Kyle Polley and Jerry Ma describe for frontier agent deployments. Deterministic enforcement means the same request, against the same policy, produces the same allow-or-deny result every time, which is precisely the property a model’s own in-context judgment cannot guarantee call to call.

Audit logging closes the loop: identity assignment, authorization policy definition, runtime enforcement, and audit logging function as one discipline, not four separate projects, and an agent’s actions should never trace back to a shared credential or an untracked grant of authority. Every sensitive action an agent takes should leave a record of the tool called, the data touched, and the policy decision that permitted it, so a reviewer can answer “was this agent authorized to do this” months later without reconstructing the agent’s reasoning from scratch. Record the resulting permission policy itself under the NIST AI Risk Management Framework Playbook’s Govern function, so a governance board can read who may grant, change, and revoke an agent’s role without asking the engineering team to explain it verbally. Vendor trust closes the last gap: roles and scopes granted to an external AI service should follow that service’s trust level and regulatory posture, the same way an internal agent’s role follows its sponsor’s accountability.

Data-Level and Model-Level Access Controls for AI Systems: RAG Filtering and Model Weights

Access control for AI systems needs two layers beyond the role assignment covered so far: filtering at the data layer, so a retrieval system never returns documents a role could not see directly, and restricting access to the model layer itself, including the weights an AI service runs on.

Data-Level Access: Role-Based Filtering in RAG Systems

A retrieval-augmented generation (RAG) system that retrieves documents using its own service-level permissions can return content the asking user’s role was never granted to see, because the retrieval step checks the service’s access rather than the person’s. A support agent’s chat tool might hold broad read access to a document store so it can answer any question put to it, and every document that access covers becomes reachable through the chat interface regardless of what the person on the other end of that chat is cleared to read.

ARBITER: AI-Driven Filtering for Role-Based Access Control addresses that gap directly, providing role-based access control inside RAG pipelines by filtering retrieved content against the requester’s role before it reaches the generation step, rather than relying on the retrieval service’s blanket permission to decide what gets returned. That filtering step is what turns “the service can read this” back into “the person asking can read this,” restoring the distinction a role-unaware retrieval pipeline erases.

Model-Level Access: Protecting Model Weights Under ASL-3

Anthropic activated its AI Safety Level 3 (ASL-3) Deployment and Security Standards on May 22, 2025, alongside the launch of Claude Opus 4, adding internal security measures that make theft of the model’s weights substantially harder Claude Opus (Anthropic). The ASL-3 Security Standard governs who and what can reach the weights themselves: the model-layer equivalent of a role check, applied to the model as a protected resource rather than to the data it processes.

The accompanying ASL-3 Deployment Standard covers a narrowly targeted set of measures aimed at limiting misuse of the model for developing or acquiring chemical, biological, radiological, and nuclear (CBRN) weapons, and Anthropic describes the activation as a precautionary, provisional step taken because ruling out ASL-3-level risk for that model could not be done with the confidence earlier models allowed. Read alongside data-level filtering, ASL-3 is the clearest public example of access control applied at the model layer specifically: a role model does not stop at deciding who may query a model, it also has to decide who may reach the weights the model runs on.

One Role Model Across Tools, Data and Model

One role model should decide what an agent may do at all three layers, the tool it may call, the data it may retrieve, and the model endpoint or weights a person may reach, rather than three separate systems each guessing at the state of the other two.

The NIST AI RMF Playbook’s Manage function, MANAGE 1 treats AI risks identified through mapping and measurement as things to be prioritized, responded to, and managed together, which is exactly the posture a split control model works against: a data-layer filter that does not know what the tool-layer role already permitted, or a model-access rule set independently of both, produces gaps at the seams rather than at any single layer’s design. Tying tool access, data filtering, and model-weight protection back to the same role assignment closes those seams, because a single accountable decision, this role may reach this tool, this data, and this model, replaces three separate teams each defending their own layer without visibility into what the others allow.

Does the Vector Database Need Its Own Access Control?

RAG filtering as ARBITER implements it works after retrieval: the pipeline pulls candidate documents, then checks the requester’s role before passing anything to the generation step. A vector database can also enforce role-aware metadata filtering before retrieval runs, so a query embedding never matches against vectors the requester’s role could not see in the first place. The two are not redundant: a pre-retrieval filter at the vector store reduces what a compromised or misconfigured generation step could ever receive, while the post-retrieval check ARBITER performs catches whatever the vector store’s own filtering missed. Treating vector-store access as a distinct layer from the RAG pipeline that queries it closes a gap a single filtering step, however well built, cannot close alone.

Summary

Every mechanism above narrows the same starting point: a role assignment that, on its own, was never enough to bound what an autonomous agent does.

The Role Sets the Outer Bound

Ferraiolo and Kuhn’s non-discretionary principle put the permission decision with the organization, not the individual data owner, and that principle still holds for AI; but the AAC framework’s contextual evaluation, IGAC’s intent certificates, and the just-in-time frameworks from the Cloud Security Alliance, Microsoft, and Zylos AI all sit inside that same outer bound rather than replacing it. None of them can grant authority a role never assigned; each one narrows what a role-holding agent may actually reach at the moment it acts. That layering is the decision rule practitioners need: a role failure means the outer bound is wrong and needs a governance review, while a least-privilege failure means the narrowing inside that bound is too loose for the task at hand. Confusing the two sends a scoping problem to the governance board and a governance problem to the engineering backlog, and neither team can fix the other’s failure.

Missing Ownership Is Where Agent Governance Fails

Every technical layer in this guide, contextual evaluation, intent certificates, just-in-time grants, RAG filtering, model-weight protection, assumes a named owner already exists for the agent identity it protects, and that assumption is the one organizations skip first. An agent with a role, a short-lived certificate, and a filtered retrieval path can still run unaccountably if no human sponsor answers for what it does, because every enforcement mechanism above checks a request against a policy, not against a person who has to explain the policy’s existence. The sequence that actually holds up in practice runs ownership first: discover the agent, name its sponsor, then apply least privilege and layered enforcement on top of an identity someone is accountable for. Skip the ownership step and the technical controls still run, but the audit log they produce has nowhere to go: a record of what an agent did, with no one positioned to say whether it should have.

Anonymous. Counted, not tracked.

Where is your organisation with this right now?

What is the hardest part where you are?

agility at scale