Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Limit Data Exposure When Deploying AI Agents?

By applying data minimization at the moment the model reads, not only when data is collected: the agent opens the record it legitimately needs, but identifiers and regulated values are replaced with tokens before the model sees the screen. Check which fields the model read in the clear on a real record, and whether the task needed each.

A stack of detailed records is reduced to selected fields at a narrow boundary before reaching an agent ring.

By applying data minimization at the moment the model reads, not only when data is collected: the agent opens the record it legitimately needs, but identifiers and regulated values are replaced with tokens before the model sees the screen. Check which fields the model read in the clear on a real record, and whether the task needed each. Data exposure has traditionally been managed at the edges: collect less, retain less, block the upload. Agents move the problem to the middle. An agent that reconciles accounts or confirms appointments has to open the record, and the record arrives as the application renders it, with every field the user's role permits. Blocking the screen stops the work; allowing it exposes the whole record to the model, and through the model to whatever the model is steered to do. The way out is to treat the rendered screen as the point where minimization applies, so that the agent sees what the task needs and tokens for the rest. This page examines what exposure means for an agent and where it occurs, how minimization applies at runtime rather than at collection, which techniques limit what the model sees, what a single student record shows, how to measure exposure, and which claims a buyer should refuse. It extends the earlier definition of AI agent data exposure and the principle of least exposure to the practical question of deployment.

Key findings

  • European data protection law requires personal data to be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed, a requirement that applies to the model's reading of a screen as much as to a database schema (GDPR Article 5).
  • Sensitive information disclosure is a named risk in the security community's taxonomy for language model applications, and the disclosed information is whatever the model was shown (OWASP, 2025).
  • Tokenization as practiced in the payments industry replaces a sensitive value with a surrogate that has no exploitable meaning outside the system that holds the mapping, which is the property an agent's view of a record should have (PCI Security Standards Council, 2011).
  • Federal guidance on de-identification treats removing or replacing identifiers as a governed technique with residual risks, and the same discipline applies when the consumer is a model rather than a researcher (NIST, 2023).
  • Joint agency guidance on AI data security addresses protecting data used to operate AI systems, not only data used to train them, which places the data an agent reads at runtime inside the security perimeter (CISA, NSA, FBI and partners, 2025).
  • Browser-level masking is documented by at least one platform as a way to strengthen DLP in Chrome, so changing what a screen displays is an accepted control; whether it governs what a model reads is the open question (Google, 2026).

What does data exposure mean for an agent, and where does it occur?

Exposure is the set of values a model has read in the clear. It is not the set of values the agent was authorized to see, and not the set it needed; it is what actually reached the model. For a browser agent the exposure event is the render: the application produces a screen, the screen is passed to the model, and every value on it is now in the model's context, available to be reasoned about, repeated, or acted on. The security taxonomy names the downstream risk, sensitive information disclosure, and the disclosed information is whatever the model was shown (OWASP, 2025).

The exposure event is also where the attacker's content arrives. A planted instruction in a free-text field reaches the model on the same screen as the identifiers it would need to act on, so the exposure of the data and the exposure to manipulation coincide. Reducing what the model reads reduces both: a model that holds a token in place of an account number cannot be steered into sending the account number anywhere.

The joint agency guidance on AI data security extends the perimeter to cover this moment. It addresses securing data used to operate AI systems, not only to train them (CISA, NSA, FBI and partners, 2025). Operational data is the data an agent reads in a live record, and the guidance's framing makes the render, not the data warehouse, the place where a deployment's exposure is set. The earlier page on what AI agent data exposure is defines the term; this page is about reducing the quantity.

How does data minimization apply at runtime rather than at collection?

Minimization is usually read as a collection rule: gather only the data the purpose requires. The legal text is broader. Personal data must be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed (GDPR Article 5), and processing includes reading. When an agent's task is to confirm an appointment and the model reads the patient's diagnosis, the processing of the diagnosis is not limited to what the purpose required, however legitimately the record was collected.

The privacy framework from NIST supplies the operational vocabulary: data processing should be managed against defined purposes, with controls that limit processing to those purposes (NIST, 2020). For a human user, the control is training and role design, and the organization accepts that a person with a legitimate reason to open a record will see all of it. For an agent, the organization can do better, because the agent's view of the screen is constructed by software and can be shaped.

Runtime minimization, then, means deciding per workflow which fields the task needs in the clear and presenting the rest to the model as tokens. The record is unchanged, the human user's view is unchanged, and the model's view is limited to what is necessary for the purpose. University guidance on managing generative AI systems states the same rule in institutional terms, limiting what data is shared with an AI system to what the use requires (Harvard University). The difference between a collection-time rule and a runtime rule is that the runtime rule can be enforced on every screen, which is where exposure happens.

