Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can an AI Agent See in a Student Information System?
Everything the student profile renders: the legal name, date of birth, grade level, attendance history, grades, discipline entries, special education status, clinic notes and guardian contact details. Ask what the model receives from each rendered screen and who approves a change to the record.
A district's student information system holds the fullest record of a child that any school office keeps, and the same office is now asked to let an agent read it. Enrollment paperwork, attendance corrections, grade changes, guardian updates and state reporting all pass through one profile screen, and each of those tasks has a vendor offering to automate it. The agent opens the page a clerk opens, inside a session the district already trusts, and the page draws every field the record holds. The task in front of it needs a name, a date and a code.
The gap is easy to miss because the controls a district already owns look like they answer it. Account provisioning, security groups and role assignments decide which buildings a staff member can reach, and an access review asks who holds which group. Those controls decide who may open a record. They do not decide what a model is shown once the page is open, and a page built for a person carries more than the task in front of it.
A student profile is the record to follow, because it is the page an agent opens first in almost every task and the one with the widest set of protected categories on it.
Key findings
- For an agent to work a student profile without carrying the record's identifiers, the fields on the rendered page would have to be replaced with consistent tokens before the model reads it, so a guardian's phone arrives as PHONE_014 and a clinic note as HEALTH_002 (What Is Render-Layer Tokenization?).
- It would also require a named person approving each attendance correction, grade change and guardian update, with a record of what the model received on each screen, exported to the district's own monitoring (What Is the PII Wall?).
- None of the vendor pages reviewed states what a model receives from the rendered profile; PowerSchool's release calls the company "committed to being a good custodian of student data" and names no privacy statute (PowerSchool, 2026).
- North Carolina's enrollment guide walks a clerk through name, "the student's date of birth in the DOB field (format: MM/DD/YYYY)", gender, grade level, entry code, ethnicity and race, and it marks the Social Security number optional (North Carolina Department of Public Instruction, 2026).
- A benchmark of autonomous web agents found them "prone to inadvertent use of unnecessary sensitive information," the failure mode a full student profile invites (Zharmagambetov et al., 2025).
- Adaptive attacks bypassed 12 published defenses with an "attack success rate above 90% for most," so a page that carries untrusted text into an agent's context is a live path (Nasr et al., 2025).
What does an agent read when it opens a student profile?
The record is a student profile: the page an enrolling clerk, an attendance secretary or a counselor opens for one child. It draws the legal name, date of birth, grade level, enrollment status, schedule, attendance history, grades, discipline entries, special education or 504 status, clinic notes and guardian contacts. A browser agent reads what the page renders, so labels, values and their order arrive as text, and a capture of the same screen arrives as an image (What Does an AI Agent See in a Screenshot?).
North Carolina's enrollment guide is specific about the first screen. It walks a clerk through the fields a new student record carries: name, "the student's date of birth in the DOB field (format: MM/DD/YYYY)", gender, grade level, entry code, ethnicity and race (North Carolina Department of Public Instruction, 2026). The guide is a 2017 revision for one state's PowerSchool districts, so a later release may put a field on a different tab. Submitting the form queries the state identifier system, because "The Student UID system is queried and results of the query are presented" (North Carolina Department of Public Instruction, 2026).
| Field on the student profile | What the page draws | What the model receives without a control |
|---|---|---|
| Date of birth | The date as MM/DD/YYYY | The date |
| Special education status | The IEP or 504 flag and the service minutes | The flag and the minutes |
| Clinic note | Visits, medication and allergy notes | The note as written |
| Guardian card | Names, phone numbers, email addresses, custody flags | Every value on the card |
| Discipline entry | Incident, date, consequence, staff member | The entry as written |
The task touches two of those fields. The rest sit on the page because a person may need them: the clinic note for a nurse's call, the guardian card for an absence, the discipline entry for a conference. A clerk reads past most of the page; the model reads the page. A page that carries a clinic note beside an attendance code hands over both, and indirect injection reaches an application through text it reads rather than an interface an attacker owns (Greshake et al., 2023).
Which fields on a student profile carry the most protected data?
Five fields do most of the damage. The name with the date of birth identifies a child across systems and survives every correction. The Social Security number is the identifier a district cannot reissue. The clinic note and the special education status describe a child's body and the services the district owes, and a discipline entry can follow a student through a transfer. The guardian card carries phone numbers, email addresses and sometimes a custody restriction a school must honor. Dr. Judy White, retired Riverside County Superintendent of Schools, described the pattern on a HAL podcast: "If the teachers are putting referrals in the system, when you get to a place of expulsion, you're able to see a pattern" (Does the Need-to-Know Rule Survive AI? A Former County Superintendent on Student Records).
Which of those the task needs is a separate question from which of them the page draws. An attendance correction needs the identifier, the date and the attendance code; it does not need the clinic note, the guardian's mobile number or the Social Security number. OWASP's entry for sensitive information disclosure records that "Personal identifiable information (PII) may be disclosed during interactions with the LLM," a description of the exposure that does not say where the control belongs (OWASP, 2025). The same entry lists "unauthorized data access, privacy violations, and intellectual property breaches" among the outcomes (OWASP, 2025).
The Social Security number is the clearest case for a field that should not be in the model's context at all. North Carolina's guide prints the prompt with its own answer built in, "Enter Social Security Number (It is permissible to ask; if provided, enter; if denied, leave blank) (Optional)", so the field is optional and the page says so (North Carolina Department of Public Instruction, 2026). A district that collects it holds it one row below the date of birth on the same profile, and nothing on the page marks it as unrelated to the task.
What do the vendors themselves say?
Three pages bear on this question: an enrollment guide from one state's education department, a security deck for district administrators, and PowerSchool's announcement of its family assistant. Each documents the part of the system it covers, and none is a specification for what a model receives.
| Dimension | What the documentation states | What a buyer should verify |
|---|---|---|
| Enrollment fields | The guide asks for name, "the student's date of birth in the DOB field (format: MM/DD/YYYY)", gender, grade level, entry code, ethnicity and race (North Carolina Department of Public Instruction, 2026). | Which of those fields the agent's task actually needs |
| Group scope | "System-wide indicates access to all data district-wide" or "Location-wide indicates access to only building data based upon the user's active locations in SIS" (Alabama State Department of Education, 2026). | Whether the agent runs under a person's group or its own |
| Assistant reading | The family assistant answers "How many absences has my child had this year?" and "What is my child's grade in English?" from the student system (PowerSchool, 2026). | What the assistant's model receives from the page |
The group model is where a district's existing governance sits. Membership comes from the student system rather than from a list an administrator maintains, since "Membership is assigned based upon the PS SIS Role assignments" the first time a user signs in through single sign-on (Alabama State Department of Education, 2026). The deck also warns that removing a user by hand does not stick, because the mapped role returns the membership at the next sign-in (Alabama State Department of Education, 2026). It covers Special Programs and the role mapping rather than core student system security.
The assistant is the closest thing to an agent in these pages. PowerSchool's release says it answers questions such as "How many absences has my child had this year?" and "What is my child's grade in English?" by drawing on the student information system (PowerSchool, 2026). The release says only that the company is "committed to being a good custodian of student data," and FERPA appears nowhere on the page (PowerSchool, 2026). A launch announcement with executive quotes is not a privacy statement.
What none of these pages describes is what a model receives when the rendered profile is handed to it; that behavior is not described in the pages reviewed. Whether the values on the page are replaced before a model reads them is a separate design choice, and no page here makes it.
Who approves a change an agent makes to a student record?
The student system's own governance answers a different question. A group's reach is set as either "System-wide indicates access to all data district-wide" or "Location-wide indicates access to only building data based upon the user's active locations in SIS" (Alabama State Department of Education, 2026). That decides which records a person may open, and the deck does not describe a second person signing off on a change an agent makes inside that access.
An approval that arrives after the agent has read the profile does not undo the reading. A counselor who declines a grade change leaves the date of birth, the clinic note and the guardian's phone number in the context the agent built before it asked, and a later step in the run sees the same transcript. A record of what the model received is the part that survives the approval (Does the ChatGPT Compliance API Record What the Agent Did in the Browser?).
Colorado's SB26-189, signed on May 14, 2026, covers automated decision tools that are "a non-de minimis factor that is used in making a consequential decision," a list that reaches "educational enrollment or opportunity," and it adds "recordkeeping requirements for at least three years" (Goodwin, 2026). Most of the law's provisions take effect on January 1, 2027, and the alert is a law firm's summary rather than the statutory text (Goodwin, 2026). A district outside Colorado is not bound by it, and the shape is the same everywhere: a record of what the tool read, what it decided and who answered for the decision. The National Conference of State Legislatures tracked 1,143 AI bills in 2025; 9 required a person to review an AI decision, and 1 was enacted (How Many AI Laws Require Human Review of AI Decisions?).
That shapes the approval a district should ask for. A named person approves the specific attendance correction, grade change or guardian update, and the approval sits beside a statement of the screens the agent read. An approval that names the agent's access in general, rather than the change in front of it, leaves the reading out of the record.
What should a district ask for in writing before an agent reads the SIS?
Three answers, in writing, before a pilot starts. The first is what the model receives from a rendered screen, in the district's own applications rather than in a demonstration. The second is who approves each record change, by name and by role. The third is what record the district receives of the screens, the actions and the approvals.
The first question carries the legal weight. The 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 (How Can Schools Use AI Without Exposing Student Records?). A district that cannot say which values a vendor's model received has little to show when the question is asked.
The PowerSchool breach of December 2024 took records of about 62 million students and 9.5 million teachers through the vendor's own support portal, and the attacker was sentenced to four years in October 2025 (Can an AI Agent Use PowerSchool Without Student PII?). An investigation into an agent's run asks the questions a breach review asks: which records were opened, by what, and what was taken.
A district can test the answers on one workflow rather than the whole system. Pick an attendance correction for a single student, run it with test values, and compare what the clerk's screen showed with what the run record says the model received and who approved the change. A vendor that cannot support that comparison on one screen will not support it across a district, and the same test applies to any browser agent a school allows (ChatGPT Atlas, discontinued in August 2026).
What does a governed environment change?
It moves the control to the point where the page is built. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.Values that a district's policy names are replaced with consistent tokens before any model reads the screen, so the profile renders as STUDENT_014, GUARD_002, HEALTH_003 and IEP_001 and keeps those labels through the run, in the summary the agent writes and on the next screen it opens.
Real values resolve only at an approved destination, at the moment of an approved action. For an enrollment, that is the registrar's approval of the submission; for a grade change, the counselor's approval of the correction. The model that drafted the work does not hold the values at any point, and the person who approves sees them where the action lands.
A named person approves each attendance correction, grade change and guardian update, and every screen as tokens, every action and every approval is written to a record that exports to the district's own monitoring. That record answers the question a school board asks after a parent complaint: what did the agent see, what did it change, and who said yes.
The scope is the rendered page. A control of this kind covers what the agent reads and does on a page in a browser, and a direct API integration, a nightly export or a report built from the warehouse is a different path with its own controls.
For the student profile the change is concrete. Before, the model read the legal name, the date of birth, the clinic note and the guardian card as page text, and any later step in the run could repeat them. Inside, the same profile renders STUDENT_014, DOB_014, HEALTH_003 and GUARD_002, the agent drafts the attendance correction on those tokens, a named administrator approves, and the real values resolve at the attendance record rather than in the model's context.
What the record shows
The control that answers this question sits on the rendered profile, not on the account: the values a district's policy names replaced with consistent tokens before any model reads the screen, a named person approving each record change, and a record of what the model received. On that reading, the student information system is the district's most sensitive application, because one page carries a child's demographics, attendance, grades, discipline entries, special education status, clinic notes and guardians, while the task needs three fields. The vendor pages document fields, groups and questions, and they leave the model's view of the page undescribed. A district can check its own stack by opening one student profile in a test tenant, naming the fields it would never read aloud in a meeting, and asking what the model receives for each one and who would appear in the record if it changed.
Methodology and limitations
This page rests on vendor and agency documentation: an enrollment guide from a state education department, a district security deck, a vendor announcement, three research preprints, an industry standard entry and a law firm's alert. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. The enrollment guide is a 2017 revision for one state, the security deck covers Special Programs and the role mapping rather than core system security, and the announcement is a launch release.
No product on this page was tested for it. The products are described from their public documentation, and "not described in the pages reviewed" means the recorded pages do not state the point. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a student profile, not an organization. Determinations about whether a practice meets a legal or contractual requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the district's own screens.
Frequently asked questions
What can an AI agent see in a student information system?
Everything the profile page renders. A student record draws a legal name, a date of birth, a grade level, attendance history, grades, discipline entries, special education status, clinic notes and guardian contact details, and an agent that opens the page in a staff session receives those values as text. What changes the answer is whether the values are replaced before the model reads the screen, and who approves a change to the record.
Does a security group limit what an agent reads in the SIS?
No. A security group decides which building's data a person can open. Alabama's deck sets a group's scope as "System-wide indicates access to all data district-wide" or location-wide for a single building, and membership follows the role assigned in the student system. That governs who may open the record. It says nothing about what the page hands the model once the record is open.
Do student records hold Social Security numbers an agent could read?
Sometimes. North Carolina's enrollment guide marks the field optional and prints the prompt with its answer built in: "It is permissible to ask; if provided, enter; if denied, leave blank." A district that collects the number holds it on the same profile an agent opens. The enrollment task does not need it once the state identifier is assigned, and a control on the page can keep it out of the model.
Who should approve a change an agent makes to a student record?
A named person with authority over that record, approving the specific change rather than the agent's access in general. An approval given after the agent has read the profile does not remove the values from its context, so the approval should sit beside a statement of what the model read. The group decides who may act. The approval decides whether this change happens.
What record should a district keep of an agent's work in the SIS?
One record that joins the screens the agent read, the values on them, the actions it took and the name of the person who approved each one. An action log alone leaves out the reading, which is where the student data was exposed. Colorado's law points the same way for automated decisions, adding "recordkeeping requirements for at least three years," and a district's record should be exportable to its own monitoring.
What should a district ask a vendor about what an agent reads in the SIS?
Three answers in writing: what the model receives from each rendered screen in the district's own applications, who approves each record change by name, and what record the district receives of the screens, actions and approvals. A vendor that cannot answer the first question has not described the control. Test the answers on one workflow, such as an attendance correction, before signing.
How RedactSure Keeps Student Records Out of the Agent's Context
A security group decides which building's data a clerk may open; it does not decide what the profile shows the model that reads it. The Alabama deck's own scope line is "Location-wide indicates access to only building data based upon the user's active locations in SIS".
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the model received the legal name, date of birth, clinic note and guardian card as page text. Inside, the profile renders STUDENT_014, DOB_014, HEALTH_003 and GUARD_002, the agent drafts the correction on those tokens, and an administrator's approval resolves the real values at the attendance record.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A wrong attendance mark follows a child into a state report. Bring one student task and see, with test values, what the model reads, who approves the change and what the record holds. Book a demo