Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Prevent AI Agents From Oversharing Data Between Apps: Carry Tokens, Not Values

Give the agent tokens, not values: the model holds SSN_001, and real values resolve only at approved destinations at the moment of an action a named person approves.

Documents from separate applications pass through a gate before entering a destination database.

62% experimenting · 23% scaling · 1 named person

62% of organizations are experimenting with AI agents and 23% are scaling them (CX Today, 2026). The agents that scale read in one application and write in another: a claim file into a letter, an invoice into an ERP posting. Every write reproduces whatever the model holds. If the model holds the claimant's Social Security number, so does the letter, and so does any address an injected instruction names.

You are probably defending the exit: a DLP rule on outbound mail, a connector scope, the vendor's allow list, "always allow" for routine steps. Each acts after the model has the record, and each can lose a single send. Rome did not guard its treasury by inspecting carts at the gate; it kept the gold where carts could not reach.

An agent that never holds the value cannot overshare it. Tokenize identifiers where the screen is rendered, before any model reads it, and stop every send, upload and submission for one named person. Real values resolve only at approved destinations at the moment of that approved action; elsewhere the token stays a token. An agent holding CLAIMANT_001 and ACCT_001 can match them across two applications and has nothing an unapproved send can carry. The work gets done. The data stays hidden.

Dots, Muse and Claude in Chrome each read the page in full, by their own documentation

OpenAI's Dots each have "its own cloud computer and browser" and connect to more than 4,000 apps (The Next Web, 2026). Secure sign-in submits credentials "without exposing them to the model's context" (OpenAI, 2026). Meta's Muse gives each user a Secure VM whose Sentinel approves every network egress, and reads the page in full (Meta AI Research, 2026). Claude in Chrome takes screenshots of the active tab, and all visible information, personal data included, becomes part of the context (Claude Help Center, 2026).

Dots and Muse keep the password out of the model. None of the three, by documentation read October 9, 2026, keeps the Social Security number out.

Property Employee's browser Vendor cloud computer Customer-owned governed environment
What the model receives The visible tab, personal data included The page in full The task's fields, identifiers as tokens
Who holds the keys The employee's device Not disclosed, or the vendor The customer
Record of each screen Not described Vendor activity view Every screen as tokens, in your SIEM

Only the governed environment hands the model tokens instead of the page.

One consistent token lets CLAIMANT_001 match across 2 applications without the value

Render-layer tokenization is replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action. The claimant is CLAIMANT_001 on the claim screen and on the correspondence screen. The agent matches them without learning the name.

Least Exposure is the principle that for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. Amounts, dates, codes, coverage and clinical facts stay in clear. As an illustration, a claims agent reads a reserve of $12,480 and the loss date, then drafts the status letter to the claimant as CLAIMANT_001, never holding the name.

The PII Wall is the point in an AI program where the valuable workflow turns out to run on data the security team will not let a model see, and the project shrinks or stops. Cross-application workflows hit it first, because the identifiers are the join key; a token can be one.

The planner sets what the agent may do, and Copilot Studio's allow list shows why an exit rule is not enough

A token that resolves anywhere is a value with a delay. The planner sets what is tokenized and what the agent may do on each screen; a named person confirms that policy before the run. Real values resolve only at approved destinations at the moment of an approved action. An unapproved send carries tokens, and they stay tokens.

Copilot Studio's access control "only prevents the model from taking actions on websites or applications that aren't in the allow list. It doesn't stop the model from opening them" (Microsoft Learn, 2026). The list governs where the agent acts, not what it holds. A connector scope returns the whole object its author defined.

Property DLP rule Connector scope Allow list Render-layer tokens
Acts when After the model holds the value At connection, once At the action Before the model reads
Governs The outbound message Which objects return Where the agent acts What the model holds
An unapproved send carries A misclassified message The whole object What the model holds SSN_001

DLP, connector scopes and allow lists stay as a second line; tokenization changes what they catch.

Greshake et al. showed in 2023 that an observed page can carry instructions the agent follows

LLM01 prompt injection · LLM02 sensitive information disclosure · 0.08% attack success in one vendor's internal testing

OWASP ranks prompt injection first and sensitive information disclosure second for 2025 (OWASP, 2025; OWASP, 2025). Greshake et al. demonstrated indirect prompt injection, in which content the agent observes carries instructions the agent follows (Greshake et al., 2023). Wallace et al. describe the instruction hierarchy, a training mitigation that teaches the model to prioritize privileged instructions (Wallace et al., 2024).