Which techniques limit what the model sees, and what does each cover?

Technique What it does, per the sources What a buyer should verify
DLP blocking Detects sensitive content and blocks the action or screen Whether a blocked screen stops the task, and how often detection misses
Browser data masking Google documents masking sensitive data in Chrome to strengthen DLP for users Whether the model reads the masked view or only the person sees it
De-identification Removes or replaces identifiers in a dataset under governed techniques Whether it applies to live screens or only to extracted datasets
Tokenization Replaces a value with a surrogate meaningful only inside the system holding the mapping Whether tokens are consistent across the run, and where they resolve

The techniques differ in where they act and what they leave usable. DLP blocking is binary: the content passes or the action stops, and a blocked agent cannot finish. Browser masking changes what a person sees; Google documents data masking as a way to strengthen DLP in Chrome (Google, 2026), and whether a model reads the same masked view is not described in the pages reviewed. De-identification is a governed discipline for datasets released to analysts (NIST, 2023). Tokenization replaces a value with a surrogate that has no exploitable meaning outside the system holding the mapping (PCI Security Standards Council, 2011).

For an agent that must open the record and act, the last property matters most: a consistent token lets the model track one account across screens without holding the value, and resolution at an approved destination lets the action complete. The comparison of an AI gateway, DLP and tokenization reaches the same conclusion.

What does a single student record show?

Take one record type, a student record in a student information system, and one task: an agent checks whether each student on a list has a completed immunization form on file and, for those who do not, drafts a reminder to the guardian. The record renders the student's name, student identifier, date of birth, home address, guardian name and phone, special education status, disciplinary notes, and the immunization form status with its date.

Without runtime minimization, the model reads all of it for every student on the list. The task needed the form status and date and a way to reach the guardian; it received the disciplinary notes and special education status, both regulated, for every student, and holds each guardian's phone number in the clear. If a disciplinary note contains text planted to steer the agent, the model reads it alongside everything it would need to act. The exposure is the full record multiplied by the length of the list.

With runtime minimization, the screen is changed before the model reads it. The model sees STUDENT_001, a guardian contact token, the form status and date in the clear, and nothing from the fields the task did not need, which are tokenized or withheld under the workflow's policy. The agent identifies the students without a form and drafts the reminder addressed to the contact token. At the moment the school's registrar approves the batch, the contact token resolves to the real phone number at the messaging system, and the message goes out. The model never held a name, an address, a phone number or a note. The exposure is the form status and date per student, which is what the purpose required, and the run record shows each screen as the model saw it. The same reasoning governs whether a platform's computer-use agent limits what it sees, where the answer depends on whether any control sits between the render and the model.

How should an organization measure exposure?

Count fields, not policies. For a sample of real runs, list each screen the model read and, for each screen, the fields present in the clear. Mark each clear field as needed or not needed for the task. The not-needed clear fields are the exposure the deployment failed to minimize, and their count per screen is the measure to track. A deployment that cannot produce this list has no exposure measurement, whatever its policy says.

Measure consistency as well. If the same account appears on three screens, the token for it should be the same on all three, and a token should never resolve anywhere except at an approved destination during an approved action. Sample the run record for both properties. The payments tokenization guidance treats the mapping system as the control point, and its security determines the strength of the whole scheme (PCI Security Standards Council, 2011); the same attention belongs on where an agent's tokens resolve.

Measure task success alongside exposure. A policy that tokenizes too much breaks the task, and the agent either fails or works around the gap in ways that may themselves expose data. The privacy framework's emphasis on managing processing against purpose cuts both ways: the fields the purpose requires should be present, and the fields it does not should be absent (NIST, 2020). A workflow with low exposure and high task completion is tuned; one with low exposure and failing tasks has been over-restricted; one with high completion and high exposure has not been minimized at all.

What does a governed environment change?

In a governed environment, data minimization is enforced at the moment the model reads, so the agent opens the record the task requires but the model receives only the fields the policy leaves in the clear.

The mechanism is a class of control that sits between the display and the model. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, and the task runs on those 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, including payments, submissions and record changes. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because exposure is a statement about what the model read, not about what the user's role permitted. The legal standard limits personal data to what the purpose requires (GDPR Article 5), and a role that permits a full record does not make every field necessary for one step. The tokens have the property the payments industry defined for a surrogate, no exploitable meaning outside the system that holds the mapping (PCI Security Standards Council, 2011). The artifacts asked for above are what the environment's record contains, and the open question about browser masking for users is settled by showing the model's input.

