Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Data Security?

AI agent data security is the set of controls that governs what data an agent can see, keep, move and act on while it completes work for a person. The field covers four separate moments, from what reaches the model before a run to the record reviewers use to reconstruct that run afterwards.

Images, tables and records pass a security gate before producing protected data and logs.

AI agent data security is the set of controls that governs what data an agent can see, keep, move and act on while it completes work for a person. The field covers four separate moments, from what reaches the model before a run to the record reviewers use to reconstruct that run afterwards. The discipline answers a question that older application security did not have to ask in this form: when a model reads screens, documents, messages and records as part of a task, what protects the values inside that material from being exposed, reused or sent somewhere they do not belong? It covers the data in the agent's context, the credentials the agent uses, the actions the agent takes with data, and the record left behind. The organizing principle 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

  • AI agent data security is distinct because the model itself becomes a data processor: material placed in its context is processed data, not merely stored data, and it can be repeated, transformed or carried into a later action (OWASP, 2025).
  • The OWASP Top 10 for LLM Applications places Sensitive Information Disclosure second among LLM risks in its 2025 edition, as LLM02, behind only Prompt Injection (OWASP, 2025).
  • Access control alone is an incomplete answer, because an agent usually works through a legitimate user's session and therefore inherits data that the user is entitled to open (NIST, 2020).
  • The NIST AI Risk Management Framework treats privacy and security as characteristics of trustworthy AI that must be managed across the system life cycle, not checked once at launch (NIST, 2023).
  • A complete control set addresses four separate moments: before the model reads data, while the agent acts, when a real value must be used at a destination, and after the run when the organization reconstructs what happened (Least Exposure governs the first; the AI Control Record governs the last).
  • Retention without a decision is the quiet fourth exposure: screenshots, transcripts and traces kept for debugging become a new sensitive store if they hold real values, which the NIST Privacy Framework's data minimization practices are designed to prevent (NIST, 2020).

What counts as data for an AI agent?

The first step is to count data the way an agent encounters it, rather than the way a database schema describes it. An agent working a claims queue, a billing inbox, or a student record does not receive neat fields from a single table. It receives rendered screens, attachments, message threads, notes written by staff, and values copied between systems. Any of those can contain identifiers, account numbers, health details, addresses, or commercially sensitive figures. A definition that only covers stored records misses most of that surface.

Three categories matter. Task data is the material the agent needs in order to reason: the invoice total, the date of loss, the enrollment status. Identity data links the work to a person or an account: names, policy numbers, patient identifiers, tax numbers. Credential data lets the agent operate systems at all: session tokens, passwords, and keys. The categories carry different risks and need different handling. Task data often has to reach the model in readable form. Identity data frequently does not, because the model can reason about a consistent placeholder instead. Credential data should never need to be read as ordinary content.

This counting exercise also changes how an organization thinks about copies. When an agent takes a screenshot, summarizes a record, or writes a value into a draft, it creates new representations of the same underlying data. Each representation is a place where exposure can occur, and each one needs a retention decision. AI agent data security therefore includes the life of those intermediate artifacts, not only the source system of record.

How is this different from general AI security?

General AI security is the broader field. It includes model supply chain integrity, training data poisoning, model theft, adversarial examples, and the safety of model outputs. AI agent data security is narrower and more operational. Its subject is the data that a deployed agent touches while doing assigned work in real systems. A model can be sound, unpoisoned, and correctly aligned, and an agent built on it can still expose a customer record by reading more of it than the task required.

It also differs from classic data loss prevention. Traditional DLP watches known channels, such as email, file transfer, and removable media, and looks for patterns that match sensitive content leaving an organization. An agent complicates that model in two ways. First, the risky transfer may be inbound: sensitive values move into a model context that the organization does not fully control. Second, the agent is an authorized actor using authorized channels, so a rule written for unauthorized exfiltration may never trigger. The relevant question shifts from whether data crossed a boundary to whether data needed to be present at all.

There is overlap, and none of this means discarding existing controls. Encryption in transit and at rest, identity management, logging, and DLP remain useful. The point is that they answer different questions. None of them, by itself, decides what a model should be shown during a specific piece of work. That decision is the core of this discipline, and it has to be made per task rather than per system.

What are the components of AI agent data security?

