How Can a School District Let Staff Use AI on Student Records Without Exposing the Data? Reading FERPA, the PowerSchool Breach and the Sanctioned Path

Chris Sowa · Founder, RedactSure
Published September 17, 2026 · Last updated September 26, 2026

By giving staff a sanctioned path in which the AI model never receives the records. When student names, IDs and family details are replaced with consistent tokens at the screen, before any model reads them, district staff can put AI to work on attendance follow-up, intervention drafting, purchasing and state reporting while the education records stay where FERPA expects them: in the district’s systems, under the district’s control. Real values resolve only at approved destinations when a named staff member approves an action. The mechanism is render-layer tokenization; the principle is Least Exposure. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

FERPA’s school-official exception at 34 CFR 99.31(a)(1) permits disclosure to outside service providers only under conditions that include the district’s direct control over the provider’s use and maintenance of the records. An AI architecture in which the model never receives the records makes the control question far smaller.
The December 2024 PowerSchool breach exposed records of about 62 million students and 9.5 million teachers, through compromised subcontractor credentials on a support portal without multi-factor authentication. It is described as the largest breach of children’s data in U.S. history, and it happened without any AI involved.
The lesson districts drew is the right one: every additional system that holds student records is an additional way to lose them. An AI tool that ingests records is such a system. An AI architecture that reads tokens is not.
The demand is already inside the building: 78% of AI users bring their own tools to work, and teachers and district staff are AI’s fastest adopters. A district ban produces invisible use of student data, not absence of use.
The workflows districts most want to automate, attendance, interventions, budgets and state reporting, all name children. This is the K-12 face of the PII Wall.

What does FERPA actually require of an AI tool?

FERPA generally requires written parental consent before a district discloses personally identifiable information from education records, and then enumerates exceptions. The one every ed-tech product lives under is the school-official exception at 34 CFR 99.31(a)(1): a district may treat a contractor or service provider as a school official with a legitimate educational interest, if specific conditions hold. The provider must perform a service the district would otherwise use its own employees for. The district must maintain direct control over the provider’s use and maintenance of the education records. And the provider may use the records only for the authorized purpose and may not re-disclose them.

Now read those conditions against a generic AI tool into which a staff member pastes a student’s record. Direct control over use and maintenance means the district must be able to say where those records went, what the provider’s systems did with them, whether they entered model training, and how they will be destroyed. For consumer AI accounts the district cannot answer any of that, which is why district AI policies overwhelmingly prohibit putting student PII into such tools. The prohibitions are correct. They are also, on their own, incomplete, because the work the staff wanted to do still exists.

An architecture in which the model reads tokens changes what the FERPA analysis has to cover. The education records stay in the district’s student information system. What reaches the model is USER_001’s attendance pattern, not the child’s name and record. The provider’s use and maintenance of identifiable records shrinks toward the resolution events the district itself approves. Districts should run this analysis with their own counsel; the point is that the analysis becomes tractable, because the data flow it must trace is small and explicit.

What did the PowerSchool breach establish?

In December 2024, an attacker used compromised subcontractor credentials to enter PowerSource, the customer support portal of PowerSchool, the most widely used student information system in North America. The portal did not require multi-factor authentication. Records of about 62 million students and roughly 9.5 million teachers were taken: names, addresses, dates of birth, and for a subset, Social Security numbers, medical alerts, health conditions and disciplinary records. PowerSchool paid approximately $2.85 million in ransom for a deletion it could not verify; extortion attempts against individual districts continued months later. The attacker, a nineteen-year-old student, was sentenced to four years in federal prison in October 2025.

For district technology leaders the breach settled an argument. Children’s records are a target, the consequences are long (a child’s Social Security number is monetizable for decades), and every system holding the records is part of the attack surface, including the vendor’s own support tooling.

That lesson bears directly on AI procurement. An AI product that ingests student records to work on them becomes another repository of children’s data, another set of credentials, another subcontractor chain. The PowerSchool pattern does not require AI; it requires a system that holds the records. The strongest position a new system can offer a district is not better custody of student records. It is not holding them: the model reads tokens, real values stay in the district’s systems of record, and the vendor stores ciphertext it cannot decrypt, with the district holding the keys.

