Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Oversharing and How Can Data Move Between Apps Without Anyone Noticing?

AI agent oversharing is data carried in an agent's context from one application into another where it was not needed. It happens through four ordinary mechanisms: context carry-over, connectors, the clipboard and summaries. No alert fires because every step is authorized, so the first notice is often a value sitting in a record it never belonged in.

A browser exports documents through a screen-level gate toward database and cloud applications.

AI agent oversharing is data carried in an agent's context from one application into another where it was not needed. It happens through four ordinary mechanisms: context carry-over, connectors, the clipboard and summaries. No alert fires because every step is authorized, so the first notice is often a value sitting in a record it never belonged in. An agent that works across applications is, by design, a bridge between them, and a bridge carries whatever is loaded onto it. A patient identifier read in the EHR to confirm a visit has no business in the email the agent drafts afterwards, yet nothing in the application, network or identity system stands between those two screens. The principle that closes the gap 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

  • The OWASP Top 10 for LLM Applications 2025 lists Sensitive Information Disclosure as LLM02, the risk of data an LLM reveals through its outputs, the output side of oversharing (OWASP, 2025).
  • Agents read the page in full: Claude in Chrome's guidance states that all visible information on the active tab, including personal data, becomes part of the context (Anthropic, 2026), and a dot sees webpage text and document content within connected apps (OpenAI, 2026).
  • Microsoft's own answer on Purview DLP states that the documentation does not describe an enforcement capability that detects or blocks a computer-use agent's data-movement step inside its automated session (Microsoft, 2026).
  • Peer-reviewed work on information-flow analysis for LLMs finds that once data is in a model's context, deciding which inputs influenced an output is itself a research problem (Siddiqui et al., 2025).
  • A model-agnostic Tool-Input Firewall that strips data not needed for a tool call, paired with a Tool-Output Firewall, reached about 0 percent attack success on four agent-security benchmarks with little utility loss (Bhagwatkar et al., 2026).

What is AI agent oversharing, and how is it different from data exposure?

Oversharing is a movement, not a reading. AI agent data exposure describes the moment a model receives more of a screen or record than the task required. Oversharing is what happens next: a value received for one purpose, in one application, travels in the agent's context into a second application where the task did not call for it. Exposure loads the bridge; oversharing is the crossing. A team can have one without the other: an agent that reads too much and writes nothing, or one that read only what it needed and still pasted it into another application.

Take an agent asked to confirm whether an invoice has been paid. It opens the ERP, reads the vendor record, which shows the bank account, tax identifier and a contact's mobile number alongside the payment status, then opens the ticketing system to close the request. Its reply in the ticket includes the payment date, which the task needed, and the last four digits of the bank account, which it did not. The vendor's banking detail now lives in a ticketing system with a different access list and different readers. Nobody granted the agent anything new. Nobody exfiltrated anything. The data moved because the agent carried it.

What distinguishes oversharing from the leakage categories security teams already track is direction and actor. Data loss prevention is built around an exit. Oversharing happens between two applications the organization owns, under a session it issued, inside a workflow it asked for. OWASP's LLM02 entry describes the risk as sensitive information revealed through model outputs (OWASP, 2025), and an agent's write into a second application is an output. For agents that act, every field filled and message sent is an output surface.

Through which mechanisms does data move between applications?

Four mechanisms carry data across the bridge, each a normal feature of how agents work, not a flaw to be patched.

Mechanism How the data moves Where it lands Who could notice
Context carry-over Everything read earlier in the run stays in the model's context when it writes later The next form, message or record the agent fills Nobody at runtime; the context is not a monitored channel
Connectors and plugins A tool call returns a whole object (a customer, an order) and the agent reuses its fields elsewhere Any application reachable through another connector The connector log shows a read, not what was reused
Clipboard and transcription The agent copies a value from one screen and types it into another A field in a second application Clipboard monitoring, if present, sees text with no task context
Summaries and notes The agent writes a summary or status note that includes identifiers read along the way Ticket comments, CRM notes, chat, email A reader of that record, often weeks later

A screen-reading agent reads a page, not a field. Claude in Chrome's safety guidance states that all visible information on the active tab, including personal data, becomes part of the context (Anthropic, 2026). OpenAI's documentation for dots describes the model seeing webpage text and document content within connected apps (OpenAI, 2026). Whatever those pages held is in context when the agent moves to the next application. The page on what an agent sees when it takes a screenshot covers the reading side; carry-over is the consequence.

Connectors change the scale. A dot can connect to more than 4,000 apps through plugins (The Next Web, 2026). A connector returns what its author chose to expose, usually the full object; whether API connectors give the agent more than the task needs has its own page. Every connector is both a source and a destination, so possible crossings grow with the square of the count.

