Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Who Decides Which Data an AI Agent Can Access?

The owner of the data and the organization's classification policy should decide, per agent and per destination, with the decision recorded so an auditor can read it; in practice the agent builder or an inherited login decides by default. Check who signed off on each agent's data scope and where that signature is kept.

Classified document layers connect through policy controls to separate agent and data destinations.

The owner of the data and the organization's classification policy should decide, per agent and per destination, with the decision recorded so an auditor can read it; in practice the agent builder or an inherited login decides by default. Check who signed off on each agent's data scope and where that signature is kept. The question sounds procedural and is in fact the center of agent governance. An agent reads whatever its session can reach, and the session was usually set up by whoever built the agent, using whatever credentials were at hand. Nobody with responsibility for the records made a decision; a decision was made by omission. Governance frameworks from NIST, ISO and the United States federal government all place the decision elsewhere, with accountable owners and documented policy, and the regulations that govern specific record types, such as student records, name the conditions under which anyone, human or machine, may see them. This page sets out who decides by default, why the data owner and classification policy should decide instead, what a record-level regulation says about the conditions, how the decision should be recorded per agent and per destination, how to measure whether it holds, and which claims a buyer should refuse. It builds on the inventory question in what AI agent data access is and how much enterprise data an agent can reach.

Key findings

  • The NIST AI Risk Management Framework places accountability for AI risk with organizational roles under its Govern function, with policies, processes and documented responsibilities set before systems are deployed (NIST, 2023).
  • ISO/IEC 42001 defines an AI management system in which leadership assigns roles and the organization documents its controls, so decisions about AI are organizational decisions rather than developer choices (ISO, 2023).
  • OMB Memorandum M-24-10 directs federal agencies to name Chief AI Officers, inventory AI use cases and apply minimum practices to rights-impacting uses, placing the data access decision at an accountable executive level (Office of Management and Budget, 2024).
  • Under FERPA, a contractor or other outside party may be treated as a school official only when it performs an institutional service, is under the direct control of the institution with respect to the use and maintenance of education records, and is bound by the redisclosure limits (eCFR, 34 CFR 99.31, 2026).
  • Gartner's position is that uniform governance across all agents leads to failure, which means the access decision must be made per agent rather than once for the fleet (Gartner, 2026).
  • A decision not recorded against each agent cannot be audited; an audit depends on a record naming the agent, the data and the approver (How to audit sensitive data access across enterprise applications?).

Who decides by default, and why is that the wrong person?

Take a student record in a student information system: name, student identifier, date of birth, address, grades, attendance, disciplinary notes, special education status. An agent built to send attendance reminders to families is given a login. Whose login decides what the agent can read. If it is the builder's own account, the agent reads everything the builder can read, which in a district office is often the whole record for every student. If it is a service account created for the purpose, the agent reads whatever the person creating the account granted, and that person is usually the builder again, choosing a scope broad enough to make the agent work on the first try.

In neither case did the registrar, the data owner for student records, decide anything. The classification policy, which may mark disciplinary notes and special education status as restricted, was not consulted. The decision was made by the person with the least responsibility for the records and the most interest in the agent working.

Developer-oriented guidance acknowledges this pattern and tries to narrow it. Coder's best practices for running AI coding agents recommend scoped, ephemeral environments with explicit boundaries on what the agent can reach, so that the agent's access reflects a decision rather than the developer's full standing (Coder, 2026). That is the right instinct and it is still a developer deciding. The structural fix is to move the decision to the owner of the data, with the builder implementing a scope the owner has set. OWASP's entry on excessive agency names the same risk from the application side: an agent granted more permission than its function needs (OWASP, 2025).

Why should data owners and classification policy decide, not the agent builder?

Because every governance framework written for AI assigns the decision to accountable organizational roles. The NIST AI Risk Management Framework's Govern function calls for policies, processes and documented roles and responsibilities for AI risk, established at the organizational level before the Map, Measure and Manage functions are performed on any system (NIST, 2023). An agent builder choosing a scope on the fly is operating without the Govern function having run.

ISO/IEC 42001 reaches the same place through management-system structure. It asks leadership to assign roles and responsibilities, to set policy, and to document the controls the organization applies to its AI systems, so that an auditor can trace a decision to a role and a policy rather than to a configuration someone made (ISO, 2023). For a United States federal agency, OMB Memorandum M-24-10 is more specific still: a Chief AI Officer, an inventory of AI use cases, and minimum risk management practices for uses that affect rights or safety, with the decision about whether and how an AI system touches personal data sitting inside that structure (Office of Management and Budget, 2024).

The practical reason is simpler. The data owner knows which fields are restricted and why, and the classification policy already encodes those decisions for human users. An agent is another reader of the same records, and the decision about what it may read should come from the same place as for a new employee: the owner, applying the policy, for this task. The builder's job is to make the agent work within that scope; the attendance agent works with a student identifier as a token and the disciplinary notes never rendered.

