Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does an AI Agent Need Access to Internal Company Data?

It needs access to the workflow, which is the screens, fields and actions a task runs through, and far less often to the raw values those fields hold. Check which values your agent actually read to complete one task, and whether access control was the only thing deciding what it received.

A restricted route connects a small set of task cards to an internal company records archive.

It needs access to the workflow, which is the screens, fields and actions a task runs through, and far less often to the raw values those fields hold. Check which values your agent actually read to complete one task, and whether access control was the only thing deciding what it received. The question is usually posed as a binary, grant access or withhold it, because that is how access has always been managed: an identity is given permission to a system, and the permission covers everything the system shows that identity. An agent that is going to approve purchase orders is given access to the procurement system, and from then on it can see every purchase order, every supplier, every price and every approver's name. The binary hides a distinction that matters more for agents than it ever did for people. Access control governs who can touch data. It says nothing about how the data flows during the execution of a task: which values the model read, which it carried into its reasoning, which it wrote into a tool call, which it used in a decision it was never asked to make. This page separates the two, describes what a workflow actually requires, examines the official guidance on agent adoption and data security, and sets out how an organization can tell the difference between an agent that has access and an agent that actually reached far more enterprise data than its task needed.

Key findings

  • Web agents built on GPT-4, Llama-3 and Claude are prone to inadvertent use of unnecessary sensitive information, which means that data an agent can see but does not need is data it will sometimes use (Zharmagambetov et al., 2025).
  • OWASP's LLM06:2025 entry on excessive agency identifies excessive permissions and excessive functionality as root causes of agent harm, and recommends limiting both to what the task requires (OWASP, 2025).
  • Joint guidance from CISA, the NSA, the FBI and international partners on AI data security treats the data used to operate AI systems as an asset to be secured through its lifecycle, not only at the point of access (CISA, 2025).
  • CISA and partner agencies published guidance on the careful adoption of agentic AI services, which places agent deployment inside existing risk management rather than outside it (CISA, 2026).
  • Zero trust architecture evaluates access per request at a policy enforcement point, which for an agent means per screen and per action rather than once at login (NIST, 2020).
  • Who decides what an agent may access is usually unclear in practice, and the absence of a named decision maker is itself a control gap (How to audit sensitive data access across enterprise applications?).

What does a workflow actually require an agent to read?

Take a purchase order record in a procurement system as the worked example. The screen shows the PO number, the supplier's name and tax identifier, the requester's name and department, the line items with unit prices and quantities, the total, the budget code, the approval chain with each approver's name, and a free-text justification. An agent asked to check whether the PO is within the requester's spending authority and route it for approval needs the total, the budget code, the requester's authority limit from a second screen, and the next approver in the chain. It needs the requester's identity only as a key to look up the limit. It does not need the supplier's tax identifier, the individual unit prices, the justification text or the names of approvers further down the chain.

The task reads perhaps five values. The screen shows thirty. Access control, as ordinarily configured, grants the agent the screen. Most of what the agent then holds is internal company data that the task did not require, and the AgentDAM evaluation shows what follows: web agents on several leading models were prone to inadvertent use of unnecessary sensitive information, drawing on what was in context rather than on what the task called for (Zharmagambetov et al., 2025). The supplier's tax identifier is in context, and at some rate it will appear in a note, a summary or a form where it was not meant to go.

The distinction between workflow and values is the answer to the title question. The agent needs the workflow: the procurement screen, the authority lookup, the routing action, a handful of values as content and a few more as keys. It does not need the raw values of everything the screen shows. Agents that operate inside a suite inherit this problem at scale, which is why the question of how to control agent access across all enterprise applications comes up as soon as an agent touches more than one system.

Why does access control not answer the question?

Access control is a decision about identities and resources made before the work begins. An identity is granted a role; the role is mapped to systems and, in finer-grained designs, to records or fields within them. The decision is static for the duration of a session and is enforced at the point of entry. It was built for people, whose use of what they can see is governed by training, habit and judgment, and whose reading of a screen leaves no copy anywhere.

An agent's use of what it can see is governed by a model, and the model's reading of a screen leaves a copy in context, in logs and in whatever it writes. OWASP's LLM06:2025 entry on excessive agency names harm from excessive functionality, excessive permissions and excessive autonomy, and the mitigation is to limit each to what the task requires (OWASP, 2025). The framing in terms of the task rather than the role is the shift that matters: a permission appropriate for the role is still excessive for a task that does not need it.

The joint guidance on AI data security from CISA, the NSA, the FBI and international partners makes a related move. It treats the data used to train and operate AI systems as something to be secured across its lifecycle, with attention to where it comes from, how it is handled and where it goes (CISA, 2025). Data that an agent reads from an internal screen is data used to operate an AI system, and lifecycle security asks what happens to it after the read, which access control cannot answer. Together the frameworks say that asking whether the agent has access is necessary and not sufficient; the sufficient question is what it received and did with it, which is the subject of auditing sensitive data access across enterprise applications.