Which district workflows are behind the wall?

District workflow	What the screens contain	What the model reads under tokenization
Attendance follow-up	Student names, attendance history, family contacts	Attendance patterns keyed to USER_001; contacts tokenized, resolving on an approved send
Intervention and MTSS drafting	Grades, behavior notes, IEP and 504 references	The academic pattern the plan needs, with identity and diagnosis fields tokenized by policy
Budget and purchasing	Vendor bank details, employee data, quotes	Line items and quotes; account and identity values tokenized
State reporting	Enrollment and demographic detail	Aggregates and required fields assembled under tokens; real values resolve in the approved report at submission
Family correspondence	Names, addresses, student specifics	Draft built on tokens; identity resolves on the staff member’s approved send

Each row is work a district administrator has asked about AI for, and each is exactly where the district’s own policy says stop, because the screens name children. The pattern is the same wall documented across industries in What Is the PII Wall?, built here from FERPA-protected records. Meanwhile the staff, like workforces everywhere, are already AI users: Microsoft’s Work Trend Index records 78% of AI users bringing their own tools to work, and IBM’s 2025 research records one in five breaches involving shadow AI. A district with no sanctioned path has unsanctioned use, on personal accounts, invisible to the technology office.

What does the sanctioned path look like?

Inside a governed environment, the district’s own applications, the student information system, the finance system, email, the state portal, render as usual, and sensitive fields are replaced with consistent tokens before any model reads a screen. The tokenization policy is confirmed field by field by a named district employee before a workflow runs.

The agent then does the assembling and drafting on tokens. The staff member who owns the work, an attendance officer, a counselor, the business manager, supervises under Supervised Delegation: they can watch the run, and every consequential action, a letter to a family, a submission to the state, a purchase order, waits for their approval, on the record. The AI never sends, submits or decides. Real values resolve at the approved destination at that moment: the family letter carries the real name when the counselor approves the send, and not before.

Permissions do not change anywhere. Teachers and administrators see real records in the student information system under the same rights as today. The run history is recorded as tokens, so the district gets a complete audit trail that itself contains no student data. Districts that have learned to count their repositories will notice the log is not one of them.

School districts are already working this way in early deployments; the Scituate School Department in Rhode Island is among the districts working with RedactSure on this model.

The business office walk: purchasing to state report

The student-facing workflows get the attention, and the district business office is often where the sanctioned path proves itself first, because the work is heavy, the deadlines are statutory, and the records include both student data and the district’s financial details.

Take the spring purchasing cycle. The business manager delegates reconciliation: match open purchase orders against invoices and the budget lines, flag discrepancies, draft the board report. The agent works the finance system and the invoice inbox reading vendor names, bank details and employee identifiers as tokens, with amounts, PO numbers, budget codes and dates in clear. It matches, flags two duplicate invoices and one PO drawn against the wrong line, and drafts the report. The business manager reviews the flags, corrects the line, and approves the report for the board packet. Elapsed staff time is the review, not the reconciliation.

State reporting runs the same shape with student data. The enrollment and demographic extracts assemble under tokens, the agent checks them against the state’s edit rules, the flags surface before the deadline instead of as rejections after it, and the registrar approves the submission, at which point real values resolve in the approved report at the state portal, the destination that was always going to receive them. The model that assembled and checked the report never held a student’s name.

The business office cases matter strategically for a district’s AI program. They produce visible time savings in offices every board member understands, they involve the same architecture the student-facing workflows need, and they let the district build its supervision practice, exposure policies confirmed, approvals recorded, logs reviewed, on workflows where the community stakes are lowest. Corral first, automate second, and start the automation where the records are least sensitive: that sequencing is how a district earns the trust the attendance and intervention workflows will need.

What does federal guidance tell districts to check?

