Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Access Control and Why Is Traditional IAM Not Always Enough?

AI agent access control is the set of decisions that governs which resources an agent may reach, what it is shown inside each resource, and what it may do there. Identity and access management settles the first decision only. Stop there and the agent opens the right records, reads all of them, and acts with nothing between reading and acting.

A task passes an access boundary and permission controls before reaching selected enterprise records.

AI agent access control is the set of decisions that governs which resources an agent may reach, what it is shown inside each resource, and what it may do there. Identity and access management settles the first decision only. Stop there and the agent opens the right records, reads all of them, and acts with nothing between reading and acting. The gap matters because an agent reads whole screens, carries what it read into later steps, and executes actions on its own initiative unless something stops it. IAM was built around a subject, a resource and a permission. The two questions it does not decide, what the agent is shown and what it may do, need their own controls, and the principle that organizes the first of them is Least Exposure: for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • NIST's zero trust architecture defines access as a per-request decision about a subject reaching a resource, evaluated continuously; it governs the connection to the resource, not what a subject is shown once inside (NIST, 2020).
  • OWASP lists Excessive Agency as LLM06 in its 2025 Top 10 for LLM Applications: an agent granted more functionality, more permissions or more autonomy than the task requires, which turns a manipulated or mistaken model into a harmful action (OWASP, 2025).
  • Microsoft's Copilot Studio documentation states that its access control for computer use "only prevents the model from taking actions on websites or applications that aren't in the allow list. It doesn't stop the model from opening them" (Microsoft, 2026).
  • Google's Agent Platform documentation describes Cloud IAM as "granular, least-privilege access control over what data an agent can query or manipulate," which is a statement about reach, while a separate Sensitive Data Protection service inspects model inputs and outputs (Google Cloud, 2026).
  • Anthropic's guidance for Claude in Chrome states that all visible information on the active tab, including personal data, becomes part of the model's context, and advises users to avoid opening the extension while viewing sensitive information (Anthropic, 2026).
  • Gartner forecast in May 2026 that applying uniform governance across AI agents will lead to enterprise agent failure, because agents differ in autonomy, scope and consequence (Gartner, 2026).

What does traditional IAM decide, and what does it leave open?

Identity and access management answers one question well: may this subject reach this resource? Zero trust sharpens the question without changing its shape. NIST SP 800-207 describes a policy decision point and a policy enforcement point that evaluate each request for access to a resource, using the subject's identity, the device, and the context of the request, and that re-evaluate as conditions change (NIST, 2020). The resource is the unit. A record system, an API, a file share, an application: each is something a subject is either granted or denied.

That model served well when the subject was a person or a service account with a narrow job. A person opening a claims system sees the claim, and training and supervision govern what happens next. A service account calling an API receives the fields the API returns and does what its code says. In both cases the decision to grant reach sat close enough to the decision about use that nobody needed to separate them.

An agent breaks that closeness in two places. First, it reads everything in front of it. Anthropic's guidance for Claude in Chrome states that all visible information on the active tab, including personal data, becomes part of the model's context (Anthropic, 2026). OpenAI's Dots documentation describes the model receiving webpage text and document content within connected apps (OpenAI, 2026). Granting reach to a screen is granting reach to every value on it, whether or not the task needed them. Second, the agent can act. It can submit a form, change a record, send a message or move money, and the model that chooses the action can be wrong or can be steered by content it read (Greshake et al., 2023). IAM can say the agent may open the vendor master. It cannot say the agent may see the invoice total but not the bank account number, or that the agent may prepare the payment but a named person must release it.

What are the three questions agent access control has to answer?

A complete definition names three questions and assigns each a control. They are listed in the order a run encounters them, because a later control cannot undo an earlier exposure.

Question Unit of decision Who or what decides today Where IAM reaches
May the agent reach this resource? Application, API, data store IAM, the identity provider, the cloud role Fully
What is the agent shown inside the resource? Field, value, screen region Usually nothing; the application renders the page in full Not at all
What may the agent do there? Action: read, prepare, submit, pay, change Usually the agent's own judgment, sometimes an allow list Partly, through coarse write permissions

The first question is IAM's, and the answer should be as narrow as the job allows: least privilege, temporary credentials and no long-lived keys on the workload (AWS, 2026). The second question is the one most programs skip. It asks, for this piece of work, which values the model should receive at all, and it has to be decided per task rather than per application, because the same screen serves many tasks with different needs. The third question is about action governance: which steps the agent may take alone and which stop for a person.