What does official guidance say about agents and internal data?

Source What it addresses What it implies for an agent on internal data
CISA and partners, Careful Adoption of Agentic AI Services, 2026 Risk management for adopting agentic AI Agent deployment belongs inside existing governance
CISA, NSA, FBI and partners, AI Data Security, 2025 Securing data used to operate AI systems through its lifecycle Data an agent reads is operating data; handling after the read is in scope
OWASP LLM06:2025 Excessive Agency Permissions, functionality and autonomy beyond the task Scope all three to the task, not the role
NIST SP 800-207 Zero Trust Architecture Per-request access evaluation at an enforcement point Evaluate per screen and per action, not once at login
NIST AI RMF 1.0 Governing, mapping, measuring and managing AI risk Decide and record what the agent may receive, with an owner

The guidance converges on existing risk management and on scoping to the task. CISA and partner agencies ask organizations to apply their risk management to agent deployments rather than treat them as a separate category (CISA, 2026). The AI Risk Management Framework's Map and Govern functions ask for the decisions about an AI system to be explicit and owned, and which internal data an agent receives is one of those decisions (NIST, 2023).

Zero trust supplies the enforcement model. NIST SP 800-207 evaluates access to each resource per request at a policy enforcement point, rather than granting it once for a session (NIST, 2020). For an agent that works through screens, the natural unit of request is the screen and the natural enforcement point is between the screen and the model. Deciding per screen which values the model receives is a finer grain than any role-based decision, and the grain at which the title question is answered.

Where does the gap between access and flow show up in practice?

The gap appears wherever an agent does something correct with data it should not have been holding. The procurement agent routes the PO correctly and also mentions the supplier's tax identifier in the routing note, because it was in context and seemed relevant. It summarizes the justification text for the approver, including a line about a competitor's pricing that the requester had typed in confidence. It fills an optional "notes" field on the routing form with the names of all five approvers in the chain. None of these actions is outside the agent's permissions. None is the task. Each moved internal data from where it was to somewhere it was not, through the ordinary operation of a model that uses what it holds.

MIT Sloan Management Review's framing of agentic AI around nine essential questions puts governance and accountability among the questions an organization must answer before deploying agents (MIT Sloan Management Review, 2025). The gap between access and flow is a governance question in that sense: who decided that the agent could hold the tax identifier, and did anyone decide at all? In most organizations the answer is that nobody decided; the agent was given the role, and the role came with the screen. The page on who decides which data an agent can access treats the absence of a named decision maker as the first finding of any review.

The gap also appears in the record. An access log shows that the agent opened the PO. It does not show that the model received the tax identifier, or that the identifier appeared in the routing note. An organization that audits agent access from its access logs will conclude that the agent accessed only what it was permitted to access, which is true and beside the point. The flow is invisible to a control that was never watching it.

How can an agent have the workflow without the raw values?

Give the agent the screen with the values it needs readable and the values it does not need replaced. For the PO record, the total, the budget code and the authority limit are readable, because the task reads them. The requester appears as EMP_001 and the supplier as VENDOR_001, consistent across the PO screen, the authority lookup and the routing form, because the agent needs to recognize them but not to know them. The tax identifier, the unit prices, the justification text and the downstream approvers' names are tokenized or withheld, because the task does not use them. The agent completes the routing with the workflow intact and most of the internal data absent from its context.

Three properties make this work. Consistency, so that EMP_001 is the same requester on every screen and the agent can connect the PO to the authority limit. Late resolution, so that where an action requires a real value, such as the next approver's address on the routing notification, the value appears at that destination at the moment of the approved action and nowhere else. And placement at the screen, so that the control covers every application the agent works through without an integration for each, which is what zero trust's per-request evaluation looks like when the request is a rendered screen.

The result is an agent that has access to the workflow and not to the raw values, which is the distinction the title question needed. Tools that classify data at rest and report on which identities can reach which records answer the access question thoroughly and the flow question not at all, a difference set out in the comparison of a render-layer design with Varonis. Both questions matter. Only one of them is new.

What does a governed environment change?

In a governed environment, the agent receives the workflow, which is the screens, fields and actions a task runs through, while the raw values in those fields reach the model only where the task needs them.

This class of control separates access from flow. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so a field the agent must carry from one screen to the next is carried as a token and a field the task does not need is withheld or tokenized. The task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions such as submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This is the per-task decision the previous section described, enforced where the agent operates. Marking each field as read, carried or unneeded is an access decision stated at the grain of the screen, with a named owner, which is the Govern function of the AI Risk Management Framework applied to one agent (NIST, 2023). The environment applies that list on every screen rather than once at login, the per-request evaluation that zero trust architecture describes (NIST, 2020). The record of each run shows what the model received, what it did and who approved it, so the decision can be verified later by someone who was not present, which an access log alone cannot do.