Districts do not have to invent their AI diligence from scratch. The Department of Education’s Privacy Technical Assistance Center has published guidance on online educational services for a decade, and its questions transfer to AI tools directly, because an AI tool is an online service that touches records.

The PTAC pattern asks districts to examine what data the provider collects, what the provider may do with it, whether the district retains direct control, what happens to the data at contract end, and what the provider’s security practices are, with the answers in the contract rather than in marketing. District technology directors know this checklist; many state student-privacy laws wrote versions of it into statute, and the student data privacy pledges and consortium contracts most districts use descend from it.

Applied to AI, the checklist gains one question that did not exist before: does the tool’s model receive student records, and if so, do they enter training, evaluation or vendor logs? For most consumer AI tools the district cannot get a contractual answer, which is why the bans exist. The architecture described here changes what the checklist finds at every stop. Data collected by the model: tokens. Provider use of records: the vendor cannot read what it stores. Direct control: the records never left the district’s systems of record. Contract end: keys are the district’s; ciphertext without keys is noise. The security practices question, hardened after PowerSchool, now covers a vendor that is not holding the crown jewels at all.

The general lesson for procurement is the one PTAC has taught all along: ask where the data goes, and prefer the architecture that makes the answer short.

What does the district tell the community?

Technology decisions in K-12 are community decisions, and a sanctioned AI path has to survive a school board meeting and a parent newsletter as well as a security review. The communication writes itself more easily than most technology announcements, because the design maps onto sentences a non-technical audience can check.

Staff use AI assistance for administrative work, and the AI never receives your child’s name or records. The records stay in the district’s own systems, where they have always been. A named district employee reviews and approves anything the AI drafts before it goes anywhere. The district can produce a complete log of what the AI read and did, and the log itself contains no student information.

Each sentence is an architectural fact rather than a policy promise, which matters at the podium: the difference between we have a policy against exposing records and the system does not show records to the AI is the difference between asking for trust and describing a mechanism. Districts that have weathered a breach notification cycle, or watched neighboring districts weather PowerSchool’s, will recognize which sentence they would rather be saying.

The same clarity serves the internal audience. Teachers and staff get a sanctioned tool that works, an honest answer to what it can see, and a bright line: student-facing and instructional uses run under the district’s separate acceptable-use policy, while the administrative workflows above are governed, logged and approved. A ban with no alternative asks staff to choose between the policy and the workload. A sanctioned path removes the choice.

Who does what in a district deployment?

A district is not an enterprise with a security operations center, and the model has to fit the staff a district actually has. The roles map onto existing jobs, which is most of why it fits.

The technology director owns the architecture decision and the vendor diligence, runs the PTAC-style checklist, and receives the audit trail. What the role does not become is the supervisor of every workflow, which is the trap district AI pilots fall into: a central owner who cannot judge an attendance letter or a purchase order becomes either a bottleneck or a rubber stamp.

The workflow owners supervise their own delegations, exactly as the Supervised Delegation model prescribes. The attendance officer confirms what the attendance workflow may see and approves the letters. The business manager owns purchasing and the board report. The registrar owns state reporting and approves the submission. Each already holds the permissions and the judgment for their own domain; the delegation adds a recorded structure to authority they already exercise.

The superintendent owns the sequencing and the community narrative: business office first, student-facing workflows after the supervision practice is established, and the four checkable sentences from the communication section above at the board meeting. The superintendent also owns the acceptable-use boundary, keeping the instructional question, which this architecture does not decide, cleanly separated from the administrative one, which it does.

Counsel, often shared or outside, owns the FERPA and state-law analysis against the small data flow this architecture leaves to analyze, and reviews the vendor contract against the school-official conditions.

Nothing on the list requires hiring. That is the test a district technology plan should apply to any AI proposal: if the governance model assumes staff the district will never have, the governance model is decorative. This one assumes an attendance officer, a business manager, a registrar and a technology director, which is to say it assumes a district.

What the record shows

