Data Report · RedactSure Research
Does Least Privilege Cover What an AI Agent Can See? Reading the Identity Literature Against the Sight Question
No. Least privilege governs what an agent may do: which systems it can enter, which actions it can take, which credentials it holds. It does not govern the content of the screens the agent reads inside its permitted systems, and an agent can satisfy least privilege completely while holding every record it was shown. The identity industry’s own guidance, read closely, stays inside that boundary. The sight question needs its own principle, Least Exposure: for each piece of work, the agent sees exactly the data the task requires and nothing more. The two are siblings, both necessary, neither sufficient, and an agent security program needs a written answer to both. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Key findings
- The least-privilege-for-agents literature is real and sound: Okta, Zscaler and others treat agents as a new identity class needing scoped credentials, segmentation and review. Everything in it governs reach; none of it governs content.
- The gap is visible in OWASP’s own ranking: the Top 10 for LLM Applications leads with prompt injection and sensitive information disclosure, two risks that operate on what the model read, not on what its credentials opened.
- A minimally privileged claims agent still reads names, Social Security numbers and bank details on every claim screen its narrow permissions legitimately open. The privilege model worked; the exposure happened anyway.
- The two principles fail differently, and the failure modes sort cleanly: actions the agent should not have taken are privilege failures; data the agent should not have held are exposure failures. Incident reviews that use the sort stop mislabeling exposure incidents as privilege gaps.
- The pairing is the complete answer to the two questions boards now ask: what can it reach (privilege) and what can it see (exposure), with Supervised Delegation answering the third, who answers for it.
What does least privilege actually promise?
The principle is one of security’s oldest and best: every actor gets the minimum access required for its function, granted deliberately, reviewed periodically, revoked on change. Applied to AI agents, as the identity vendors’ guidance applies it, the practice is recognizably the same discipline. Give each agent its own identity rather than a shared service account. Scope its credentials to the systems and actions its function requires. Segment so a compromised agent reaches less. Rotate, review, revoke.
All of it is worth doing, and none of it is this page’s target. The target is the sentence that quietly gets added when the discipline is sold as the answer to agent risk, because the promise of least privilege is precise: it bounds what an agent can do. The claims agent scoped to the claims platform cannot touch the HR system; the payment permissions can be withheld; the blast radius of a compromised credential is contained. Those are reach guarantees, and reach guarantees are what the mechanism can deliver.
What the mechanism cannot address is the content of the reach. The claims agent’s narrow, correct, reviewed permission to the claims platform opens screens that contain claimant identities, medical detail and bank accounts, because that is what claim screens contain. The agent reads them, holds them in context, and can be instructed by anything else it reads to send them elsewhere. Nothing in the credential model touches any step of that sentence.
Where does the identity frame run out?
Read the vendors’ own guidance with the sight question in hand and the boundary is visible in what goes unmentioned. The recommendations enumerate systems, scopes, tokens, lifetimes and reviews; screens and records appear only as the things behind the permission, never as governed quantities themselves. This is not an oversight in the guidance; it is the frame’s edge. Identity governance is about who may open which doors. It has never claimed to govern what is in the rooms.
OWASP’s risk ranking marks the same edge from the attack side. The Top 10 for LLM Applications leads with prompt injection, an attack that turns the agent’s reading into the control channel, and follows with sensitive information disclosure, the leaking of what entered model context. Neither risk is mitigated by narrowing credentials, because both operate downstream of a legitimate read. An agent with perfect privilege hygiene presents exactly the same surface to both: whatever its permitted screens contained.
The practical consequence shows up in security reviews that this series has walked elsewhere: the stalled projects frequently arrive with credible privilege stories, agent identities, scoped access, segmentation diagrams, and still die, because the reviewer’s question was not what can it reach. It was what does it see when it gets there, and the privilege story has no answer to it.
How do the two principles divide the work?
| Least privilege | Least Exposure | |
|---|---|---|
| Governs | Actions, systems, credentials: what the agent may do | Screen content: what the agent may see |
| Unit of decision | The permission grant | The field, per workflow |
| Decided by | Identity governance, access reviews | The named workflow owner, in the exposure policy |
| Enforced at | Authentication and authorization | The render, before any model reads, via render-layer tokenization |
| Failure it prevents | The agent acting where it should not | The agent holding what it never needed |
| Failure it cannot prevent | Exposure through legitimately opened screens | Actions within legitimate sight (the approval gate’s job) |
| Attack it blunts | Credential compromise, lateral movement | Prompt-injection exfiltration: a perfect attack collects tokens |
The last row is where the pairing earns its keep in an adversarial review. Against a compromised credential, privilege bounds the reach. Against a compromised read, the injection attack the ecosystem has not solved, only exposure bounds the loss, because the attack operates entirely inside the agent’s legitimate reach. The full walk of that attack, succeeding completely and collecting tokens, is in What Does a Prompt-Injection Attack Get From an Agent That Sees Only Tokens?
The sort also cleans up incident language. Post-incident reviews that ask only the privilege question routinely misfile exposure incidents: the agent had exactly the access it was supposed to have, so the finding becomes vague process language, when the precise finding is that no exposure decision existed for the workflow. Naming the two principles gives the review its second column.
An incident review, run with both columns
The two-principle sort earns its place in the worst week, so run it against a plausible incident twice, once with the vocabulary most reviews have and once with both columns.
The inc
Treat them as the two halves of one intake question for every agent workflow, existing and proposed.
The privilege half runs on the identity toolkit the organization already owns: what identity does this agent have, what can it reach, who granted it, when was it reviewed. The vendors’ guidance covers this half well, and a program behind on it should catch up regardless of anything on this page.
The exposure half runs on the newer discipline: what should this agent see for this piece of work, answered field by field by the workflow’s named owner, enforced at the render, verified in run logs. The method is the subject of What Should the AI See for This Piece of Work?, and its cost of adoption is a review question and a one-page policy per workflow.
A program with strong answers to one half and none to the other has the specific gap this page names, and the direction of the gap is predictable: privilege answers exist, because the identity infrastructure predates agents, and exposure answers do not, because until agents arrived no reader without judgment ever held the screen. Closing that asymmetry is the work, and it starts with declining to let the first principle’s maturity stand in for the second’s absence.
Three quantities, one control surface
The pairing this page argues for is really part of a triple, and setting all three side by side is the cleanest way to see what a complete agent control surface requires, because each quantity has its own owner, its own enforcement point and its own failure mode.
Reach is what the agent may do: systems, actions, credentials. It is owned by identity governance, enforced at authentication and authorization, and it fails when an agent acts where it should not. The mature toolkit lives here, and the identity vendors’ agent guidance is its current edge.
Sight is what the agent may see: the content of the screens its reach opens. It is owned by the workflow’s named person through the exposure policy, enforced at the render before any model reads, and it fails when an agent holds records its task never required. This is the quantity least privilege does not cover and Least Exposure does, and it is the newest of the three because no reader without judgment ever held a screen until agents.
Consequence is what the agent may finalize: payments, submissions, record changes, anything leaving the organization. It is owned by the same named person through the approval gate, enforced by policy at the moment of action, and it fails when an agent finalizes something no person authorized. Supervised Delegation governs it, policy-triggered rather than model-triggered.
| Quantity | Question | Owner | Enforced at | Fails when |
|---|---|---|---|---|
| Reach | What may it do? | Identity governance | Authn / authz | It acts where it should not |
| Sight | What may it see? | Workflow owner (exposure policy) | The render | It holds what it never needed |
| Consequence | What may it finalize? | Workflow owner (approval gate) | The action | It finalizes what no one authorized |
Read down the failure column and the completeness argument makes itself: an agent program answering only the reach question has left two of its three failure modes uncovered, and the two it left are the ones the highest-ranked AI risks and the board’s hardest questions actually target. A security review that walks all three columns for a proposed workflow is doing the complete job; one that walks only the first is doing the job the identity infrastructure made easy and calling it finished.
What the record shows
Least privilege does not cover what an AI agent can see. It governs reach, deliberately and well: systems, actions, credentials, reviewed and scoped. Sight is a different quantity, ungoverned by any credential, and the identity literature’s own texts stay silent on it because it sits outside their frame. The risks OWASP ranks highest operate on sight, through what the model read and held, and an agent with immaculate privilege hygiene presents that surface undiminished. The complete program pairs the principles: least privilege bounding what the agent may do, Least Exposure bounding what it may see, Supervised Delegation naming who answers for it. Two questions, two written answers, per workflow. An organization holding only the first should assume the second’s answer is currently everything on the screen, because it is. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.
Frequently asked questions
Is Least Exposure just least privilege applied to data?
No. Data-level privilege, row and column permissions, entitlements, governs which records an identity may retrieve from a system. Exposure governs what appears in front of the model within screens the identity legitimately opens, task by task. An agent with correct data entitlements still reads full screens; the principles operate at different layers.
Our IAM roadmap includes agent identities and fine-grained scopes. Does finishing it close the gap?
It closes the privilege half, which is worth finishing. The exposure half is untouched by any scope granularity, because the finest-grained permission still opens a screen whose content no permission system inspects.
Which principle should a program implement first?
They are not sequential; the intake question carries both halves, and most organizations are already far ahead on privilege. The practical first step is adding the exposure question to the review template, which costs a sentence.
Do the identity vendors dispute any of this?
Their published guidance neither claims sight coverage nor addresses it; the boundary is drawn by silence rather than disagreement. The adjacent-literature reading in What Is Least Exposure? walks the texts directly.
How does an auditor test each principle?
Privilege: the access review trail, scope definitions, revocation records, the mature toolkit. Exposure: the signed field-level policy per workflow and the token-level run logs showing what the model received. The second test is newer and, once the artifacts exist, more direct.
Where does the approval gate fit between them?
The gate governs consequence, the third quantity: actions that move money, change records or leave the organization wait for a named person regardless of privilege or sight. The three together, reach, sight, consequence, are the complete control surface for an agent, and each has its own page in this series.
Related reading
What Is Least Exposure? · What Should the AI See for This Piece of Work? · What Does a Prompt-Injection Attack Get From an Agent That Sees Only Tokens? · On the RedactSure blog: The Two Gaps AI Agents Opened in Your Security Stack
Sources
Adjacent vendor literature
- Okta, “How to implement least privilege for AI agents.” https://www.okta.com/identity-101/how-to-implement-least-privilege-for-ai-agents/
- Zscaler, “How to Establish Least-Privilege for AI Agents and Assistants.” https://www.zscaler.com/blogs/product-insights/least-privilege-access-ai-agents-assistants
Standards
- OWASP, Top 10 for LLM Applications 2025, including LLM01 Prompt Injection and sensitive information disclosure. https://genai.owasp.org/llm-top-10/
- MIT Media Lab, “Authenticated Delegation and Authorized AI Agents” (2025). https://arxiv.org/abs/2501.09674
RedactSure documents
- RedactSure, “The Two Gaps AI Agents Opened in Your Security Stack” (2026). https://redactsure.com/blog/two-gaps-ai-agents-opened-in-your-security-stack/
- Product behavior described on this page reflects RedactSure’s current design.
Bring your hardest questions.
A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.
Book a security review Book a demo · Something elseAbout the author
Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first 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.