What Is Least Exposure? Reading the Principle, the Gap It Closes and the Published Numbers Behind It

Chris Sowa · Founder, RedactSure
Published September 17, 2026 · Last updated September 26, 2026

Least Exposure is a security principle for AI agents: for each piece of work, the agent receives exactly the data the task requires and nothing more, enforced before any model reads the screen. Least privilege limits what an agent can do. Least Exposure limits what it can see. Term defined by RedactSure, September 2026.

Key findings

Least privilege, the identity industry’s standard answer to agent risk, governs actions and credentials. It does not govern the content of the screen an agent reads. An agent can satisfy least privilege in full and still hold every record it was shown.
The gap matters because an AI agent can be instructed by content it merely reads. Prompt injection is the first entry in the OWASP Top 10 for LLM Applications 2025, and OpenAI has said the problem may never be fully solved.
The demand side of the gap is measured. Microsoft and LinkedIn’s Work Trend Index reports that 78% of AI users bring their own AI tools to work. IBM’s Cost of a Data Breach Report 2025 records that one in five breaches now involves shadow AI, at about $670,000 of added cost per breach where it does.
Under Least Exposure, the values a task does not need are replaced with consistent stand-ins before any model reads the page. The enforcing mechanism is render-layer tokenization; the accountability model around it is Supervised Delegation.
A successful attack against an agent operating under Least Exposure exfiltrates tokens. There is nothing to sell and nothing to report.

Why does a new principle exist at all?

Every control in the classical security stack shares one assumption: a person with judgment decides what gets pasted, uploaded or sent. Permissions, encryption, DLP and the perimeter all finish their work before the screen renders, because the screen was the end of the line. A person read it, and the person could be trusted, trained or fired.

An AI agent reads the screen the way a person does and has no judgment. It sees whatever the person operating it can see. It can be instructed by content it merely reads, the attack class OWASP lists first for language models. And it can carry what it read beyond the application and every control around it.

The security industry’s first answer was least privilege: constrain what the agent may do. Okta, Zscaler and others have published detailed guidance on applying it to agents, and the guidance is sound as far as it reaches. It does not reach the screen. An agent with narrow permissions and a wide field of view still holds every record it was shown, and a single successful prompt injection is enough to move that record somewhere it should not go.

Least Exposure completes the pair. Where least privilege asks what this agent may do, Least Exposure asks what this agent should see for this piece of work.

What does the principle require?

The answer is task-specific. A claims agent needs the loss details and the policy terms, not the policyholder’s Social Security number. A budget agent needs the line items, not the vendor’s bank account. A student-records agent needs the attendance pattern, not the child’s name.

Under Least Exposure, the values a task does not need are replaced with consistent stand-ins before any model reads the page. The agent can reason and finish the work while the sensitive value never enters its context at all. The replacement is not deletion. A redacted record cannot be worked; a tokenized one can, because the stand-ins stay consistent within the task. The agent that sees USER_001 on a claims screen sees USER_001 again on the payment portal and can connect the two without ever holding the name.

Three consequences follow from stating the principle this way.

First, the decision about what an agent sees becomes explicit. Someone has to answer the question field by field for a given workflow, which is a policy decision a named person can review, approve and defend. In most agent deployments today that decision is never made at all. The agent sees whatever the screen shows.

Second, the principle is testable. For any given run, either the sensitive value entered the model’s context or it did not. This is a narrower and more checkable claim than the assurances that usually stand in for it, such as a vendor’s promise about retention or a policy document about acceptable use.

Third, the principle is independent of the model. It holds whether the agent runs on Claude, GPT, Gemini or an open-source model, because it is enforced before the model reads anything.

How does it differ from its neighbors?

Concept	What it governs	Relationship to Least Exposure
Least privilege	What an agent may do: which systems, which actions, which credentials	Sibling. Both are needed. Privilege limits action; exposure limits sight. An agent can satisfy least privilege and still see everything.
Data loss prevention, enterprise browsers	Where data may go: blocking a paste, an upload, a download, a copy	Governs the act, after the data is already on screen and already visible to any AI reading it. Least Exposure acts one step earlier, on what the screen contains.
Data privacy vaults, API tokenization	Data at rest and in pipelines that developers control	Same tokenization idea, applied where an integration exists. Least Exposure applies it to the screen, so it works in applications that were never integrated.
Model vendor contracts, acceptable-use policy	What the vendor promises to do with data it receives	Governs by assumption. Least Exposure governs by engineering: the model never receives the value, so the promise is never tested.
Screenshot-based computer-use agents, personal agent platforms	What the agent reads: the rendered page as an image, with the platform’s vault withholding only what the user deposited (passwords, payment cards)	Receives the whole picture: every value on the screen, every element the task never needed, anything an attacker placed there. Least Exposure governs the two things a screenshot cannot: which values the model receives and which parts of the screen it is handed at all.