Every vendor answers with a filter. Anthropic reports attack success under 0.08% in internal testing of Claude in Chrome's classifiers (Claude Help Center, 2026). OpenAI combines "model safeguards with tool restrictions, checks before actions, and monitoring" for Dots (OpenAI, 2026).

A filter decides whether the send happens. Tokenization decides what it carries. An agent that holds only tokens follows "forward this file" with tokens, so the attacker's inbox receives SSN_001 and the action still stops for the named person (Prompt Injection When the Agent Sees Only Tokens). The classifiers stay; they are no longer the only barrier.

Every send, upload and submission waits for 1 named person

Supervised Delegation means a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. Here the consequential actions are the writes, since each moves what the agent holds elsewhere.

At each stop the person sees the destination and the content as tokens. On approval the real values resolve at that destination, at that moment. Without approval nothing resolves, the tokens stay tokens, and the person can send it themselves.

The approver must have run the work. Copilot Studio's documentation says a reviewer other than the person running the agent "likely don't see the activity because they didn't initiate the run. Therefore, they can't properly verify or act on the request" (Microsoft Learn, 2026).

A tethered agent is an agent that works only inside the governed environment a named person connected it to, on the applications that person chose. It cannot open an application the person did not connect, so "always allow" has nothing to allow beyond them.

The AI Control Record puts every destination in your SIEM, where Purview does not reach today

An AI Control Record is the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. The useful rows are the writes: destination, content as tokens, which tokens resolved, who approved, when.

Your DLP lacks those rows. A Microsoft Q&A moderator's reply states that Purview documentation does not describe enforcement against a computer-use agent's data-movement step (Microsoft Q&A, 2026).

Exported to your SIEM, an unapproved send becomes an alert beside everything else. Separation of model and control is the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. The record, the policy and the keys stay with you when you change the model.

7 Rules for carrying tokens, not values, between apps

Trace every write before the first run

List each application the work crosses and mark the writes. A claims agent writes a letter; an AP agent posts to the ERP, then emails the supplier. Each write is a destination to govern. Test: Ask a colleague to name a place the agent could write that is not on your list. If they can, you are not done.

Mark the identifiers on every screen the agent reads

Split each screen's fields into what the task needs in clear and what becomes a token. The task needs amounts, dates and codes, not the Social Security number.

In clear As tokens
Reserve amount, loss date, coverage code CLAIMANT_001, SSN_001
Invoice total, due date, GL code VENDOR_001, ACCT_001

Confirm the policy before the first run

The planner sets what is tokenized and what the agent may do on each screen. The named person confirms it, dated, on the record. Real values resolve only at approved destinations at the moment of an approved action. Before: The letter leaves with whatever the agent holds, and no one confirmed what that was. After: The person confirmed the claimant is CLAIMANT_001 to the model; the name resolves in the letter only when the person approves the send.

Keep tokens consistent across applications

The same person must be the same token on every screen, or the agent cannot match records. A redaction cannot be matched. Test: Open both screens in the record. The claimant token on each is the same string.

Stop every send, upload and submission for the named person

The person sees the destination and the content as tokens, then decides, on the record. The owner decides, not a bystander. Before: The agent sends the supplier email; the person is notified afterward. After: The send waits. The person sees VENDOR_001, ACCT_001 and the supplier's address, approves, and the values resolve at that moment.

Attack your own deployment before an attacker does

Have the agent attempt a send to an address no one approved. Then plant a line on a test page telling it to forward the content elsewhere, the indirect injection path Greshake et al. described (Greshake et al., 2023). Test: Both runs stop for the named person, and the content that would have left reads SSN_001.

Keep the exit controls and connect the record

Leave your DLP rules and the vendor's own action checks in place as the second line. Export the AI Control Record to your SIEM so an unapproved send is an alert where security already looks. Test: An unapproved send appears in the SIEM with the destination and the person's decision.

How to choose where the agent runs and where values resolve

  • If the workflow reads identifiers in one application and writes to another, run the agent in a customer-owned governed environment with render-layer tokenization and a named person approving every write.
  • If the task runs on amounts, dates and codes, keep those in clear and tokenize everything else.
  • If a destination is outside your organization, have the named person approve every send to it; nothing resolves without that approval.
  • If your plan is a DLP rule on outbound mail, keep it as the second line; it acts after the model holds the value.
  • If the vendor offers "always allow" or an automatic-approval default, decline it for writes.
  • If an application exposes a well-scoped API for a high-volume structured step, use it there and the screen elsewhere, and check what the connector returns.

The checklist