Why does nobody notice?

Three controls that would catch a person doing the same thing do not fire for an agent, because the agent is an authorized actor using authorized channels.

Identity and access management sees nothing wrong because the agent works inside a legitimate session. Least privilege does not cover what the AI sees: the user was entitled to open the vendor record and to write the ticket, so an entitlement check has no grounds to object.

Data loss prevention sees nothing wrong because no boundary was crossed. Microsoft's answer on a Q&A thread about Purview DLP and Copilot Studio computer use states that the documentation does not describe an enforcement capability that detects or blocks the agent's automated session actions, nor DLP enforcement against the data-movement step; what Purview DLP for Copilot covers is restricting prompts with sensitive information types and keeping labeled files out of grounding (Microsoft, 2026). A rule written for exfiltration has no event to match.

Logging sees nothing wrong because it records the opening, not the reading or the reuse. An application log shows the vendor record was opened at 2:14 p.m., not which of the twelve fields the model held, or that one reappeared in a ticket comment at 2:16 p.m. in another system. Copilot Studio's computer use shares reasoning messages and screenshots of the machine's activity in the chat (Microsoft, 2026): a record of what was on screen, not of what crossed between screens. The page on monitoring what an agent accesses treats the logging gap. The first notice of oversharing is a human reader, weeks later, wondering why a bank account fragment is in a ticket.

The fourth reason is adversarial. Indirect prompt injection, where instructions hidden in content the agent reads redirect it, was demonstrated against real LLM-integrated applications in 2023 (Greshake et al., 2023), and OWASP ranks it first in its 2025 list (OWASP, 2025). An injection does not need to break out of the organization to cause oversharing. It only needs to tell the agent to include what it has read in the next thing it writes.

What does research say about tracking data once it is in the model's context?

The instinctive engineering answer is to track the data: label every input, follow the labels through the model, and block any output carrying a label to a destination not cleared for it. This is information-flow control, and it has been tried on LLMs.

Siddiqui and colleagues treat an LLM as a component in a larger system and observe that poisoned data from one component can coerce the model into spreading confidential data to untrusted components, oversharing under attack (Siddiqui et al., 2025). Their proposal attaches integrity and confidentiality labels to each input and propagates to the output only the labels of inputs that influenced it, rather than the most restrictive label of everything in context. The permissive rule is needed because under the conservative one, every output of an agent that has read a confidential screen is confidential and the agent can write nothing. Under the permissive rule, deciding which inputs influenced an output becomes the hard problem, and the paper's contribution is a method for approximating it. That this is a peer-reviewed result from late 2025 is the point: tracking what an LLM does with data in its context is an open problem, not a feature a buyer can assume.

Bhagwatkar and colleagues approach the boundary from the other side. Their Tool-Input Firewall, the Minimizer, strips data not needed for a tool call before the call is made; their Tool-Output Firewall, the Sanitizer, removes instructions from what comes back. Together the two reached about 0 percent attack success on AgentDojo, Agent Security Bench, InjecAgent and tau-Bench with little utility loss (Bhagwatkar et al., 2026). The Minimizer is the oversharing control in that pair: it does not track where data went; it keeps data the next step did not need from reaching it. The same paper finds the public benchmarks weak, a caution against trusting any defense on benchmark numbers alone.

Read together, the two results point the same way. Following data after it has entered the context is hard and partial. Keeping data the next step does not need out of that step is tractable and, in the published tests, effective. What sits in the context is at the model's disposal, so the control has to act before it arrives.

How can an organization detect and bound oversharing?

Detection comes first because most organizations have agents in use before they have a policy. Accenture reports that 38 percent of executives expect agents to access data from across the organization within three years (Accenture, 2025); cross-application reach is the plan. Three detection steps use what teams have.

First, sample destinations rather than sources. Pick ten records an agent wrote last month (tickets, notes, emails, form submissions) and read each against the task that produced it. Any identifier the task did not require is an oversharing event, and the proportion across the sample is the baseline. Second, read one run end to end: list every screen or object the agent received, list every value in its outputs, and draw the lines that cross applications. Third, plant a marker: a distinctive, harmless string in a field the agent will read but should not reuse. Run the normal workflow and search the destination systems for it. If it appears, the carry-over path is live.

Bounding it is a design decision, with choices from least to most effective:

Approach What it does What it misses
Instruct the agent The system prompt tells the model not to include identifiers in outputs Depends on the model obeying; an injection can override it
Scan outputs A detector checks each write for sensitive patterns before it lands Misses unusual formats and runs after the model already holds the value
Scope connectors Each connector returns only the fields a defined task needs Per-connector engineering; screen reading not covered
Minimize per step Data the next step does not need is withheld before the step runs (Bhagwatkar et al., 2026) Needs a per-task definition of need, confirmed by someone accountable
Tokenize before reading Identifiers become consistent tokens before any model reads the screen, so what carries over is SSN_001, not the number Policy is set per task; clear values the task needs still carry over by design