What does a record-level regulation say about the conditions?

FERPA is useful here because it was written for a specific record type and names the conditions. The regulation defines education records as records directly related to a student and maintained by an educational agency or institution, and defines personally identifiable information to include direct identifiers such as name and student number as well as indirect identifiers and information that would allow a person to identify the student with reasonable certainty (eCFR, 34 CFR 99.3, 2026). Every field on the student record in the worked example falls under one or both definitions.

Disclosure without consent is permitted to school officials with a legitimate educational interest, and the regulation extends that category to a contractor, consultant, volunteer or other party only when the party performs an institutional service or function for which the institution would otherwise use employees, is under the direct control of the institution with respect to the use and maintenance of education records, and is subject to the redisclosure requirements (eCFR, 34 CFR 99.31, 2026). Read against an agent, those conditions are a job description for the person who decides. Someone at the institution must determine that the agent's task is an institutional function, must be in a position to exercise direct control over what the agent does with the records, and must be able to show that the agent cannot redisclose. A builder who grants a service account cannot show any of the three. A registrar who sets a per-task scope, with a record of what the agent read and where it sent anything, can.

The point generalizes. Regulations for health, financial and government records set comparable conditions on who may see a record and for what purpose, met by an accountable owner applying policy, not by a configuration.

How should the decision be recorded per agent and per destination?

A decision that lives in someone's memory, or in a ticket closed a year ago, is not one an auditor can use. The record has to answer, for each agent, what it may read as values or as tokens, and for each destination, what may arrive there as a real value. An agent may need the student's real email address at the email system when the reminder is sent, and must never need it in the model's context or in a log.

Decision Who makes it Where it is recorded
Which fields on each screen the agent reads as tokens Data owner, applying the classification policy The agent's confirmed tokenization policy, signed by a named person
Which fields remain readable because the task depends on them Data owner with the workflow lead The same policy, with the task justification
Which destinations may receive a real value, and which values Data owner and security A per-destination resolution list attached to the agent
Which actions require a person to approve before they execute Workflow lead and compliance The agent's approval rules, with the approver's role named
What the agent read, did and who approved it on each run Produced by the environment, not decided The run record, exported to the organization's logging

Per agent is the unit because agents differ; Gartner's warning that uniform governance across AI agents leads to failure rests on this, since the attendance agent and an agent that updates grades carry different consequences (Gartner, 2026). Per destination is the unit because the real value must go somewhere eventually, and that list is short and knowable. A decision recorded in this form is the input to the run record that an audit of sensitive data access across applications needs.

How should an organization measure whether the decision holds?

Three measurements. First, coverage: of the agents in use, how many have a recorded data scope signed by the data owner. The denominator is the hard part, because agents appear without announcement, and a shadow agent reading customer data has no recorded scope by definition. Inventory before measurement.

Second, enforcement: for an agent with a recorded scope, does the run record show that the scope held. Compare the fields the policy says are tokens against the screens the agent actually read, and compare the destinations that received real values against the per-destination list. Zero trust architecture frames the same check as a policy decision point and a policy enforcement point, with access evaluated per request rather than granted once (NIST, 2020); an agent's recorded scope is the policy, and the environment it runs in is the enforcement point, so the measurement is whether the two agree on every run.

Third, drift: how often the scope changed, who changed it and whether the data owner signed the change. A scope that the builder can widen without the owner noticing is a scope that will widen. Guidance for coding agents already points toward narrow, bounded environments with explicit limits on reach (Coder, 2026); the measurement is whether the limits, once set by the owner, stayed where they were set. Tools that discover and classify data at rest answer a different question, which data exists and who holds standing permission to it; that approach and per-task control of what an agent reads are complementary measurements.

What does a governed environment change?

In a governed environment, the data access decision is made by a named person before the agent runs and enforced on every screen the agent opens, instead of being inherited from whichever login the agent was given.

This class of control works at the rendered screen, not in the application's permission model. Sensitive values on each screen are replaced with consistent tokens before any model reads them, so the agent performs its task on tokens. Real values resolve only at an approved destination at the moment of an approved action, so the short, named list of destinations that may receive a real value is a setting someone chose, not a description of what the agent did. A named person confirms what is tokenized for each agent, and a named person 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.

For this page's question, that supplies two things the default arrangement lacks. The decision exists as a per-agent record naming the agent, the fields and the destinations, which is what the Govern function's documented responsibilities require (NIST, 2023). And the direct-control condition that a record-level regulation imposes on an outside party handling education records has something to point to, since the institution rather than the model decides which values leave the screen (eCFR, 34 CFR 99.31, 2026). A log then shows what happened and the decision shows what was permitted, and an audit can find the difference.

