Explainer · By Chris Sowa · Published
Last updated
What Is AI Agent Data Reach and How Do You Map Everything an Agent Can Access?
AI agent data reach is the total set of records an agent could obtain through every path it holds: permissions, connectors, screens, retrieval, and other agents. It is mapped by inventorying the paths, sampling what the model received, and testing with planted instructions. An organization that maps only permissions understates reach and governs a smaller agent than it runs.

AI agent data reach is the total set of records an agent could obtain through every path it holds: permissions, connectors, screens, retrieval, and other agents. It is mapped by inventorying the paths, sampling what the model received, and testing with planted instructions. An organization that maps only permissions understates reach and governs a smaller agent than it runs. The question matters because the paths compound: a login opens a session, the session renders screens full of fields the task never asked for, a connector returns a whole record, a search returns documents nobody assigned, and a second agent passes along what it found. The union is reach, and it is the number a security team accepts when it approves the agent. The principle that sets the ceiling 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
- Reach is wider than permissions because an agent inherits a legitimate session and the content that session renders; zero trust guidance treats every access as a decision about a specific resource, not a standing grant, which is the gap a permission inventory cannot close on its own (NIST, 2020).
- OWASP names Sensitive Information Disclosure as LLM02 in its 2025 Top 10 and Excessive Agency as LLM06, the two failures that reach turns into when an agent reads more than it should and can act on what it read (OWASP, 2025; OWASP, 2025).
- Retrieval and tool outputs are a reach path an attacker can steer: indirect prompt injection places instructions in content the agent reads, so a page, an email or a database field can redirect the agent toward records the task never named (Greshake et al., 2023; OWASP, 2025).
- Consumer and enterprise agents now ship with large connector catalogs; OpenAI's dots can connect to more than 4,000 apps through plugins, each one a path into records the agent could obtain (The Next Web, 2026).
- Executives expect reach to grow: 38 percent expect agents to access data from across the organization within three years, and 29 percent expect agents to access functions in third-party systems in the same period (Accenture, 2025).
- Once data is inside a model's context, tracking where it flows is a research problem; information-flow tracking through LLM queries is proposed in peer-reviewed work as a way to follow it, which is why keeping records out of context is the simpler control (Siddiqui et al., 2025).
How is data reach different from data access?
Data access describes the paths an agent has been given and how much each one can return. A companion page, What Is AI Agent Data Access?, works through those paths and the quantity of enterprise data behind them. Data reach is the sum. It is the full set of records an agent could obtain if every path it holds were followed to its end, including paths the organization did not think of as data paths when it granted them.
The distinction is the one an auditor draws between an entitlement and an exposure. An entitlement is a line in a permission report: this account may open the claims module. An exposure is what that line produces: the module renders a claimant's name, address, date of birth, policy number and the adjuster's notes on every screen, and the agent reads all of it to find the one field the task needed. Access is the entitlement. Reach is the exposure, summed across every entitlement, connector, search and handoff.
Reach also includes records the agent can obtain without any entitlement of its own. An agent working through a browser inherits the user's session, so its reach is at least the user's. A connector to a finance system reaches whatever its API returns, often the whole object. A retrieval tool reaches whatever the index returns for the model's query. An agent that receives output from another agent reaches whatever that agent reached. None of those appear in a permission report as records; they appear as capabilities.
The two numbers are also governed by different people. Access is granted by an identity team at provisioning time. Reach is produced at runtime by the applications the agent opens, the queries it runs and the content it encounters. A review that signs off on access has signed off on the inputs to reach, not on reach itself.
Which paths make up an agent's reach?
Five paths recur, and each one has a different owner, a different unit of data and a different way of being wider than it looks.
| Path | What grants it | Unit the agent receives | Why reach exceeds the grant |
|---|---|---|---|
| Permissions and sessions | Identity team, or the user whose session the agent inherits | Everything the role or session may open | A role is scoped per application, not per task; the agent reads all of it |
| Connectors and APIs | Application admin, plugin catalog | The object the API returns | Returns the whole record when the task needed a few fields |
| Screens | Whatever the application renders | The rendered page, in full | Fields, notes and neighboring records the task never asked for |
| Retrieval and search | Index configuration | Every matching document | Query breadth, not task scope, decides the result |
| Other agents | Orchestration design | The other agent's output | Carries that agent's reach into this one |
Permissions and sessions are the path most organizations already inventory, because identity tooling exists to do it; What Is AI Agent Least Privilege? explains why a passing review still leaves an agent able to read a full record. Connectors are the fastest-growing path: Meta's Muse for Small Business ships with connectors to Shopify, Stripe, QuickBooks, Slack and more than a dozen other services, and OpenAI's dots claim more than 4,000 apps through plugins (TechCrunch, 2026; The Next Web, 2026). A companion page asks whether API connectors give an agent more data than the task needs, and the answer is yes, because a connector returns what the API returns.
Screens are the path least often counted and the one with the widest unit. Anthropic's guidance for Claude in Chrome states that the extension takes screenshots of the active tab and that all visible information, personal data included, becomes part of the context (Claude Help Center, 2026). OpenAI's documentation for dots describes the model seeing webpage text and document content within connected apps, the page in full (OpenAI, 2026). Meta's write-up of Muse's design says the agent reads the page in full (Meta AI Research, 2026). Three vendors, one unit: the whole screen.
Retrieval returns what matches the query the model wrote, not what the task assigned. Multi-agent designs pass outputs between agents, and Microsoft's taxonomy of failure modes in agentic systems catalogs the ways those handoffs go wrong (Microsoft AI Red Team, 2025).
Why does reach exceed what the permission inventory shows?
Four mechanisms widen reach past the inventory, and each one operates at runtime, after the review is over.
The first is inheritance. An agent inside a person's session holds that person's entitlements for the run, and those were set for a job, not for one task. NIST's zero trust architecture frames every access as a per-request decision about a specific resource (NIST, 2020). A session grant is the opposite: one decision, at login, covering every screen the application will render.
The second is rendering. Applications show people context: the full customer record on the case page, the adjuster's notes beside the reserve, the student's household beside the grade. A companion page describes what an agent sees when it takes a screenshot: everything on the page. No permission report lists rendered fields.
The third is steering. The content an agent reads can contain instructions. Greshake and colleagues showed that instructions placed in web pages, emails and retrieved documents can redirect an LLM-integrated application, a pattern OWASP lists first in its 2025 Top 10 (Greshake et al., 2023; OWASP, 2025). An injected instruction can send the agent to open a record, run a search or call a connector the task never named, so reach under attack is the full set reachable through every path. What Is AI Agent Prompt Injection? covers the attack; the point here is that injection converts potential reach into actual reach.
The fourth is retention. Screens, transcripts and traces kept for debugging are copies of what the agent reached, each a new store with its own access list. Peer-reviewed work on information-flow tracking through LLM queries treats the model as one component in a larger system and tracks labels through it because, once data is in context, where it goes next is hard to know (Siddiqui et al., 2025). The smallest reach map is the one where records never entered context.
Accenture's Technology Vision reports 38 percent of executives expecting agents to access data from across the organization within three years and 32 percent expecting cross-organization workflow automation in the same period (Accenture, 2025). Reach unmapped today is unmapped at a larger scale next year.
How do you map an agent's data reach?
Three methods, in order, each catching what the one before it cannot. The step-by-step procedure is in How to Map All the Data an AI Agent Can Reach; what follows is what each method is for and what it misses.
| Method | What it produces | What it catches | What it misses |
|---|---|---|---|
| Path inventory | A list of every grant, connector, index and agent handoff | The shape of reach: which systems and which objects | What each path renders in practice |
| Sampling | Real screens and responses as the model received them | The unit of reach: fields, notes, neighbors on each screen | Paths the sampled tasks did not exercise |
| Testing | Runs with planted instructions and out-of-scope prompts | Reach under steering: where the agent goes when told to | Attacks the test author did not think of |
The path inventory starts with the identity report and goes further: for each agent, the accounts and sessions it uses, the connectors and plugins enabled for it, the retrieval indexes it may query and the other agents that feed it or receive from it, each with the owner who granted it and the object or screen set it returns. The inventory is the only method that produces a complete list of paths and the one that tells the least about any path, because it records capability rather than content.
Sampling fills that gap. Run a set of real tasks and capture what the model received at each step: the screen as rendered, the connector response as returned, the retrieval result as indexed. Count the fields that reached the model as real values against the fields the task needed, per screen. What Is AI Agent Data Security? recommends asking a vendor for the same artifact, one real screen as the model received it. Sampling turns a list of systems into a list of records and fields, which is what reach is made of.
Testing covers the paths normal tasks never exercise. Place an instruction in a document, an email or a web page the agent will read, directing it toward a record, a search or a connector outside the task, and observe what it does. Bhagwatkar and colleagues found public agent-security benchmarks weak, and found that firewalls which strip unnecessary data at the tool boundary reach near-zero attack success on them, which says both that testing is necessary and that a clean benchmark result is not a clean estate (Bhagwatkar et al., 2026). A test that succeeds has measured reach under steering. A test that fails has only measured the test.
The map is finished when every path has at least one sample and one test against it, written per task rather than per agent. Gartner's finding that uniform governance across agents leads to failure applies: two agents with the same account can have different reach, because they run different tasks across different screens (Gartner, 2026).
What should an organization do with the map?
A reach map has one purpose: to shrink the distance between what the agent could obtain and what the task requires. Three moves follow from it.
The first is to remove paths no task uses: connectors enabled by default, indexes added for a pilot that ended, session grants wider than any current workflow. Each is reach with no task behind it. McKinsey's State of AI 2026 found 62 percent of organizations experimenting with agents and 23 percent scaling them, a population of pilots whose paths outlive their purpose (CX Today, 2026).
The second is to change what the remaining paths deliver, per task, before the model reads it. Permissions do not change; what changes is what the AI can see. The sampling results say which fields on which screens the task needed, and that list is a policy; What Should the AI See for This Piece of Work? frames the question. Identifiers the task does not need become tokens, so the model receives SSN_001 and ACCT_001 in place of the real values, and reach through the screen collapses to what the policy allows. The page on data minimization extends the same decision to what is kept and sent on.
The third is to bound what reach can be turned into. OWASP's Excessive Agency entry describes the failure where an agent with broad reach also holds broad authority to act (OWASP, 2025). Reach that ends in a read is an exposure; reach that ends in a payment, a submission or a record change is an incident. A named person approving every consequential action means steered reach, however wide, stops before the action. The test results say which actions an injected instruction tried to trigger, and those are the actions that need a name on them.
A map drawn once is a snapshot. Paths are added by application admins, plugin catalogs and index owners without a security review, which is why the NIST AI Risk Management Framework places mapping inside a cycle of Govern, Map, Measure and Manage (NIST, 2023). The trigger for a re-map is any change to the inventory: a new connector, index, agent in the chain, or task on the same agent.
Where does RedactSure sit?
RedactSure's design shrinks reach at the widest path, the screen, and records what remained. Every sensitive value chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, through render-layer tokenization, so the model receives the task's fields with identifiers as tokens. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy before the run and approves every payment, submission and record change while it runs, under Supervised Delegation. Real values resolve only at approved destinations at the moment of an approved action. A prompt injection that succeeds collects tokens, and the consequential action still stops for a named person.
The AI Control Record holds every screen as tokens, every action and every approval with a name, exported to the customer's own SIEM, so what the model received is on the record for every run. The environment needs no per-application integration and no change to user permissions, is model agnostic, and runs in the customer's cloud with keys the customer holds. 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 framework publications read as of October 13, 2026: NIST's Zero Trust Architecture, SP 800-207 (2020, official guidance) and AI Risk Management Framework 1.0 (2023, official guidance); the OWASP Top 10 for LLM Applications 2025, entries LLM01, LLM02 and LLM06 (industry standard). Vendor statements about what agents read come from Anthropic's Claude in Chrome safety guidance, OpenAI's safety write-up for dots and Meta's design write-up for Muse (vendor documentation), with connector counts from press coverage of the September 29, 2026 launches (industry press). Research findings come from Greshake et al. (2023, preprint), Bhagwatkar et al. (2026, preprint), Siddiqui et al. (2025, peer-reviewed) and the Microsoft AI Red Team taxonomy (2025, whitepaper). Survey figures are from Accenture's Technology Vision 2025 and McKinsey's State of AI 2026 as reported by CX Today.
No product was tested, no agent was run against a live estate, no reach map of any organization was produced, and no incident data is reported. Connector counts and reading behavior are as the vendors and press described them on the date of review; features change, and the page carries its date. The claims module, finance system and student record 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 reach map satisfies an organization's obligations under HIPAA, FERPA, PCI DSS, GLBA, the Privacy Act or any other regime is a determination for its counsel, assessor and security and compliance officers, not for the page. The frameworks cited set out practices; they do not certify a map or a product.
What the record shows
Data reach is the union of everything an agent could obtain through every path it holds, and most of it is produced at runtime by screens, connectors, searches and handoffs rather than granted at provisioning. A permission inventory is the first input to the map and the smallest number in it. The alternative to mapping is to approve the agent on its entitlements and discover its reach from an incident, when an injected instruction or a mistaken query shows where the agent could always have gone. The test a reader can apply is one task: list every path the agent holds, capture one screen or response from each as the model received it, and count the fields the task needed against the fields it got. The gap is the reach to remove.
Frequently asked questions
Is data reach the same as data access?
No. Data access is the set of paths an agent holds and how much each can return; data reach is the total set of records those paths could produce, followed to their end: screens rendered inside a session, whole objects returned by connectors, documents returned by retrieval and outputs passed from other agents. Access is granted at provisioning. Reach is produced at runtime and is almost always larger.
Why is a permission review not enough to know an agent's reach?
Because a permission describes a capability, not the content it returns. A role that may open the claims module says nothing about the fields the module renders on each screen, and an inherited user session carries the person's whole entitlement set into a one-task run. Reach is found by sampling what the model received and testing where the agent goes when steered, not by reading the permission report.
Which path usually contributes the most reach?
The screen. Vendor documentation for Claude in Chrome, OpenAI's dots and Meta's Muse each describes the agent reading the page in full, and application screens show people context: the whole record, the notes, the neighboring cases. Connectors come second, because an API returns the whole object. Both exceed the task's needs by design rather than by error.
How do you test reach rather than list it?
Place an instruction in content the agent will read, directing it toward a record, search or connector outside the task, and observe what it does. The result measures reach under steering, which is the reach that matters in an incident. A clean result on a public benchmark is not the same as a clean result in an estate; research on those benchmarks found them weak, so tests should use the organization's own paths.
Does mapping reach mean changing user permissions?
No. Permissions stay exactly as they are. The map shows which fields on which screens each task needs, and that list becomes a per-task policy about what the AI can see. Identifiers the task does not need are replaced with tokens before the model reads the screen, which shrinks reach without touching the entitlements the application relies on.
How often should a reach map be redone?
Whenever a path changes: a connector is enabled, an index is added, an agent is chained to another, or a new task is assigned to an existing agent. Each of those widens reach without any change to the permission report, so the inventory of paths, not the identity system, is the trigger. Frameworks such as the NIST AI RMF place mapping inside a continuing cycle for this reason.
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