OWASP's LLM06 entry describes what happens when the third question goes unanswered. Excessive Agency arises from excessive functionality, excessive permissions or excessive autonomy, and the recommended mitigations include limiting the extensions an agent can call, limiting their permissions, and requiring human approval for high-impact actions (OWASP, 2025). The entry treats permissions and autonomy as separate properties: a correctly scoped permission does not make an autonomous action safe, because the permission does not know whether the action was right.

Why does a scoped identity still expose the whole screen?

Google's Agent Platform documentation describes Cloud IAM as providing "granular, least-privilege access control over what data an agent can query or manipulate," and separately describes a Sensitive Data Protection service that gives "continuous visibility into model inputs and outputs" (Google Cloud, 2026). IAM decides which data stores the agent's identity may query; the inspection service watches what flowed to and from the model afterward. Neither decides, before the model reads a record, which of its fields the task requires.

Microsoft's Copilot Studio documentation lets an administrator define the URLs and desktop applications the agent is limited to, and adds that this "only prevents the model from taking actions on websites or applications that aren't in the allow list. It doesn't stop the model from opening them" (Microsoft, 2026). The allow list governs action, which is the third question. It does not govern what the model sees when a page opens, which is the second.

The reason is structural. Permissions attach to a subject and a resource; a screen is rendered for a human reader and carries everything that reader is entitled to see. An agent working inside a legitimate user's session inherits that whole rendering. Research on information flow through language models treats this as a live problem: once data is in the model's context, tracking which inputs influenced which outputs requires propagating labels through every query (Siddiqui et al., 2025). A control that decides what enters the context in the first place avoids the tracking problem rather than solving it. Work on indirect prompt injection reaches the same shape from the attack side: the Tool-Input Firewall proposed by Bhagwatkar and colleagues strips unneeded data from what reaches a tool, since an attacker cannot exploit what was never delivered (Bhagwatkar et al., 2026).

This is why least privilege and agent access control are different subjects. Least privilege is a principle about the size of the grant. Agent access control is the full set of decisions, including the two no grant expresses.

What should decide what the agent may do?

OWASP's mitigations for Excessive Agency include requiring a human to approve high-impact actions and keeping that approval outside the model's control (OWASP, 2025). Microsoft's AI Red Team taxonomy of agent failure modes catalogs harmful steps taken through a mistaken plan, a manipulated instruction or an interaction between agents, and the cases do not depend on the agent holding a permission it should not have (Microsoft AI Red Team, 2025). The permission was legitimate. The action was wrong.

The vendors' own designs show where the control sits. OpenAI's Dots use Custom Rules to set what a dot may do on its own, what needs approval and what is forbidden, with a separate Auto-review system checking planned actions before execution; the documentation notes that Custom Rules cannot override mandatory confirmations (OpenAI, 2026). Meta's Muse design requires human approval before sensitive actions and routes every network egress through a separate Sentinel (Meta AI Research, 2026). In each case the vendor built a layer IAM does not provide, because the thing controlled is a step in a run, not a grant to a resource.

Three properties distinguish a usable action control from a nominal one. The approver must be a named person, not a model reviewing another model; MIT Technology Review describes stacked model-side defenses as a "Swiss cheese" of layers that each have holes (MIT Technology Review, 2026). The approval must be per action, not a standing allowance, because a standing "always allow" converts the control back into a permission. And the approval must be on the record, with the name, so the organization can later show who released each payment or change. Supervised Delegation is the name for an arrangement with all three: a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action.

How does agent access control fit a zero trust program?

Zero trust and agent access control are not in competition. SP 800-207 describes a program in which no implicit trust follows from network location, each access request is evaluated against policy, and the policy engine uses identity, device state and behavior as inputs (NIST, 2020). An agent fits that program as a subject: it should authenticate, its requests should be evaluated per resource, and its session should be monitored. What the program needs added is a second enforcement point that operates inside the granted session rather than at its edge.

The practical shape is an environment, owned by the organization, in which the agent works, with controls that operate during deployment rather than only at configuration, as the NIST AI Risk Management Framework's Manage function calls for (NIST, 2023). Inside such an environment, the policy decision point for exposure runs at the render layer and decides which values the model receives on each screen; the policy decision point for action runs at each consequential step and routes it to a named person. Both decisions are made per task, which answers Gartner's observation that uniform governance across agents fails: an agent reconciling invoices and an agent drafting a response to a parent need different exposure and approval points even when their IAM grants look alike (Gartner, 2026).

A reviewer can test for the second enforcement point with one request: for a single completed task, show the screen as the model received it, the policy that produced that view, and the name of the person who approved the step that changed a record. An IAM-only program can produce a role assignment and an application log, not the first or third artifact, because nothing in it made those decisions. The record that holds all three is what an AI Control Record is for.