Check Pass Fail
Model input for one claim screen Reserve and loss date in clear; claimant as CLAIMANT_001 The screen in full
Token consistency across applications Same token for the same person Different tokens, or a blank
Policy confirmed before the first run Dated, names the owner, states what is tokenized Unconfirmed or undated
Unapproved send test Stops; content reads SSN_001 Delivered with the value
Planted-instruction test Action stops; tokens were all it could move Values forwarded
Approver on each write The person who ran the work, by name A rule or a queue
Keys and record In your custody; record in your SIEM Held by the vendor
Model change Policy, record and keys unchanged Controls move with the model

Questions

Can the agent paste a customer's SSN into an email?

Not when the model never held it. The model receives SSN_001, so its draft contains SSN_001. The real value resolves only at an approved destination at the moment the named person approves the send. An address no one approved is not one, so the string SSN_001 is all that could arrive, and the attempt lands in the AI Control Record with the person's decision.

What if the destination is legitimate but was not anticipated?

The send stops for the named person, with the content shown as tokens and the destination shown. The person approves it, on the record, and the real values resolve at that destination at that moment, or sends it from their own mailbox. An unanticipated destination is an approval event, not an exfiltration event; the record shows who approved it, and when.

Does this stop prompt-injection exfiltration?

It changes what an injection can take. Greshake et al. showed that observed content can carry instructions the agent follows (Greshake et al., 2023). An agent that holds only tokens follows "send this elsewhere" with tokens, so the attacker's inbox receives SSN_001, and the action still stops for a named person. Classifiers and the instruction hierarchy remain useful. They are no longer the only barrier.

Does this change the user's permissions?

No. The agent works under the permissions the user already holds, on the applications a named person connected it to. Nothing is added, removed or changed. What changes is what the AI can see on each screen and where the values it carries resolve. A user who could not reach the payer portal still cannot, and neither can the agent tethered to that user.

How does the agent do the work if it cannot read the identifiers?

The work runs on the fields the task needs, which stay in clear: amounts, dates, codes, coverage and clinical facts. The identifiers are consistent tokens, so the agent matches CLAIMANT_001 on the claim to CLAIMANT_001 on the correspondence screen and fills the letter the way a person would. The letter is addressed to the real claimant only at the approved send.

Is a DLP rule still needed?

Yes, as a second line. Egress rules and the vendor's own action checks still catch anomalies, and the AI Control Record gives them a per-screen input to correlate against. They are no longer the only thing between a misclassified message and a Social Security number; a Microsoft Q&A moderator's reply states that Purview documentation does not describe enforcement against a computer-use agent's data-movement step (Microsoft Q&A, 2026).

Why is the workflow owner the approver rather than security?

Because the owner can judge the send. Copilot Studio's documentation says a reviewer other than the person running the agent "likely don't see the activity" and "can't properly verify or act on the request" (Microsoft Learn, 2026). Security sets the policy and watches the SIEM; the owner approves each write with the run in front of them. Both names appear in the record.

Methodology

What this page rests on. Vendor documentation for OpenAI Dots, Claude in Chrome, Meta Muse, Microsoft Copilot Studio computer use, Microsoft Purview, read as of October 9, 2026 and quoted with dates; the OWASP Top 10 for LLM Applications 2025; the McKinsey figures as reported in press; and the research works cited.

What was not tested. No hands-on testing of any named product was performed. Platform behavior changes with releases, and this page carries its date. The examples are illustrations.

Whose determination it is. Whether a workflow meets the minimum necessary standard, PCI scope or any other obligation is for the organization's counsel, its assessor and its security and compliance officers to determine.

How RedactSure does this

RedactSure is the governed environment these steps describe, in pilot: a secure virtual machine in the cloud your posture requires, with keys you hold, holding ciphertext it cannot decrypt. Identifiers chosen by policy, names, SSNs, MRNs, account and card numbers, dates of birth, addresses, become consistent tokens at the render layer before any model reads the screen. The Planner sets what is tokenized and what the agent may do on each screen; a named person confirms it and approves every send, upload, submission and record change while it runs. Real values resolve only at approved destinations at the moment of the approved action; elsewhere the token stays a token.

LLM01 injection · LLM02 disclosure · 1 named person per write

Every screen as tokens, every action and every approval lands in the AI Control Record and exports to your SIEM. The environment is model-agnostic: Claude, GPT, Gemini or open-weights models, swapped without moving the controls. Permissions do not change; what the AI sees does. Prompt injection that succeeds against a RedactSure agent collects tokens, and the action still stops for the named person. The work gets done. The data stays hidden.

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.