Data Report · By Chris Sowa · Published
Last updated
How Do You Reduce the Risk of AI Agent Access to FERPA-Protected Student Records?
Treat the agent and its model provider as the school official exception treats any contractor, under the district's direct control with a legitimate educational interest, and arrange the deployment so the model never receives personally identifiable information from education records. Check what the model sees on each screen, who confirms that policy, and what record the district can produce.

Treat the agent and its model provider as the school official exception treats any contractor, under the district's direct control with a legitimate educational interest, and arrange the deployment so the model never receives personally identifiable information from education records. Check what the model sees on each screen, who confirms that policy, and what record the district can produce. FERPA has been applied to online educational services for more than a decade through the same exception that lets a district share records with a software vendor. An AI agent that reads a student information system screen is, for FERPA purposes, another party receiving education records, and the model endpoint behind it is another provider. The tests do not change; what changes is how hard they are to satisfy for a system that reads whole screens and sends them to a model the district does not operate. This page sets out what FERPA protects, what the school official exception requires of a contractor and how an agent fits, how a single student record illustrates the disclosure, why the safest posture is that the model never receives identifiable records, which official guidance supports that posture, and what a district should refuse when a vendor proposes an agent on student data.
Key findings
- FERPA's definitions in 34 CFR 99.3 make personally identifiable information reach direct identifiers, indirect identifiers and information that would let a reasonable person in the school community identify the student (34 CFR 99.3, 2026).
- The school official exception in 34 CFR 99.31(a)(1)(i)(B) permits disclosure without consent to an outside party performing an institutional service if it is under the agency's direct control with respect to the records and bound by the use and redisclosure limits that bind school officials (34 CFR 99.31, 2026).
- The Department of Education's Privacy Technical Assistance Center defines "provider" to cover the third-party vendors, contractors and other service providers that make online educational services available to schools and districts (PTAC, 2014).
- The Department's Student Privacy Policy Office reminded district leaders in August 2026 that, in general, student information may only be disclosed to an online educational service company in compliance with FERPA; the letter does not mention AI (U.S. Department of Education SPPO, 2026).
- CISA, NSA, FBI and partners have published best practices for securing data used to train and operate AI systems, treating the data an AI system operates on as an asset to protect (CISA, 2025).
- Whether the exception reaches an AI system turns on direct control and legitimate educational interest, both easier to evidence when the model never receives identifiable records (Does FERPA's School-Official Exception Cover AI?).
What does FERPA protect, and what counts as a disclosure to an agent?
FERPA protects education records, which 34 CFR 99.3 defines as records directly related to a student and maintained by an educational agency or institution or by a party acting for it, and it restricts disclosure of personally identifiable information from those records. The definition of personally identifiable information is broad: it includes direct identifiers such as name and student number, indirect identifiers such as date of birth and mother's maiden name, and other information that, alone or in combination, is linked or linkable to a specific student such that a reasonable person in the school community could identify the student with reasonable certainty (34 CFR 99.3, 2026).
Disclosure means permitting access to or releasing the information to any party. When an agent sends a student information system screen to a model endpoint, the district has permitted the model provider to access personally identifiable information from an education record. That is a disclosure, and it needs consent or an exception. That the model does not store the data, or that the vendor promises not to train on it, bears on what the recipient may do afterward, not on whether a disclosure occurred.
The breadth of the definition matters for agents in a particular way. A screen with the student's name removed but the date of birth, grade, school and a disciplinary note still present is linkable to a specific student by anyone in the school community. Minimization that removes a name and leaves everything else has not removed personally identifiable information under 34 CFR 99.3. The design question is therefore not which field to drop but which combination of fields reaches the model as real values.
What does the school official exception require, and how does an agent fit?
Districts share records with vendors every day under 34 CFR 99.31(a)(1)(i)(B), which permits disclosure without consent to an outside party performing an institutional service if it does work the agency would otherwise use employees for, is under the agency's direct control with respect to the records, is bound by the use and redisclosure limits that bind school officials, and has a legitimate educational interest (34 CFR 99.31, 2026).
| Test in the exception | Applied to an agent and its model provider | What a district should verify |
|---|---|---|
| Does work the district would otherwise use employees for | Clerical or analytical work staff would do | Is the task one staff perform today? |
| Under the district's direct control with respect to the records | The district sets what the model receives and what the agent does | Who configures the policy, and can the district change it? |
| Subject to use and redisclosure limits | The model provider may not use the records for other purposes or pass them on | What do the provider's terms say about retention and training? |
| Legitimate educational interest | The agent needs the records for the task | Does the task need identifiable records, or only their structure? |
PTAC defines "provider" to cover the third-party vendors, contractors and other service providers that make online educational services available to schools and districts (PTAC, 2014). The model operator is a provider if it receives the records. A district that cannot say what the model receives on a screen does not have direct control of them. Whether the exception covers AI at all is for counsel, and easier to answer when the model receives nothing identifiable.
How does a single student record illustrate the disclosure?
Consider a student record in a student information system. The screen shows the student's name and student number, date of birth, grade level, school, homeroom teacher, a list of courses with current grades, attendance totals, a special education services flag, a discipline incident with a short narrative, and a parent's name, phone number and email. A registrar asks an agent to check the schedule against graduation requirements and flag gaps.
As rendered, sending the screen to a model endpoint discloses personally identifiable information under every element of the 34 CFR 99.3 definition at once. The task does not need most of it. The schedule check needs the grade level, the course list and the credits earned. It does not need the student's name, number or date of birth as real values, the parent's contact details, the special education flag or the discipline narrative.
Now consider the same screen rendered with the identifiers substituted before the model reads it: STUDENT_001 for the name and number, DOB_001 for the date of birth, PARENT_001 and PHONE_001 for the parent's details, with the discipline narrative and services flag either substituted or left off the screen for this task. The agent still works one student across every screen in the session, because the same value maps to the same token. The model provider receives a course list and a grade level attached to a token. Whether that remains personally identifiable information under 34 CFR 99.3 is a determination for the district's counsel, but the direct control test is now easy to evidence, because the district can show exactly what the model received and that it chose it. The same holds for an agent working inside PowerSchool: the screen is the unit of disclosure.
Why is the safest posture that the model never receives identifiable records?
Because every test in the exception becomes easier, and some become unnecessary. If the model provider never receives personally identifiable information, the district need not establish direct control, redisclosure limits or legitimate educational interest for it, because no record was disclosed to it. The agent vendor operating the environment in the district's cloud remains a provider under direct control, documented in the usual way. The model, the component the district controls least, drops out of the analysis for the fields it never sees.
The NIST Privacy Framework supports settling these decisions in advance as deliberate, purpose-based choices about what data is processed for what task (NIST, 2020). A tokenization policy that names, for each screen type, which fields the model receives as real values and which as tokens is such a choice written down, and a named district official confirming it is the direct control test made concrete.
The posture also removes two risks the district bears regardless. A model holding real identifiers can be made to leak them through prompt injection; one holding tokens cannot. And a vendor's retention and training terms stop mattering for fields it never receives, which shortens procurement review. The joint CISA guidance on careful adoption of agentic AI services treats agents as needing deliberate controls over what they can access and do (CISA, 2026), and controlling what the model receives is the most direct such control.
What official guidance bears on agents and student data?
The Department of Education's Student Privacy Policy Office wrote to chief state school officers and superintendents in August 2026 to remind them that, in general, student information may only be disclosed to an online educational service company in compliance with FERPA (U.S. Department of Education SPPO, 2026). The letter does not mention AI, and that is the point: the Department is restating the existing rule for online services, and an AI agent that sends records to a model endpoint is an online service receiving student information.
Federal security agencies have addressed the AI side. CISA, NSA, FBI and international partners published best practices for securing data used to train and operate AI systems, which treats the data an AI system operates on as an asset to be protected through its lifecycle (CISA, 2025). CISA's separate joint guidance on the careful adoption of agentic AI services addresses the agents themselves.
Practitioner documentation offers an architectural parallel. Coder's best practices for running AI coding agents describe operating agents inside workspaces the organization provisions and governs (Coder, 2025). The principle transfers: run the agent in an environment the district operates, so that what it sees and does is the district's decision and record. None of these documents is FERPA guidance; what they share is the expectation that an organization running agents on sensitive data decides, in writing, what those agents can receive.
What does a governed environment change?
In a governed environment, the model never receives personally identifiable information from an education record, because the student information system renders to it with identifiers replaced by tokens and a named district official confirms that policy and approves each record change.
The mechanism is a class of control that sits between the display and the model. Sensitive values on the rendered screen, including the indirect identifiers and linkable combinations that 34 CFR 99.3 treats as personally identifiable (34 CFR 99.3, 2026), 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 record changes and communications. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the district's own logging.
This bears on the title question because the school official exception turns on direct control with respect to the records and on the use and redisclosure limits that bind school officials (34 CFR 99.31, 2026). A district that sets the tokenization policy, approves each action and holds the record of every screen the model received can evidence direct control in a way a contract clause cannot, and the disclosure question narrows, because receipt is the disclosure and the model receives tokens.
The control does not change the student information system, staff permissions or the model, and it does not make the determination; whether a disclosure satisfies the exception remains a decision for the district and its counsel.
Where does RedactSure sit?
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design is built so that the model never receives identifiable records. Agents run in a governed environment in the district's own cloud. Substitution happens at the render layer, before any model reads the screen, so the student record described above reaches the model with STUDENT_001, DOB_001 and PARENT_001 in place of the identifiers, with consistent tokens for the whole run so the agent can work one student across many screens. Real values resolve only at approved destinations at the moment of an approved action, such as a schedule change written back to the student information system after a registrar approves it. A named district official confirms the tokenization policy for each screen type and approves every payment, submission and record change under Supervised Delegation, which is the direct control test in operation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the district's SIEM. 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 run the agent on a real screen type in the district's student information system and hand counsel the screen as the model saw it, the confirmed policy, and the exported record for the pilot period. Everyone else controls where data can go. RedactSure controls what the AI can see.
Methodology and limitations
This page rests on the FERPA regulations at 34 CFR 99.3 and 99.31 as published on eCFR, the Department of Education's Privacy Technical Assistance Center guidance on online educational services, the Student Privacy Policy Office's August 2026 letter to state and district leaders, joint federal guidance from CISA and partner agencies on AI data security and on careful adoption of agentic AI services, the NIST Privacy Framework, and Coder's documentation on running AI coding agents in governed workspaces. Existing RedactSure research pages on student records, the school official exception, PowerSchool and tokenization are cited as evidence for the design points they document. All sources were read as of October 16, 2026.
No hands-on testing of any agent, student information system or product was performed for this page, and no determination is made about whether any design satisfies FERPA; the regulatory text is summarized as it reads on the cited pages and is not a legal interpretation. Where a vendor capability is described as "not described," that means it was not found in the pages reviewed. Regulations, guidance and vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The student record and graduation check examples describe a record type and a task, not any district or school; no customer or prospect is described.
Whether a given deployment's disclosures fall within the school official exception, whether tokenized screens remain personally identifiable information, and whether the arrangement meets state student privacy laws that go beyond FERPA are determinations for the district's counsel, its assessors and its own privacy and security officers, not for a research page.
What the record shows
Reducing the risk of agent access to FERPA-protected records comes down to applying the school official exception's tests, direct control, use and redisclosure limits and legitimate educational interest, to both the agent and the model behind it, and recognizing that a screen-reading agent discloses everything on the screen to the model provider unless the environment substitutes identifiers first. The definitions in 34 CFR 99.3 make name removal insufficient, because indirect identifiers and linkable combinations remain personally identifiable. The posture that satisfies the tests most easily is the one in which the model never receives identifiable records, which RedactSure's render-layer design is built to produce and document. The test is to name one agent and one task on a real screen in the student information system and ask what the model received, which district official confirmed that policy, and what record the district can hand to counsel.
Frequently asked questions
Is sending a student record screen to an AI model a FERPA disclosure?
Yes, if the screen contains personally identifiable information from an education record and the model provider is a party outside the district. Disclosure means permitting access to or releasing the information, and the model provider accesses it when the agent sends it. Whether the model stores the data or trains on it bears on what the provider may do afterward, not on whether a disclosure occurred. The disclosure needs consent or an exception.
Can the school official exception cover an AI agent and its model provider?
It can cover any outside party that performs a function staff would otherwise do, is under the district's direct control with respect to the records, is bound by use and redisclosure limits, and has a legitimate educational interest. Applying those tests to a model provider is hard when the district cannot say what the model receives. Counsel must decide for each deployment, and the decision is easier when the model receives nothing identifiable.
Is removing the student's name enough?
No. FERPA's definition of personally identifiable information includes indirect identifiers such as date of birth and information that, alone or in combination, would let a reasonable person in the school community identify the student. A screen with the date of birth, school, grade level and a discipline narrative remains identifiable with the name gone. Minimization has to address combinations of fields, which is why a per-screen policy matters more than a single redaction.
What does the model actually need to do a task like a schedule check?
The structure of the record and a few values: grade level, the course list, credits earned. It does not need the student's name, number or date of birth as real values, the parent's contact details, or the services and discipline fields. Consistent tokens let the agent work one student across screens while the model receives nothing identifying. The real values are needed only when an approved action writes back to the district's own system.
What does the Department of Education's 2026 letter say about AI?
Nothing directly. The Student Privacy Policy Office's August 2026 letter reminds state and district leaders that, in general, student information may only be disclosed to an online educational service company in compliance with FERPA. The letter does not mention AI. Its relevance is that an agent sending records to a model endpoint is an online service receiving student information, so the existing rule it restates applies.
What should a district be able to produce after a pilot?
The model's view of each screen type, field by field, with the policy confirmed by a named district official; the approval record for every action that changed a record or sent a communication, with the person who approved; and an exported log of every screen as the model received it and every action taken, held in the district's own systems. Those three artifacts are what direct control looks like when a district is asked to demonstrate it.
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