A workable control set can be described in five components, ordered by the moment each one applies.

Component Moment it applies Question it answers
Exposure policy Before the run Which values may the model receive for this task?
Transformation Before the model reads How are protected values replaced or withheld?
Action control During the run Which actions need a person's approval?
Resolution control At the destination When may a real value be used, and where?
Run record After the run What was seen, done, and approved, and by whom?

Exposure policy comes first because later controls cannot undo a value the model has already read. Transformation is the mechanism that enforces the policy, and it can take several forms: withholding a field, masking part of a value, or substituting a consistent token that preserves the relationships a task depends on. Action control addresses a separate risk. Reading data and changing data are different events, and an agent that may read a record should not automatically be able to submit, pay, delete, or amend it. OWASP names the failure of that boundary Excessive Agency, LLM06 in the 2025 list (OWASP, 2025).

Resolution control is the least discussed component and one of the most important. Many tasks end with a real value being needed somewhere legitimate: a payment must go to a real account, a letter must carry a real name. The control question is whether that value appears only at that approved destination, at that moment, rather than traveling through the whole run in readable form. The payments industry has used this idea for years; the PCI Security Standards Council's tokenization guidance describes a token as a stand-in that carries no value outside the system entitled to resolve it (PCI SSC, 2011). The run record then closes the loop. Without a record that ties screens, actions, and approvals together, the other four components are assertions rather than evidence an auditor can inspect.

Which data exposures does it have to prevent?

Four exposure patterns recur. The first is over collection at the point of reading, where a screen or record carries far more than the task requires and the whole thing enters the model context. OWASP describes the related failure as sensitive information disclosure, in which an LLM reveals or is given access to data it should not have (OWASP, 2025). The second pattern is leakage through output, where a value read in one step is written into a summary, a message, or a different customer's record. The third is leakage through an attack, where an instruction hidden in content the agent reads redirects it toward data it holds, which is the prompt injection pattern (OWASP, 2025).

The fourth pattern is quieter: retention without a decision. Screenshots, transcripts, traces, and evaluation logs tend to be kept because they are useful for debugging. If those artifacts hold real values, the organization has created a new sensitive store with its own access list and its own breach consequences, often without noticing. Good practice treats agent artifacts as in scope for the same retention limits and access reviews as the source records, and prefers artifacts that were generated from tokenized material in the first place.

Severity also depends on whose data is involved. Exposure of an employee's own working notes is a different event from exposure of a patient's, a policyholder's, or a student's record, where a regulator and a duty to the individual are involved. A policy that grades sensitivity only by field type will miss that. Reviewers should expect the sensitivity decision to consider the data subject and the regulatory context, not only the shape of the value.

How should an organization govern and measure it?

The NIST AI Risk Management Framework organizes risk work into Govern, Map, Measure, and Manage, and that structure fits this discipline well (NIST, 2023). Govern assigns an owner for agent data decisions and sets the organization's tolerance for exposure. Map requires an inventory of the workflows an agent performs and the data each one touches, which for agents means screens and documents as well as databases. Measure asks for evidence: samples of what the model actually received, tests with planted instructions, and counts of approvals and interventions. Manage turns those measurements into changes in policy, scope, or tooling.

Measurement deserves emphasis because agent data security is easy to claim and hard to demonstrate. Useful measures are concrete. A reviewer can ask what proportion of fields in a sampled workflow reached the model as real values, how many runs were stopped for approval, how many actions were reversed, and whether the run record for a randomly chosen task can be produced in full. Frameworks such as the NIST Privacy Framework add the complementary privacy view, including data minimization practices that limit processing to what a defined purpose requires (NIST, 2020). Together they give a buyer questions that a policy statement alone cannot answer.

Procurement is where these questions bite. A vendor security review for an agent should request one real screen as the model received it, the policy that produced that view, and the record of a completed run. Those three artifacts distinguish a control that operates at the point of reading from one that operates only in documentation.

Where does RedactSure sit?

RedactSure is built for those four moments within a single run. Before reading, render-layer tokenization replaces every identifier chosen by policy with a consistent token before any model reads the screen, so the model receives the task's fields with PATIENT_001 and ACCT_001 in place of the real values. While acting, Supervised Delegation governs the run: 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 that person approves every payment, submission and record change while it runs. At the destination, real values resolve only at approved destinations at the moment of an approved action. After the run, the AI Control Record preserves every screen as tokens, every action and every approval with a name, exported to the customer's own SIEM.

