Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?

Separate access to the workflow, meaning the ability to navigate, click and fill, from access to the values on the screen, then grant the first broadly and the second only at approved destinations at the moment of an approved action. Check whether the platform you are evaluating can tell those two kinds of access apart at all.

An abstract agent reaches selected workflow records through several screen layers and a separate data boundary.

Separate access to the workflow, meaning the ability to navigate, click and fill, from access to the values on the screen, then grant the first broadly and the second only at approved destinations at the moment of an approved action. Check whether the platform you are evaluating can tell those two kinds of access apart at all. Most do not. When an agent is given a login to an accounts payable system so that it can process invoices, it receives both kinds of access in one grant: it can open the invoice screen, and it can read the vendor's bank account number and tax identifier that the screen displays. The task needs the first. It does not need the second until the moment a payment is scheduled, and even then it is the payment system, not the model, that needs the number. The two are bundled because applications were built for people, and a person who can work a screen can read it. For an agent the bundle can be taken apart. This page sets out the distinction, surveys how current agent platforms grant workflow access, explains why bundling the two produces excessive agency, describes how value access is granted only at a destination, proposes a measurement, and lists the claims a buyer should refuse. It builds on the definition of a governed AI workflow and on the question of whether a bot should be given access to company systems at all.

Key findings

  • OWASP's LLM06:2025 entry defines excessive agency as a model granted more functionality, permission or autonomy than its task requires, which is what a single login that bundles workflow access with value access produces by construction (OWASP, 2025).
  • Agent platforms document user-interface automation as a core capability: AWS describes an AgentCore Browser for web applications (AWS, 2025), and Microsoft describes computer-using agents for UI automation in Copilot Studio (Microsoft, 2026).
  • Platform vendors document human approval before consequential steps; OpenAI's Agents SDK includes a human-in-the-loop guide for interrupting a run until a person approves a tool call (OpenAI, 2025).
  • The credential case shows the separation working: 1Password describes browser agents whose model never needs to see or handle the credentials, which are injected only if the human approves the access (1Password, 2025).
  • Tokenization, as the payments industry defined it, lets a system work with a surrogate while the real value is exchanged only where needed, the mechanism value access at a destination relies on (PCI Security Standards Council, 2011).
  • Governance writing on agentic AI frames the core questions as what the agent is permitted to do, what it can see and who is accountable, which are three separate decisions rather than one (MIT Sloan Management Review, 2025).

What is the difference between workflow access and value access?

Take an invoice record in an accounts payable system: vendor name, vendor identifier, tax identifier, bank account and routing numbers, invoice number, line items, amounts, purchase order reference, approval status. The workflow for processing it is a sequence of screens: open the invoice, match it against the purchase order, check the three-way match, set the approval status, schedule payment. Each step is a navigation, a comparison or a form entry.

Workflow access is the ability to perform that sequence: find the record, move between screens, read the fields the comparison depends on, change the status, fill the payment form. Value access is the ability to read the real content of specific fields: the bank account number, the tax identifier, the vendor's legal name. The workflow needs structure and state. It needs to know that this invoice's purchase order reference matches a purchase order that exists, that the amounts agree, that the vendor identifier on the invoice is the vendor identifier on the order. None of that requires knowing the bank account number, which becomes relevant only when the payment is written to the banking system.

For a person the two are inseparable, because a person reads a screen by looking at it. For an agent they are separable, because the agent reads a screen that the environment has rendered, and the environment can render the bank account field as BANK_001 while leaving the amounts and references readable. The agent then has full workflow access and no value access, and the task completes. The question of what the agent should see for this piece of work is a question about value access alone, asked once per task; workflow access can be granted as widely as the task requires.

How do current agent platforms grant workflow access?

The platform vendors have made workflow access a product. AWS documents a browser tool within Amazon Bedrock AgentCore for interacting with web applications (AWS, 2025). Microsoft documents computer-using agents in Copilot Studio for complex UI automation at scale (Microsoft, 2026). OpenAI documents a human-in-the-loop pattern in its Agents SDK, in which a run is interrupted until a person approves a tool call (OpenAI, 2025).

Dimension Vendor, per its documentation What a buyer should verify
Operating a web application through its interface AWS AgentCore Browser documents a browser tool for web application interaction What the model receives from each page, and whether any field is substituted before it arrives
Automating user interfaces Microsoft documents computer-using agents for UI automation in Copilot Studio Whether the agent reads the full rendered screen and what controls which values the model sees
Pausing for human approval OpenAI's Agents SDK documents human-in-the-loop interruption of tool calls Which actions are gated, who approves, and whether the approver sees values or tokens
Substituting values before the model reads the screen Not described in the pages reviewed for any of the three Whether the platform or a separate environment performs render-layer substitution with consistent tokens