The environment does not change the application, the permissions already set for people, or the model; it adds the decision the agent would otherwise make for itself on each run.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design puts the decision where this page says it belongs and records it. A governed environment runs in the customer's cloud; substitution happens at the render layer before any model reads the screen, 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. A named person confirms the tokenization policy for each agent and task, and approves every payment, submission and record change, which the company calls Supervised Delegation; that confirmation is the data owner's decision in recorded form. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, so the decision and the evidence that it held sit side by side. The environment is model agnostic, needs no per-application integration and leaves user permissions unchanged.

Deployments are in pilot. On the reader's own workflow, a pilot would show who confirmed the scope for one agent, which fields it read as tokens, which destination received a real value and who approved that action. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the NIST AI Risk Management Framework 1.0 (2023; official guidance), the ISO/IEC 42001 standard summary (2023; standard), OMB Memorandum M-24-10 (2024; official guidance), the FERPA regulations at 34 CFR 99.3 and 99.31 as published on eCFR (2026; regulation), NIST Special Publication 800-207 (2020; official guidance), OWASP's LLM06:2025 entry on excessive agency (2025; standard), Coder's documentation on running AI coding agents (vendor documentation), Gartner's May 2026 press release on agent governance (industry analysis) and RedactSure research pages. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed. Where a vendor's practice is described, the description comes from the pages reviewed, and "not described in the pages reviewed" means exactly that. Vendor features change, and the page carries its date. The governance frameworks are summarized at the level of their structure and functions; the page does not assess any organization's conformance with them. The FERPA passages are summarized from the regulation's text and are not legal advice; how the school-official exception applies to a particular agent is a question for the institution's counsel. Statements about RedactSure describe its current design, with deployments in pilot. The student record and attendance agent used as a worked example describe a record type and a task, not any district or institution.

Whether a given agent's recorded scope, approval design and run record satisfy 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

Who decides which data an agent can access is, by default, whoever built it, through whichever login it was given, and that is the wrong person applying no policy. Every governance framework written for AI, from NIST's Govern function to ISO/IEC 42001 to OMB M-24-10, moves the decision to accountable organizational roles, and record-level regulations such as FERPA name conditions, including direct control over use, that only an owner applying policy can meet. The decision has to be made per agent, because agents differ, and per destination, because the real value must eventually go somewhere, and it has to be written down next to the evidence that it held. RedactSure's design records it as a named person's confirmation of the policy for each agent and task. The test is to name one agent and one task and ask who signed its data scope and where that signature is.

Frequently asked questions

Is the agent builder ever the right person to decide?

The builder is the right person to implement the scope and the wrong person to set it. Builders know what the agent needs to function; data owners know which fields are restricted and why. When the two disagree, as they will when a task is easier with a wider scope, the owner's decision governs and the builder redesigns the task to fit it. A tokenized identifier usually satisfies both, since the agent can recognize the record without reading the restricted value.

What is a data owner in this context?

The role accountable for a record type under the organization's own policy: the registrar for student records, the privacy officer for patient records, the controller for financial records. Most organizations already name these roles for human access decisions. The change an agent introduces is that the owner must now decide for a reader that is not a person, has no legitimate curiosity, and can be given a narrower scope than any employee would accept.

Does the classification policy already answer the question?

It answers half of it. A classification policy marks fields as public, internal, confidential or restricted and says who may see each class. It does not say which fields a specific agent's task depends on, or which destination may receive a real value when the task completes. Those two decisions must be made per agent, using the policy as the input, and recorded alongside it. Without them the policy is applied to the agent by accident, through whatever login it was given.

How does FERPA's school official exception apply to an agent?

The exception lets an institution disclose education records without consent to an outside party that performs an institutional function, is under the institution's direct control regarding use and maintenance of the records, and is subject to redisclosure limits. An agent vendor can satisfy those conditions only if someone at the institution sets and controls what the agent reads and where it sends anything, and can show it. Whether a given arrangement qualifies is a question for the institution's counsel.

What should the recorded decision contain?

For each agent: the fields on each screen it reads as tokens, the fields that remain readable with the task reason for each, the destinations that may receive a real value and which values, the actions that require a person's approval before execution, and the name and role of the person who confirmed all of it, with a date. The record should sit next to the run logs so an auditor can compare what was permitted with what occurred.

How often should the decision be revisited?

Whenever the agent's task, tools or destinations change, and on a fixed schedule otherwise, because screens change under agents without anyone announcing it. A field added to a record type is a field the agent now reads unless the policy is re-examined. The practical trigger is any change to the agent's configuration, with the data owner signing the revised scope before the changed agent runs, and the run record showing which version of the scope each run used.

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.