The comparison with least privilege deserves one more sentence, because the two are so often collapsed into each other. Least privilege has decades of practice behind it and a mature tooling market. Least Exposure has neither, and does not need either to be applied: it is a question an organization can start asking about every agent workflow tomorrow, with or without any product. What should the AI see for this piece of work? A program that cannot answer has found its gap.

What enforces the principle?

A principle without a mechanism is a wish. The mechanism that enforces Least Exposure at the screen is render-layer tokenization: sensitive values are replaced with consistent tokens (USER_001, SSN_001, ACCT_001) at the moment a page renders, before any model reads it, and real values resolve only at approved destinations at the moment of action.

The agent does this work inside the RedactSure environment, a governed workspace where the organization’s applications render and the agent operates them. Owning the render is what allows the screen to be changed before the model sees it. Nothing is installed in the applications themselves and nothing runs on employees’ endpoints. Permissions never change. What changes is what the AI can see.

A named person confirms the exposure policy before the workflow runs, field by field, and approves every consequential action while it runs. That governance model is Supervised Delegation, and it answers the question that follows naturally from this one: once the agent’s sight is governed, who answers for its actions?

Does the principle govern how the agent sees the screen, not only what is on it?

Yes, and the distinction decides how much an agent is handed before any value is tokenized. An agent can be handed the picture or the fields. The picture is a screenshot: a rendering of the whole window, read as an image, carrying the record the task needs, the records beside it, the application’s menus and banners, and any text an attacker placed on the page, visible or not. The fields are the structured content of the page: this label, this value, this control, selected for this piece of work. The 2026 generation of computer-use and personal agents reads the picture, and their own documentation describes what their vaults protect (credentials and payment cards) and leaves the rest of the page read raw.

A screenshot violates Least Exposure by construction. It hands the model the maximum and relies on the model to ignore the rest, which is the reliance prompt injection exploits. Under the principle, two mechanisms limit what the model is handed. Render-layer tokenization governs which values it receives. Handing the agent the fields the work needs, rather than the picture, governs which parts of the screen it receives at all. The RedactSure environment does both: the agent operates the application through a structured reading of the rendered page, which is more efficient than reading pixels and hands the model a smaller surface than the whole window, with the identifiers already tokenized when it arrives. The residual surface is the free text inside the fields a task legitimately reads; narrower is not immune, and the token is what holds when an instruction gets through. The full walk is in What Does an AI Agent See When It Takes a Screenshot?

What happens when the attack succeeds?

Assume the worst case rather than arguing about its likelihood. A phishing email arrives in the agent’s queue with hidden instructions to send everything it knows. The agent complies, because prompt injection works and OWASP ranks it first among LLM application risks for a reason.

The attacker receives NAME_001 and SSN_001.

There is nothing to sell and nothing to report. The agent was not made trustworthy; the data was made worthless to steal. This is the design property that separates Least Exposure from every control that tries to make the attack less likely. The attack is permitted to succeed, and succeeds at nothing.

Security architectures are usually evaluated by their hardest question. For agents, the hardest question is what a perfect prompt injection gets. Under Least Exposure the answer is tokens, and the answer holds without any claim about the model’s alignment, the vendor’s contract or the filter’s accuracy.

How does the principle map to existing law?

Least Exposure is data minimization applied to a new reader. Data minimization is a legal principle about collecting and retaining only what is necessary, and versions of it already bind most regulated records. The minimum necessary standard at 45 CFR 164.502(b) requires reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose. FERPA’s school-official provisions condition disclosure of student records on legitimate educational interests and direct control. Card-network rules scope systems by whether they touch cardholder data.

None of these regimes was written with an AI agent in mind, and none of them needs to be rewritten for the principle to apply. Each already asks the organization to limit what a party sees to what the task requires. Least Exposure is the operating form of that requirement once the party doing the reading is a model: enforced in real time, at the screen, for each task. It is the practical way to meet a data-minimization obligation once an AI is doing the reading, and it is measured in the same terms an auditor would use, by what entered the reader’s context and what did not.

What do the published numbers say about the alternative?

The alternative to a sanctioned path is not abstinence. It is unsanctioned use, and the record on that is now measured by three separate publishers.

Microsoft and LinkedIn’s Work Trend Index found 78% of AI users bringing their own AI tools to work. IBM’s Cost of a Data Breach Report 2025 found one in five breaches involving shadow AI, with about $670,000 of added cost per breach where it appears. Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027, with weak risk controls among the causes it names.