The control does not alter the application, the user's permissions or the model, and it does not cover agents that have not been registered and run outside the environment.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design gives the agent the workflow without the raw values. The agent runs inside a governed environment in the customer's cloud, and substitution happens at the render layer, before any model reads the screen, so the tax identifier, unit prices, justification text and downstream names on a purchase order reach the model as consistent tokens such as VENDOR_001 or EMP_001 for the whole run, or not at all, while the total, budget code and authority limit the task reads stay readable. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy, which is the per-task access decision with an owner, and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, needs no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would produce the read, carried and unneeded list for one task and show each screen as the model received it. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on official guidance from CISA and partner agencies on AI data security and on the careful adoption of agentic AI services, on NIST SP 800-207 and the NIST AI Risk Management Framework 1.0, on OWASP's LLM06:2025 entry on excessive agency, on the AgentDAM preprint measuring privacy leakage by web agents, on MIT Sloan Management Review's framing of agentic AI governance, and on earlier RedactSure research pages on data access, auditing, customer data, Varonis and shadow agents. All sources were read as of October 16, 2026. The behavioral finding cited is the study's own reported result and is not extrapolated to other models or tasks. The MIT Sloan Management Review article is cited for the governance framing its title describes and not for any specific finding.

No hands-on testing of any agent, model or product was performed for this page, and no organization's procurement workflow was examined. Where a vendor or platform capability is mentioned, the description is confined to the pages reviewed; what is not described there should be read as not described, not as absent. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The purchase order record, authority lookup and routing form used as examples describe a record type and a workflow, not any organization; no customer or prospect is described.

Whether a given agent's access to internal data meets an organization's obligations under its own policies, its contracts or applicable regulation is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

An agent needs access to the workflow, and the workflow needs far fewer raw values than the screens that carry it display. Access control answers who may touch the data and stops there; the official guidance on agent adoption, AI data security and excessive agency asks the further question of what the agent received and what happened to it during execution, and the research shows that an agent uses what it holds whether or not the task called for it. Zero trust supplies the grain, per request, and for a screen agent the request is the screen. A design that keeps read fields readable, carries keys as consistent tokens and withholds the rest gives the agent the workflow without the values; RedactSure's design does this at the render layer. The test is to name one agent and one task and ask which values on each screen the task read, which it carried, and which it received for no reason anyone decided.

Frequently asked questions

If the agent cannot see the data, how can it do the work?

Because most of the work is navigation, comparison and action, not reading of secrets. The procurement agent needs to find the PO, compare the total with a limit, and route it. It needs the requester as a key to look up the limit, not as a name. Fields the task reads stay readable; fields it carries become consistent tokens; fields it does not use are withheld. The task that breaks is one whose policy hid a field the step needed to read, and a pilot run exposes that quickly.

Is giving the agent the same access as the employee the safe default?

It is the common default, and it is wider than any single task. An employee's role was sized for the whole job, across many tasks and years. An agent performing one task under that role receives everything the role can see, and research shows agents use what is in context whether or not the task required it. OWASP's excessive agency entry frames permissions against the task, not the role, and that is the frame that fits agents.

What is the difference between access control and controlling data flow?

Access control decides, before the work, which identities may reach which resources, and enforces it at entry. Data flow is what happens to the values after entry: which the model read, carried into reasoning, wrote into a tool call or included in an output. Access control was sufficient for people because a person's reading leaves no copy. A model's reading leaves copies in context, logs and outputs, so flow needs its own control.

Does zero trust apply to an agent reading screens?

Yes, if the unit of request is chosen correctly. NIST SP 800-207 evaluates access per request at a policy enforcement point. For a person the request is a login or a resource call. For a screen agent the request is each screen, and the enforcement point sits between the screen and the model. Deciding per screen which values the model receives is zero trust applied at the grain the agent operates at, rather than once at session start.

Who should decide which internal data an agent may receive?

A named person who owns the task, recorded as the decision maker, which is what the AI Risk Management Framework's Govern function asks for. In practice the decision is often made by default: the agent was given a role and the role came with the screens. A review that cannot name who decided the agent could hold a given field has found its first gap. The decision should be made per task, written as a field list, and verified against a captured run.

What does the record of a run need to show?

What the model received on each screen, what the agent did, and who approved any consequential action. An access log shows that the agent opened a record, which is necessary and not sufficient; it cannot show whether an unneeded field reached the model or appeared in an output. A record that captures screens as the model saw them lets someone who was not present verify, later, that the agent had the workflow and not the raw values it did not need.

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.