The environment runs in the customer's cloud with keys the customer holds, works across applications with no per-application integration and no change to user permissions, and is model agnostic. 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 draws on standards and framework publications from NIST, read as of October 13, 2026: the AI Risk Management Framework 1.0 (NIST AI 100-1, 2023, official guidance), the Privacy Framework Version 1.0 (2020, official guidance) and Zero Trust Architecture, SP 800-207 (2020, official guidance). It draws on the OWASP Top 10 for LLM Applications 2025, entries LLM01, LLM02 and LLM06 (industry standard), and on the PCI Security Standards Council's Tokenization Guidelines Information Supplement (2011, official guidance) for how the established concept of tokenization is defined in payments. Framework citations describe what those frameworks recommend, not what any given organization does.

The page does not report original testing, incident data, or measurements of any product. No product was evaluated, no agent was run, and no claim is made about the frequency of agent related data incidents, because no primary measurement of that frequency was found in the sources consulted. Vendor features and framework editions change; the page carries its date and is revised when the sources change. The claims queue, billing inbox and student record 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 and are identified as such in the text.

Whether a given control set meets an organization's obligations under HIPAA, FERPA, PCI DSS, the Privacy Act or any other regime is a determination for its counsel, assessor, privacy officer and compliance officer, not for the page. The frameworks cited set out questions and practices; they do not certify any product.

What the record shows

AI agent data security exists because the model is not a passive store. Once material enters its context, it is being processed by a system that can repeat it, transform it, and carry it into a later action, inside a session the user was entitled to open. Access control, which decides who may open a record, cannot by itself answer what happens to the values inside that record once an agent is reading it. The discipline follows the data through four moments: before the model reads it, while the agent acts, when a real value has to be used at a destination, and after the run, when someone must reconstruct what happened. A reviewer who tests all four will find gaps a launch checklist misses.

Frequently asked questions

How is AI agent data security different from data loss prevention?

Data loss prevention watches data as it moves toward an exit, such as an email, an upload, or a file transfer, and tries to stop sensitive values leaving. AI agent data security starts earlier, at the moment material is placed in a model's context, because processing inside that context is itself a form of exposure. The two overlap at the boundary where an agent sends data onward, but the agent discipline also covers what the agent was shown, what it retained during the run, and what record remains afterwards.

When should these controls be checked, once or continuously?

Continuously. The NIST AI Risk Management Framework treats privacy and security as characteristics that are managed across the system life cycle, not verified once at launch. An agent's tasks, the applications it reads, and the data they hold all change over time, so a control set that was adequate for the first workflow may not cover the fifth. Review belongs in the same cycle as the work: when a task, application, or data type is added, the four moments should be examined again.

How can a reviewer tell whether the controls are actually working?

By reconstructing a real run. Take one completed task and ask, in order, what the agent was shown before the model read it, what it kept while it acted, where real values were used, and what record the organization can produce. Controls that exist only as policy statements will leave at least one of those questions unanswered, usually the last one. A working control set leaves evidence at each moment, so the reviewer is checking artifacts of the run rather than descriptions of how runs are supposed to behave.

Does access control already cover what an AI agent can see?

No. Access control decides who may open a record. An agent usually works inside a legitimate user's session and inherits everything that user is entitled to open, which is normally far more than any one task needs. The missing decision is what the model should be shown for a specific piece of work, and it has to be made per task, before the model reads the screen, not per system at provisioning time.

What data does an AI agent handle that a database schema does not describe?

Rendered screens, attachments, message threads, staff notes, and values copied between systems. Three categories matter: task data the agent needs to reason, identity data that links the work to a person or account, and credential data that lets the agent operate systems. Each copy the agent makes, such as a screenshot, a summary, or a draft, is a new representation of the same data and needs its own retention decision.

What should a vendor security review for an AI agent ask for?

Three artifacts: one real screen as the model received it, the policy that produced that view, and the record of a completed run with its approvals. Those three distinguish a control that operates at the point of reading from one that exists only in documentation. Useful measures to request alongside them are the proportion of fields that reached the model as real values and the count of runs stopped for approval.

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.