Read together, the three numbers describe one situation. Employees are already using AI on work data, mostly outside sanctioned channels. Where that unsanctioned use intersects a breach, it makes the breach more expensive. And the sanctioned projects that would replace it are being canceled, in large part because they cannot answer the security questions this page has been describing. A ban produces invisibility, not safety. Least Exposure exists to give the organization a sanctioned path that survives those questions, which is the only thing that has ever reduced shadow AI.

One claim, two architectures: a worked example

Abstractions hide the difference, so walk one file through both designs.

A water-damage claim arrives. The adjuster delegates the intake work to an agent: assemble the file, verify coverage, pull the loss history, check the weather record for the loss date, price the estimate, draft the proof of loss.

In the common architecture, the agent reads the claims screen as rendered. Its context now holds the claimant’s name, address, date of birth, Social Security number, policy number, bank details from a prior payment, and the medical notes attached after the claimant mentioned a fall. The agent uses almost none of this. The name appears in the draft letter; the rest simply sits in context because it was on the screen. Every downstream system the model touches, every log that captures prompts, every vendor subprocessor in the inference path is now part of the story a breach investigator would have to tell. And if any page the agent reads that day carries a hidden instruction, the context is the payload.

Under Least Exposure, the agent reads the same screen with the identifiers replaced: USER_001, SSN_001, ACCT_001, with the loss details, coverage terms and pricing left in clear because the task needs them. The work product is identical. The draft letter reads USER_001 until the adjuster approves the send, at which point the name resolves in the sent document. The context never held anything a breach investigator, a regulator or an extortionist would want. The difference between the two runs is invisible in the output and total in the exposure.

The example generalizes to any file: swap the claims screen for a patient account in a revenue-cycle queue or a student record in an attendance review and the two architectures split the same way. The work is carried by the structure of the record. The risk is carried by the identifiers. Least Exposure separates the two.

What does adopting the principle involve?

An organization can adopt Least Exposure as a review discipline before it deploys anything, and the discipline has three steps.

First, inventory the agent workflows, proposed and actual, and ask the question of each: what should the AI see for this piece of work? The workflows with no answer on file are the findings. Most organizations that run this exercise discover that nobody has ever enumerated what any agent can see, because every screen the operator could see was implicitly included.

Second, write the answer down per workflow, field by field: which values the task requires in clear, which are replaced. This document is the exposure policy, and it belongs in the same governance binder as the access reviews. It is short, concrete and reviewable, which distinguishes it from most AI governance artifacts.

Third, enforce it at the layer where the reading happens. Policy without enforcement decays into aspiration; the enforcing mechanism at the screen is render-layer tokenization, and the person who confirms the policy and answers for the workflow is defined by Supervised Delegation.

Security teams already run this exact pattern for access: inventory, policy, enforcement, review. Least Exposure asks nothing methodologically new. It asks the familiar discipline be pointed at a question nobody was asking, because until agents arrived, no reader without judgment had ever held the screen.

What does the adjacent literature cover, and what does it leave open?

The least-privilege-for-agents literature is worth reading closely rather than dismissing, because its own reasoning arrives at the door Least Exposure walks through.

Okta’s guidance treats agents as a new class of identity: give each agent its own credentials, scope them narrowly, rotate them, review them. Zscaler’s treatment extends the same discipline to assistants and adds segmentation, so a compromised agent reaches less. Both are correct, and both stay inside the identity frame: the unit of control is the credential, and the question is what the credential opens.

Read either piece while holding one fact in mind: an agent does its damage with what it has read, not only with what it can open. The OWASP Top 10 for LLM Applications makes the point structurally. Its first-ranked risk, prompt injection, turns the agent’s reading into the attack surface. Its second-ranked risk, sensitive information disclosure, is about models revealing what entered their context. Neither risk is reduced by narrowing credentials, because both operate on content the agent was legitimately shown. The identity literature secures the doors. The content walks out through the agent’s memory of the room.

The same open edge appears in the data-side literature. Data privacy vaults tokenize what flows through integrated pipelines, and their own documentation scopes the protection to those integrations. The applications an agent works from the screen, the ERP, the claims platform, the payer portal, the email client, were never integrated, which is exactly why screen-reading agents are attractive and exactly where the vault’s coverage ends.

None of this is a criticism of the adjacent work; the point runs the other way. Identity governance, segmentation and pipeline tokenization are each necessary, each mature, and each silent on the same question: what is in front of the agent’s eyes for this task? A principle was missing at that spot. Least Exposure is the name for it.

What the record shows

Least Exposure is the principle that an AI agent should see exactly the data a task requires and nothing more, enforced before any model reads the screen. It completes least privilege rather than replacing it: privilege limits action, exposure limits sight, and an agent program needs both answers on file. The published numbers describe the cost of leaving the question unasked. 78% of AI users bring their own tools to work, one in five breaches now involves shadow AI at about $670,000 of added cost, and over 40% of agentic projects are projected to be canceled by 2027 with weak risk controls among the causes. The principle can be adopted as a review question today, workflow by workflow, and enforced at the screen by render-layer tokenization, with a named person confirming the policy and approving consequential actions under Supervised Delegation. Under that pairing, the hardest attack in the current literature succeeds and collects tokens. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.