The last two rows share a principle: the model cannot overshare what it never received. Tokenization goes a step beyond minimization by keeping the relationship (ACCT_001 on the ERP screen is ACCT_001 in the ticket) without the value, so the task completes and the crossing carries nothing that matters. HIPAA's minimum necessary standard at 45 CFR 164.502(b) limits protected health information to what a purpose requires (HHS, 2024); for an agent, the purpose is the task and the limit has to hold at each application the agent touches. The how-to page on preventing agents from oversharing between apps works through the implementation sequence.

Where does RedactSure sit?

RedactSure bounds oversharing at the moment before the model reads. Every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, which is render-layer tokenization. What carries over from the ERP to the ticketing system is ACCT_001 and VENDOR_001, not the account number and the name, so a summary, a pasted value or a reused field moves a token that resolves only at an approved destination at the moment of an approved action. The model receives the task's fields rather than a picture of the screen.

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. Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's SIEM, so the crossing nobody noticed is now a line in the record. No per-application integration, no change to permissions, model agnostic, 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 sources read as of October 13, 2026: the OWASP Top 10 for LLM Applications 2025 entries LLM01 and LLM02 (industry standard); vendor documentation from Anthropic on Claude in Chrome, OpenAI on dots and Microsoft on Copilot Studio computer use and the Purview DLP Q&A peer-reviewed research by Siddiqui et al. on information-flow analysis (TMLR, 2025) and Bhagwatkar et al. on tool-boundary firewalls (arXiv:2510.05244, 2026), with Greshake et al. on indirect prompt injection (2023); Accenture's Technology Vision 2025 and The Next Web (industry analysis and press); and 45 CFR 164.502 (regulation). Vendor statements are reported as what the vendors' own published material states.

No product was tested. No agent was run, no benchmark was reproduced, and the benchmark figures quoted are the papers' own, with the authors' caution about benchmark weakness. No measurement of how often oversharing occurs in production was found in the sources consulted and none is claimed. Vendor documentation changes; the page carries its date and is revised when the sources change. The invoice and ticketing 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 agent deployment satisfies the minimum necessary standard or any other requirement is a determination for the organization's counsel, assessor and security and compliance officers, not for the page. The sources cited describe risks and methods; they do not certify any product.

What the record shows

AI agent oversharing is the crossing, not the reading: a value received in one application reappears in another where the task never needed it, carried by context, a connector, the clipboard or a summary. It goes unnoticed because every step is authorized and no existing control watches the space between two internal applications. Tracking data after it enters the model's context is an open research problem; withholding data the next step does not need is a published, effective control. The test is one run: list what the agent received, list what it wrote, and draw the lines that cross applications. Each line carrying a real value the second application did not need is the problem, and the count of those lines is the measure.

Frequently asked questions

Is oversharing the same as a data leak?

No. A leak means data left the organization or reached someone not entitled to it. Oversharing means data moved between two applications the organization owns, under an authorized session, to a place the task did not need it. It can become a leak later, when the second application has wider readers, but no external boundary is crossed at the time, so leak-oriented controls do not fire.

Does the agent have to do something wrong for oversharing to occur?

No. The commonest case is an agent doing its task well and including one more detail than the task needed, because that detail was in its context. The failure is that the context held the value at all. Ordinary oversharing needs no attacker.

Can DLP catch an agent moving data between two internal applications?

Not as documented by the vendor reviewed here. Microsoft's answer on Purview DLP and Copilot Studio computer use states that the documentation does not describe enforcement against the agent's data-movement step inside its session. DLP is built around exits, and an internal write by an authorized session is not an exit. Check your own DLP vendor's documentation for the same scenario.

Why not label the data and track it through the model?

Because the tracking is the hard part. Siddiqui et al. show that under a conservative rule everything the agent writes after reading a confidential screen is confidential; under a permissive rule, deciding which inputs influenced an output is a research problem they approximate. Keeping the value out of the context avoids the question.

Does tokenizing identifiers stop the agent from finishing the task?

Not when the token is consistent. The agent matches ACCT_001 on one screen to ACCT_001 on another and completes the record update without holding the number. Amounts, dates and codes stay in clear by policy. The real value resolves only at an approved destination when a named person approves the action.

What is the quickest way to find out whether an agent is oversharing today?

Read its outputs. Take ten records the agent wrote last month and compare each against the task that produced it. Any identifier the task did not require is an event, and the share of records with one is the baseline. A planted marker string in a field the agent reads but should not reuse, searched for in destination systems, shows whether the carry-over path is live.

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.