Where does RedactSure sit?

RedactSure supplies the two decisions IAM leaves open, without changing the decision IAM already makes. User permissions stay exactly as they are; the agent works the organization's applications as rendered inside a governed environment, under the user's existing permissions, with no per-application integration. On the exposure question, render-layer tokenization replaces every identifier chosen by policy with a consistent token before any model reads the screen, so the model receives the task's fields with ACCT_001 and SSN_001 in place of real values, and real values resolve only at approved destinations at the moment of an approved action. On the action question, the Planner sets what the agent may do on each screen, a named person confirms that policy before the run, and that person approves every payment, submission and record change while it runs. Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's own SIEM. The environment runs in the customer's cloud with keys the customer holds and is model agnostic. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page is a definitional synthesis. It rests on standards and official guidance read as of October 13, 2026: NIST SP 800-207, Zero Trust Architecture (2020), the NIST AI Risk Management Framework 1.0 (2023), and the OWASP Top 10 for LLM Applications 2025 entries LLM01 and LLM06 (industry standard). It draws on vendor documentation from Microsoft (Copilot Studio computer use), Google Cloud (the Gemini Enterprise Agent Platform security write-up), OpenAI (Dots safety documentation), Anthropic (Claude in Chrome safety guidance), Meta (the Muse safety write-up) and AWS (IAM best practices), each cited as vendor documentation and quoted only for what it states. Peer-reviewed research and preprints on indirect prompt injection, information-flow analysis and agent failure modes supply the research context, and a Gartner press release and an MIT Technology Review essay supply the industry analysis.

No product was tested. No agent was run against any application, no permission model was audited, and no measurement of exposure or action rates is reported. Vendor documentation quoted here describes features as published on the date of reading; features change, and the page carries its date and is revised when the sources change. The claims system, vendor master and parent response examples describe kinds of work, not any organization; no customer or prospect is described. Statements about RedactSure are limited to the design facts the company publishes about itself.

Whether a given combination of IAM, exposure control and action control meets an organization's obligations is a determination for its counsel, its assessor and its security and compliance officers, who hold the policies and the risk tolerance it depends on. The standards cited set out practices; they do not certify any product.

What the record shows

IAM decides whether an agent may reach a resource, and it should go on deciding that as narrowly as the work allows. It does not decide what the agent is shown inside the resource or what it may do there. A program that treats the grant as the whole of access control has an agent reading every value on every screen it opens and choosing its own actions. The two missing decisions are made per task, at the render layer and at each consequential step, by a policy a named person confirmed. The test is one completed task: produce the screen as the model received it and the name of the person who approved the change. A role assignment answers neither.

Frequently asked questions

Is AI agent access control the same as giving the agent a least-privilege role?

No. A least-privilege role narrows the first decision, which resources the agent may reach. Agent access control also covers what the agent is shown inside each resource and which actions it may take there. A perfectly scoped role still opens a screen that renders every field, and still lets the agent choose its own next step.

Does zero trust cover AI agents?

Partly. NIST SP 800-207 treats access as a per-request decision about a subject reaching a resource, and an agent should be governed that way as a subject. Zero trust does not add an enforcement point inside the granted session that decides which values the model receives and which actions stop for a person. Agent access control adds that point without replacing the first.

If the agent uses the employee's own permissions, is the problem solved?

No. Using the employee's permissions keeps the first decision correct and keeps the record of who was responsible. It also hands the agent everything the employee is entitled to see, far more than any single task requires. The exposure decision still has to be made per task, before the model reads the screen, and the action decision still has to route consequential steps to a named person.

What is Excessive Agency and how does it relate to access control?

OWASP's LLM06 entry describes an agent with more functionality, permissions or autonomy than its task requires, so that a manipulated or mistaken model produces a harmful action. It maps to the third access control question, what the agent may do. OWASP's mitigations include limiting what the agent can call, limiting those permissions, and requiring human approval for high-impact actions, kept outside the model's control.

Can an allow list of applications control what the agent sees?

An allow list governs which applications the agent may act in. Microsoft's documentation for Copilot Studio computer use states that its access control prevents actions outside the allow list and does not stop the model from opening other sites. Inside an allowed application, the page renders in full. Controlling what the model sees requires a field-level decision made before the model reads the screen.

Who should approve an agent's consequential actions?

A named person, per action, on the record. A model reviewing another model is a model-side control with the same gaps as refusal, and a standing allowance turns the approval back into a permission. The organization needs to show, for each payment, submission or record change, which person released it, so the approval belongs in the run record, not in a setting.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.