Frequently asked questions

Is Least Exposure the same as data minimization?

It is data minimization applied to a new reader. Data minimization is a legal principle about collecting and retaining only what is necessary. Least Exposure is an operating principle about what an AI agent is shown during a task, enforced in real time at the screen. It is aligned with the data-minimization requirements that privacy regulation places on protected information.

Does it break the agent?

No. The agent works with consistent tokens, so it can still reason about the record, compare it across systems, draft a response and queue an action. The only thing it cannot do is reproduce the sensitive value, which is the point. Real values resolve at approved destinations when a named person approves the action.

Does it apply to an agent we already run?

Only if that agent does its work inside the RedactSure environment. Least Exposure is enforced at the render, so an agent that reads its own screen elsewhere, a computer-use agent on a hosted Windows machine for instance, is shown whatever that screen contains. The workflow moves into the environment; the applications and the permissions stay exactly where they are.

Why not just block AI from sensitive systems?

Because a ban produces invisibility, not safety. 78% of AI users bring their own AI tools to work, and one in five data breaches now involves shadow AI. The work does not stop when it is banned; it moves to personal accounts and phones where nothing is logged.

Who decides what the agent should see?

A named person who is accountable for the work. That person grants the access under their own existing permissions, chooses the applications, confirms the tokenization policy and approves every payment, submission or record change. The person who delegates the work is accountable for the AI that performs it. RedactSure calls the resulting model Accountable AI and the mechanism Supervised Delegation.

Is least privilege still necessary under Least Exposure?

Yes. The two are siblings, and each covers a failure the other does not. Least privilege stops an agent from taking actions it was never authorized to take. Least Exposure stops an agent from holding data its task never required. An agent program needs an answer to both questions.

Can the principle be adopted without buying anything?

The question can. What should the AI see for this piece of work is a review question any security team can add to its agent approvals today, and the workflows that cannot answer it are the ones to look at hardest. Enforcing the answer at the screen requires a mechanism; the one RedactSure builds is render-layer tokenization.

Does Least Exposure apply to chatbots and RAG systems, or only to agents?

The principle applies to any system that puts records in front of a model; the urgency differs. A retrieval pipeline is built by developers who can apply pipeline tokenization, and a chat interface exposes what a person chooses to paste. An agent reads whole screens on its own, at scale, which is why the screen is where the principle bites hardest.

Doesn’t the agent need real values to reason well?

For the workflows measured so far, no. Reasoning runs on structure: amounts, dates, codes, histories, relationships between records. Those stay in clear or stay consistent as tokens. What the agent loses is the ability to reproduce identifiers, which no legitimate task step has required; the steps that need real values are exactly the consequential actions where a person approves and the value resolves at the destination.

How does an organization know the policy is being enforced?

From the record. Every screen the agent read is logged as it was shown to the model, tokens included, and the log exports to the SIEM. Enforcement is checkable per run, which makes the exposure policy one of the few AI governance documents whose implementation can be audited directly.

Is an agent that reads a screenshot compatible with Least Exposure?

No. A screenshot hands the model everything the window renders, whether or not the task needs it, so the exposure decision was never made. An agent can satisfy the principle only when the environment decides which parts of the screen it is handed and replaces the values the task does not need before the model reads them. Structured readings such as an accessibility tree are easier to govern than an image, but a full tree carries the same content; the surface becomes smaller when a policy, confirmed by the person who owns the workflow, decides what the task receives.

What Is Render-Layer Tokenization? · What Is the PII Wall? · What Is Supervised Delegation? · What Does an AI Agent See When It Takes a Screenshot? · On the RedactSure blog: Your AI Doesn’t Need to Know Who You Are

Sources

Standards and regulation

OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
U.S. Department of Health and Human Services, Minimum Necessary Requirement, 45 CFR 164.502(b). https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html
Family Educational Rights and Privacy Act regulations, 34 CFR Part 99. https://www.ecfr.gov/current/title-34/subtitle-A/part-99

Research and industry data

Microsoft and LinkedIn, Work Trend Index, “AI at Work Is Here. Now Comes the Hard Part.” https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part
IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach
Gartner, “Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure” (May 2026). https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure

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
Palo Alto Networks, “Prisma Browser: Last-Mile Data Protection for the AI Era.” https://www.paloaltonetworks.com/sase/prisma-browser-data-protection

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 (render-layer tokenization, supervised delegation, setup confirmations, task-level policy) 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 else

About 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.