Workflow access is well documented and approval gating is documented at the tool-call level. Separation of value access, meaning substitution of specific fields before the model reads the screen, is not described in the pages reviewed for these platforms, so a buyer who needs it should ask the vendor and otherwise supply it from the environment the agent runs in.

Why does bundling the two produce excessive agency?

OWASP's definition is the reference point: excessive agency arises when a model is granted more functionality, permission or autonomy than its task requires (OWASP, 2025). A login that grants both kinds of access to an invoice-processing agent is excess permission by definition. The agent's task requires workflow access; the login also delivers every bank account number on every invoice the login can open.

The excess matters because of what else the agent reads. An invoice is a document a vendor sent. Its line items, its notes field and its attached PDF are untrusted content, and untrusted content can carry instructions. OWASP lists prompt injection as the first risk for LLM applications (OWASP, 2025). An agent with value access that reads an injected instruction in a vendor's notes field can be directed to copy the bank account numbers it has seen into a field the attacker controls. An agent with workflow access only can be directed to do the same thing and will copy BANK_001, which resolves to nothing outside the run.

The governance literature arrives at the same separation from the management side. The MIT Sloan Management Review's nine questions on agentic AI distinguish what an agent is permitted to do, what information it works with and who is accountable for its actions, treating them as separate decisions for separate owners (MIT Sloan Management Review, 2025). Bundled access collapses the first two into one grant made by whoever provisioned the login. Separating them restores the decisions to the people who should make them: the workflow owner decides what the agent may do, the data owner decides what it may see, and both decisions are recorded.

How is value access granted only at approved destinations?

The mechanism is tokenization in the sense the payments industry defined it: the real value is held in a system segmented from the systems that work with the surrogate, and the exchange happens only where the real value is required (PCI Security Standards Council, 2011). For the invoice agent, the destination is the payment form in the banking system. The agent fills that form with BANK_001 and ROUTING_001; when a named person approves the payment, the environment resolves the tokens as it writes the form to the destination, and the model's context never held the numbers.

The credential case shows the pattern already deployed in one domain. In 1Password's description of browser agents, the agent and the underlying model never need to see or handle the credentials, which are injected into the sign-in form if, and only if, the human approves the access (1Password, 2025). A credential is needed at one destination, the login form; a bank account number is needed at one destination, the payment form. The same conditions make the pattern work: the value is injected by the environment rather than typed by the model, the injection is tied to an approval, and the approval is given by a person.

Zero trust architecture frames this as policy enforcement per request rather than access granted per session (NIST, 2020). The session grants workflow access. Each resolution of a token at a destination is a separate request, evaluated against the per-destination list and the approval, and recorded. A governed workflow pilot is where an organization sees that sequence on its own invoice records: the agent working the screens on tokens, the single approval, the single resolution.

How should an organization measure the separation?

Measure two things on a real run. First, value exposure: for each screen the agent read, which fields arrived at the model as real values and which as tokens. The measurement is a list, produced from the run record, and it should match the policy the data owner confirmed. Any sensitive field that arrived as a value is a gap, whether or not anything went wrong.

Second, resolution events: how many times during the run a token was exchanged for a real value, at which destination, under whose approval. For the invoice workflow the expected count is one, at the payment form, approved by the named approver. A count of zero means the task did not complete or the payment went out with a token in the account field, which the banking system will reject. A count above one means a destination received a value that the per-destination list did not anticipate, or that the policy allows more resolution than the task needs.

Then run the workflow with an injected instruction in a vendor notes field and repeat both measurements. The agent may follow the instruction; the research record says agents often do. What the measurement shows is what the instruction could reach. A platform that offers workflow access alone, with the approval gates its documentation describes, will show a wrong action attempted and nothing sensitive in the model's context to exfiltrate. A platform with bundled access will show the account numbers available to whatever the instruction asked for. Comparing a governed environment with a data-governance platform that discovers and classifies data at rest makes the same point from another side: knowing where sensitive data lives does not change what the agent reads on a screen.

What does a governed environment change?

A governed environment is what makes the separation between workflow access and value access enforceable: the agent navigates, clicks and fills on tokens, and real values appear only at an approved destination at the moment of an approved action.

Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so the task runs on tokens, and workflow access can be granted broadly because it no longer carries the values with it. Real values resolve only at an approved destination, such as the payee field at the moment a payment is approved. A named person confirms what is tokenized for each workflow and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This corrects the two bundled grants this page describes. A single login that grants both kinds of access produces excessive agency in OWASP's sense, more permission than the task requires (OWASP, 2025); tokenizing the screen withdraws the value grant while leaving the workflow grant intact. Approval of an action does not cover what the model has already read, and in this class of control the approver and the model both see tokens up to the approved resolution. The surrogate pattern is the payments industry's, a token in use and the real value exchanged only where needed (PCI Security Standards Council, 2011). The two lists the page asks a vendor for, fields received as values and resolution events, are read from the run record.