The control does not change the application, the user's permissions or the model; the agent still opens the full record, and the environment changes only which values are on the screen when the model looks.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design is runtime minimization as this page describes it. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so identifiers and regulated values reach the model as consistent tokens, such as ACCT_001 or PATIENT_001, for the whole run, and the fields the task needs remain in the clear. Real values resolve only at approved destinations at the moment of an approved action, which is how a reminder reaches a guardian's phone without the model ever holding the number. A named person confirms the tokenization policy for each workflow and approves every payment, submission and record change, which RedactSure 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, which gives the exposure measurement described above a source. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would produce the field count this page asks for: each screen as the model saw it, the fields in the clear, the fields tokenized, and the task completion rate under that policy. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on regulation, official guidance, an industry standard, institutional guidance and vendor documentation. Regulation is Article 5(1)(c) of the GDPR as published on gdpr-info.eu. Official guidance comprises the NIST Privacy Framework Version 1.0 (2020), NIST Special Publication 800-188 on de-identifying government datasets (2023), and the joint CISA, NSA, FBI and partner guidance on AI data security (2025). Industry standards are the OWASP Top 10 for LLM Applications entry on sensitive information disclosure (2025) and the PCI Security Standards Council's tokenization guidelines (2011). Institutional guidance is Harvard University's best practices for managing generative AI systems. Vendor documentation is Google's Workspace Admin Help page on data masking in Chrome (updated October 13, 2026). All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page. Where a vendor's documentation does not describe a capability, that capability is described as not described in the pages reviewed, not as absent; in particular, whether browser masking governs a model's input is stated as undocumented in the page read, not as unsupported. Regulatory text is quoted from the secondary source named. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The student record example describes a record type, not any organization; no district, customer or prospect is described.

Whether a given deployment's minimization satisfies the data protection, privacy and sector obligations that apply to an organization is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Limiting data exposure when deploying agents means moving minimization to the moment the model reads. Collection limits and retention rules still apply, but an agent that must open a record to do its work is exposed to whatever the record renders, and the legal and framework standards, limitation to what the purpose requires, apply to that reading. The techniques available differ in where they act: blocking stops the task, masking changes the person's view, de-identification governs datasets, and tokenization produces a screen the model can work from with the values absent and recoverable only at an approved destination. The measurement is a count of fields the model read in the clear that the task did not need, taken from real runs. The test is to name one agent and one task and ask for one screen as the model saw it; every clear field on it should have a reason.

Frequently asked questions

Is data minimization only about what we collect?

No. The legal text speaks of data being limited to what is necessary for the purposes for which it is processed, and reading a record is processing. An organization that collected a field lawfully still processes it unnecessarily when a model reads it for a task that did not need it. Minimization at collection and retention remains important; minimization at the point of reading is the addition agents make necessary, because they open far more records than any one person would.

Why not just block the agent from sensitive screens?

Because the task usually requires the screen. An agent confirming immunization forms has to open the student record; blocking the record blocks the work. Blocking is the right answer for screens the task does not need at all, and tokenization is the answer for screens it does need, where some fields are required and others are not. The two controls are complementary, and most workflows need both: block the screens with no purpose, tokenize the ones with a partial purpose.

Does tokenizing identifiers prevent the agent from doing its job?

Not for tasks that compare, match, route or draft. A consistent token identifies the same record across screens without revealing who it belongs to, so the agent can tell that STUDENT_001 is missing a form and address a reminder to that student's guardian token. Where a real value is required, as in sending the message, it resolves at the approved destination at the moment of the approved action, outside the model.

How is this different from de-identification?

De-identification is a discipline for datasets released to analysts, with defined techniques and a known residual re-identification risk. Runtime tokenization acts on a live screen inside a working session, keeps the record itself unchanged, and preserves a reversible mapping so that an approved action can complete with the real value. The techniques share a goal, removing identifiers from what a consumer sees, and differ in timing, reversibility and context, so a de-identification program does not substitute for a runtime control.

What should the exposure metric be?

Fields the model read in the clear that the task did not need, counted per screen over a sample of real runs. It is a direct count, not a policy statement, and it can be tracked over time and compared across workflows. Pair it with task completion under the same policy, so that a low exposure count achieved by breaking the task is visible as a failure rather than reported as a success, and review both figures when the policy changes.

Does masking data in the browser limit what the model sees?

The documentation reviewed describes browser masking as a control on what a person sees in Chrome, and it does not describe whether a model reading the page receives the masked view. The distinction matters because an agent may read the page's underlying content rather than its rendered pixels. A buyer should ask the vendor to show the model's input for a masked page before relying on masking as an agent exposure control.

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.