A district can give staff a sanctioned AI path for attendance follow-up, interventions, purchasing and state reporting in which the model never receives a student record: identity tokenizes at the screen, the records stay in the district’s systems under the district’s keys, and a named staff member approves anything that leaves the building. The FERPA analysis becomes tractable because the data flow it must trace is small, and the PowerSchool breach, 62 million students’ records taken through a vendor’s own support portal, settled the argument for preferring an architecture that does not hold the records at all. The demand side is already in the building at the same 78% rate as every other workforce, so the choice is between a governed path and an invisible one. The roles required are the roles a district already has, the sequencing starts in the business office, and every sentence the superintendent needs at the board meeting is an architectural fact rather than a promise. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.

Frequently asked questions

Does this make an AI tool FERPA compliant?

No tool makes a district compliant; compliance belongs to the district’s whole program and its counsel’s analysis. What the architecture changes is the shape of that analysis: the model never receives education records, the records stay in district systems, and the school-official conditions are evaluated against a small, explicit set of resolution events the district itself approves.

Can teachers use it for instructional work?

The workflows described here are administrative: attendance, interventions, business office, reporting. Instructional AI use raises its own questions, and a district’s acceptable-use policy governs it separately. The architecture’s contribution is the same wherever it is applied: what the model sees is decided in advance, by policy, not by whatever is on the screen.

What about COPPA and state student-privacy laws?

The same design property does most of the work in each analysis: the model does not receive the child’s identifiable data. State student-data-privacy statutes, many of which restrict vendors’ use of student data, are evaluated by counsel the same way as the FERPA question, against the small set of approved resolution events.

Who at the district supervises the agent?

The person who owns the work: the attendance officer for attendance, the business manager for purchasing, the registrar for state reporting. Not the technology office, which instead sets the exposure policy with them and gets the audit trail.

What would the district tell a parent who asks?

That the AI drafting assistance used by staff never receives their child’s name or records; that a named staff member approves anything that leaves the district; and that the district can produce, from its logs, the full history of what any AI run read and did, with no student data in the log itself.

What does this cost a district relative to the risk?

Districts should weigh it as they weigh any control: against the workflows unlocked and the exposure avoided. The PowerSchool episode gives the exposure side a concrete floor; districts spent months on breach response, credit monitoring and family communication for a system they did not choose to expose.

Can the district’s existing AI ban stay in place?

Yes, and it should, for unsanctioned tools. The sanctioned path replaces the part of the ban that was failing: the invisible use on personal accounts. Corral first, automate second: bring the existing use into the governed environment, then let agents take on the valuable workflows inside it.

What Is the PII Wall? · What Is Render-Layer Tokenization? · What Is Supervised Delegation? · Can an AI Agent Work in PowerSchool Without Exposing Student Records? · Can an AI Agent Prepare Budget Transfers in Tyler Munis Without Exposing Vendor or Staff Data? · On the RedactSure blog: AI Is Already in Your Schools. Make It Safe and Useful.

Sources

Regulation

FERPA regulations, 34 CFR 99.31(a)(1), conditions for disclosure to school officials, including outside service providers. https://www.ecfr.gov/current/title-34/subtitle-A/part-99/subpart-D/section-99.31
U.S. Department of Education, Privacy Technical Assistance Center, guidance on online educational services and FERPA. https://studentprivacy.ed.gov/

Incidents and reporting

Security.org, “PowerSchool Data Breach: What Happened and What Families Should Do”; approximately 62 million students and 9.5 million teachers affected, December 2024. https://www.security.org/identity-theft/breach/powerschool/
PowerSchool, “PowerSchool Cybersecurity Incident” (company disclosure). https://www.powerschool.com/security/sis-incident/

Research and industry data

Microsoft and LinkedIn, Work Trend Index, “AI at Work Is Here. Now Comes the Hard Part.” https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part
IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach

RedactSure documents

RedactSure, “Secure AI for Schools and Campuses” (2026). https://redactsure.com/blog/secure-ai-for-schools-and-campuses/
Product behavior described on this page reflects RedactSure’s current design.

Bring your hardest questions.

A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.

Book a security review Book a demo · Something else

About the author

Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first 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.