The environment does not change the application, the user's permissions or the model; the workflow runs as before.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design is the separation this page describes. A governed environment in the customer's cloud grants the agent workflow access to the applications the task requires, and substitution at the render layer before any model reads the screen withholds value access, with consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action, which for an invoice workflow is the payment form after approval. A named person confirms the tokenization policy and approves every payment, submission and record change, which the company calls 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 environment is model agnostic, requires no per-application integration and leaves user permissions unchanged, so the agent's workflow access is the access the organization already grants.

Deployments are in pilot. On the reader's own workflow, a pilot would show the agent completing the screens on tokens, the list of fields that arrived as values, and the single approved resolution event with the approver's name. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on OWASP's LLM06:2025 and LLM01:2025 entries (standards), the PCI Security Standards Council's Tokenization Guidelines Information Supplement (2011; industry standards guidance), NIST Special Publication 800-207 (2020; official guidance), vendor documentation from AWS on the AgentCore Browser tool, Microsoft on computer-using agents in Copilot Studio, OpenAI on human-in-the-loop in its Agents SDK and 1Password on credential handling for browser agents, the MIT Sloan Management Review's article on agentic AI governance questions (2025), and RedactSure research pages. All sources were read as of October 16, 2026.

No hands-on testing of any platform or product was performed. The vendor table reports what each vendor's cited page describes and does not rank the platforms; a platform may offer substitution or field-level controls on pages not reviewed here. Vendor capabilities are described from the pages reviewed; "not described in the pages reviewed" means exactly that and not that a vendor lacks the capability. Vendor features change quickly in this market, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The invoice record and accounts payable workflow used as a worked example describe a record type and a task, not any organization or vendor relationship.

Whether a given separation of workflow and value access, a per-destination resolution list or an approval design meets an organization's regulatory and contractual obligations is a determination for its counsel, its assessors and its own security and compliance officers. This page supports that review and does not replace it.

What the record shows

Agents can be given access to workflows without exposing sensitive data once the two kinds of access are taken apart. Workflow access, the ability to navigate, compare, change status and fill forms, is what the platforms now sell and what the task requires, and it can be granted broadly. Value access, the ability to read the real content of sensitive fields, is required at one or two destinations per task and nowhere else, and it can be granted there alone through substitution before the model reads the screen and resolution at the destination under a person's approval. The platform documentation reviewed describes the first and the approval gate but not the substitution; RedactSure's design supplies it from the environment. The test is to name one agent and one task and ask which fields the model received as values, and how many times a token was resolved and where.

Frequently asked questions

Can an agent complete a workflow if it cannot read the sensitive fields?

Yes, when the fields it cannot read are the ones the task does not depend on. An invoice-processing agent needs amounts, references and status, not bank account numbers. The design requires that the policy leave task-critical fields readable and tokenize the rest, with tokens consistent across screens so the agent recognizes the same record. Where a task does depend on a sensitive value, that value is needed at a destination, and resolution there completes the task without the model having read it.

Is human approval of actions enough on its own?

It governs actions, not reading. An approval gate stops a payment from being scheduled until a person agrees, which is necessary. It does not change the fact that the model has already read every screen it opened, including the account numbers, before the approval request is raised. Approval gates and value separation address different risks, wrong actions and data exposure, and a workflow processing sensitive records needs both.

How is this different from restricting which applications the agent can open?

An application allowlist controls workflow access at the coarsest level: which systems the agent may enter. It says nothing about which fields within those systems the model reads. The sensitive values and the untrusted content, such as a vendor's notes field, are inside the approved application. Separating value access operates within an approved application, field by field, which an allowlist cannot do.

Where does the real value get entered if the model never sees it?

By the environment, at the destination, at the moment the approved action executes. The model fills the payment form with tokens; when the named approver confirms, the environment substitutes the real values as the form is written to the banking system. The pattern is the one credential managers use for browser agents, where the credential is injected into the login form on approval and the model never handles it.

Does this require changing the applications?

Not in the design described here. Substitution is applied to the rendered screen inside the agent's environment, after the application has produced it, and the application, its database and other users are unaffected. Workflow access is the access the organization already grants through its existing permissions. What changes is what the model receives from each screen and how the final write to a destination is performed, which is why the approach reaches legacy screens that have no API.

What should a pilot measure to confirm the separation?

On a real workflow with real records, two lists from the run record: the fields that arrived at the model as values on each screen, matched against the confirmed policy, and the resolution events, with destination and approver for each. Then repeat the run with an instruction planted in untrusted content, such as a vendor notes field, and compare the lists. The second run shows what an attacker could have reached, which is the figure that matters.

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.