Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can a School District Use AI Agents on Infinite Campus Without Exposing Student Data?
No. Not while the agent's model receives the rendered student page: every Infinite Campus screen carries the student's name, flags and attendance, and FERPA's school-official exception requires direct control over the recipient, so ask what the model is shown before any agent touches the SIS.
A registrar opens one student's page in Infinite Campus to correct a single attendance code, and the page draws more than the code: the student's name and number, the special-education flag in the header, the Enrollment tab's funding fields, and the roster the code sits in. An agent given that task works the same page under the same session, and its model receives whatever the screen renders. The legal question districts ask first is who may receive a FERPA education record, and the Department of Education answers it through the school-official exception, which conditions disclosure on the district's direct control over the recipient and on the purpose of the disclosure (U.S. Department of Education, School official, 2026). The engineering question comes before that one: what the model receives from the rendered page. A page that draws the student on every screen, as Infinite Campus does, puts the second question first, because a model that has read the name and the flag has received the record whatever the contract says. A district can answer the legal question with a contract. Whether a model ever sees the student is decided earlier, at the point where the page is drawn.
Key findings
- For an agent to work Infinite Campus screens without exposing student data, the values on the rendered page would have to be replaced with consistent tokens such as STU_2140 before the model reads it, with the real name, flag and birth date resolving only at an approved destination (What Is Render-Layer Tokenization?).
- The district would also need one named person approving each attendance correction, enrollment submission and flag change, and an exported record of what the model received and who approved it (What Is Supervised Delegation?).
- Infinite Campus's own tool-rights catalog states that "All SSNs initially display as XXX-XX-XXXX," so the value a staff screen shows is set by the rights a role holds, and none of the pages reviewed says that a rendered value is replaced before a model reads it (Infinite Campus, Tool rights, 2026).
- The vendor's special-education setup article describes the flag editor and says that to show the flag in the header the administrator must "also mark the Flagged checkbox," the mark a registrar sees before any other field (Infinite Campus, Special Ed setup, 2026).
- Kentucky's attendance training shows the Attendance Wizard marking every selected student unexcused absent "with one click" once "Overwrite existing records" is ticked, a batch screen where every row is a student (Kentucky Department of Education, 2026).
- An evaluation of autonomous web agents reports that they "are prone to inadvertent use of unnecessary sensitive information," which is what a student page invites when the task is one attendance code (Zharmagambetov et al., 2025).
What does an agent receive when it opens an Infinite Campus student page?
The record is one student page in Infinite Campus, opened by an attendance clerk who needs to fix one code. What the page draws follows the rights attached to the clerk's user group: the vendor's catalog tells administrators to "Review User Groups and Suggested Tool Rights as a starting point for assigning tools and rights to user groups," then cautions "These are suggestions" (Infinite Campus, Tool rights, 2026). Two clerks with different groups can open the same student and see different fields, and an agent inherits whichever view the session holds.
The catalog's SSN rule shows how field-level that decision is: "All SSNs initially display as XXX-XX-XXXX," and "Users must be assigned appropriate calendar rights in addition to SSN rights to view the person's SSN" (Infinite Campus, Tool rights, 2026). The page still draws the name, the grade level, the enrollment dates and the header flag.
The header flag is the clearest example. The vendor's setup article describes the editor: a name, a State Program Code, Special Ed and Flagged checkboxes, a flag image and a flag color; to show the flag on the student's header, the article says to "also mark the Flagged checkbox" (Infinite Campus, Special Ed setup, 2026). That article is Arizona state-reporting setup for districts that do not run special education in Campus, and it warns against using the flag where Campus holds the IEP, so a district's configuration decides which students carry it.
The Enrollment tab draws more. Kentucky's training deck opens a SPECIAL ED FIELDS section there and records funding through a Full Funding checkbox, and the same deck's Attendance Wizard can mark every selected student unexcused absent "with one click" once "Overwrite existing records" is ticked (Kentucky Department of Education, 2026). An agent asked to post one absence works a roster where every row is a student.
| What the student page draws | What the attendance task needs | What the model receives without a control |
|---|---|---|
| Student name and number | A row to match | Both, on every row |
| Special-ed flag in the header | Nothing | The flag, among the most sensitive fields on the page |
| Birth date and enrollment dates | Nothing | Both |
| SSN, masked as XXX-XX-XXXX initially | Nothing | The mask, and the real value if the role can reveal it |
| Attendance code and history | The code for one date | The code, the student it belongs to and the history beside it |
Does Infinite Campus's SSN masking keep the student out of the model's context?
Not on its own. The mask is a rule about one field for one role, and a model receives the whole rendered page. When the clerk's group holds SSN rights, "All SSNs initially display as XXX-XX-XXXX" describes the first paint, not the value on the screen; the real digits appear where the role is allowed to see them (Infinite Campus, Tool rights, 2026). When the group lacks those rights, the mask holds and the other fields do not: the name, the header flag, the birth date and the attendance history render in full.
An enrollment screen has the same shape. North Carolina's guide puts the student's date of birth in the DOB field and leaves the SSN optional, with the state UID system queried when the form is submitted (North Carolina Department of Public Instruction, 2026). Optional means the form can be completed without that one value, not that the screen is free of identifiers; a model that fills the form reads the birth date and the name.
Role scope has the same character. Alabama's security-group deck draws the line at the role: "System-wide indicates access to all data district-wide" while "Location-wide indicates access to only building data" (Alabama State Department of Education, 2026). That is a boundary on which records an account may open, not on what one student's page shows once it opens, and an agent under a building-scoped account still receives every field that page renders.
A district should read a mask as a display convenience, not as a control on the model, because the field it covers is one of a dozen on the page. The same question in the other large student system is worked in Can an AI Agent Use PowerSchool Without Student PII?.
What do the vendors themselves say?
Three vendor pages bear on the question, and each one locates its control somewhere other than the rendered screen.
Infinite Campus documents the pieces a district administers: user groups and suggested tool rights, and an SSN mask that shows XXX-XX-XXXX until a role is granted the right to view the real value (Infinite Campus, Tool rights, 2026). Its catalog calls those rights "suggestions," and none of the pages reviewed describes a rule that decides which values a model may read once a page is open.
PowerSchool's release shows a vendor model already reading the student system. PowerBuddy for Engagement answers "How many absences has my child had this year?" and "What is my child's grade in English?" by "leveraging the PowerSchool Student Information System (SIS)" (PowerSchool, Family-facing, 2026). The release says only that PowerSchool "is committed to being a good custodian of student data," and names no privacy statute (PowerSchool, Family-facing, 2026). A family assistant answering a grade question is not an agent working a registrar's screen, and the release describes no control on what the assistant's model receives.
Glean's agent governance page places its control on the action: the product "enforces permissions for every action an agent takes" (Glean, 2026). That governs which records an agent may touch and which operations it may run; it does not describe what the model receives from a rendered student page.
Three vendor pages are not the whole field. Of 15 AI agents and 86 AI security products reviewed, none describes replacing the customer data an agent reads on a screen with tokens it can work with, and the student information systems described here were not among them (Do AI Agents Ask Before Making a Payment?).
Where does FERPA put a vendor whose model reads student screens?
The school-official exception lets a district disclose education records without consent to an outside party that performs an institutional service. The Department's FAQ states that the party qualifies when it "Performs an institutional service or function for which the agency or institution would otherwise use employees," and when it "Is under the direct control of the agency or institution with respect to the use and maintenance of education records" (U.S. Department of Education, School official, 2026). PII "may be used only for the purposes for which the disclosure was made" (U.S. Department of Education, School official, 2026).
Direct control is the hard part for a model vendor. A district can name the vendor a school official and limit the purpose in the contract; what it cannot do from the contract is decide what the model receives, keeps or logs once a student page renders. The record has entered the context, and the purpose limitation describes a use the district can no longer observe. Does FERPA's School-Official Exception Cover AI? puts it plainly: direct control is the condition generic AI tools fail.
The Department made the online-service case explicit in August 2026, when its back-to-school letter stated that "student information may only be disclosed to an online educational service company in compliance with FERPA" (U.S. Department of Education, Back to school, 2026). A model vendor receiving screens is an online service receiving student information, and the question is whether the disclosure fits an exception.
That is why the architecture matters before the contract. If the model receives tokens instead of the student's values, the model vendor is not receiving the education record, and the disclosure question moves to the operator of the governed environment. If the model receives the rendered page, the district is asking the exception to cover a recipient whose use it cannot see.
Counsel decides whether a given arrangement fits; the engineering fact is narrower, since a screen that renders the student hands the record to whatever reads it.
What should a district ask a vendor for in writing?
A district's written ask should describe the page, not the promise. The checklist below turns the record into questions a procurement office can score, and the first one decides the rest.
| Ask in writing | A useful answer | Why it matters on a student page |
|---|---|---|
| What does the model receive from a rendered screen? | A field list per screen, with the substitution rule for each field | The page draws the name, the header flag, the birth date and the attendance history |
| Where do real values resolve? | Only at the approved destination, at the moment of an approved action | An agent posting attendance does not need the real name in its context |
| Who approves an action? | A named district employee, per action, with the approval recorded | The registrar owns the correction, not the vendor |
| What record exists? | Screens received, actions taken, approver names and times, exportable | The district answers a FERPA request without asking the vendor |
| What are the contract terms? | School-official designation, purpose limitation, deletion, no training on district data | These are the exception's conditions, and they need wording |
| What may the agent open? | Role scope per application and per task | Tool rights decide screens; they do not decide values |
Ask what the model receives from a rendered screen first, and ask for the field list as an exhibit. A vendor that cannot produce one is describing a policy, not a control. How Do You Test Whether an AI Agent Can Reach Data Outside Its Assigned Task? gives the test: give the agent one task, watch what it opens beyond the task, and compare the list with the exhibit. Can Schools Enable OpenAI Dots on Student Records? applies the same questions to a consumer product.
The answers also compare an agent against a plain browser session. A staff member's session renders the page; the difference with an agent is who reads it. The district's own machines raise the same question about what should be there at all. Thomas Livers, Associate Athletic Director for IT Services, University of North Carolina at Chapel Hill, described the rule for staff machines on a HAL podcast: "you shouldn't even have the FERPA data on your laptop, you shouldn't have any of that." (Does Banning AI Work? A University IT Leader on Athlete Data, FERPA and AI Governance).
What does a governed environment change?
A governed environment changes the question from who may receive a record to what the model is shown. Values chosen by policy are replaced with consistent tokens such as STU_2140 at the moment the page is rendered, before any model reads it; the model works the roster, the attendance code and the flag as tokens, and the real values resolve only at the approved destination at the moment of an approved action. One named person confirms which fields are tokenized, approves each attendance correction or submission, and appears by name in the record, which lists the screens received, the actions taken and the approvals.
The difference from the controls above is placement. Role rights, SSN masks and permission checks decide which records an account may open; they do not decide which values reach the model once the page is open. A control on the model call has the same limit, since a gateway governs the request and not the screen behind it (RedactSure vs AI Gateways). Render-layer tokenization acts before the screen reaches the model, which is the placement the FERPA question turns on: the model never receives the education record.
None of this decides the legal question. It keeps the model outside the subject matter of the exception, and the district still needs the contract, the purpose limitation and the school-official designation. Counsel decides whether a given arrangement fits; the engineering fact is that the model reads tokens while the page, the action and the approval stay in the district's record.
What the record shows
The question a district can settle is what the model receives, not what a vendor promises. Infinite Campus draws the student on the pages a role opens, from the header flag to the enrollment funding fields to the attendance roster, and its tool rights decide which fields a role may see rather than which values a model may read. FERPA's school-official exception then asks whether the recipient is under the district's direct control and bound to the purpose of the disclosure, which is a hard fit for a model vendor that receives rendered screens. The pages reviewed describe the screens and the masks; none describes replacing a rendered value before a model reads it. A district can test the answer on one student page: name the fields the page draws, list the ones the attendance task needs, and compare the lists while the agent's context is open. The difference is the exposure the district is accepting.
Methodology and limitations
This page rests on public documentation: Infinite Campus's knowledge base and a Kentucky Department of Education training deck for its screens, U.S. Department of Education guidance, a PowerSchool release and regional enrollment and security guides, Glean's governance page, and a peer-reviewed study of web agents. Vendor pages were read between October 16, 2026 and October 22, 2026, and public documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested hands-on: everything is described from documentation, and "not described in the pages reviewed" means the pages listed in Sources, not a claim about a vendor's plans. 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 page, not an organization. Determinations belong to counsel, assessors and the district's own security and compliance officers, and nothing here replaces a pilot of one workflow on the district's own screens.
Frequently asked questions
Can a district let an AI agent read Infinite Campus screens if the vendor signs a FERPA agreement?
Not by itself. A contract can name the vendor a school official, bind it to the disclosure purpose and require deletion, and the Department of Education's exception expects those terms. It does not change what the model receives when the page renders: the name, the header flag, the enrollment fields and the attendance history enter the model's context, where a clause cannot recall them. The agreement governs the recipient's obligations. The rendering decides what the recipient receives.
Does Infinite Campus's tool-rights model keep student data away from an agent's model?
No. Tool rights decide which screens and fields a user group may open, and the catalog describes suggested rights and a mask under which "All SSNs initially display as XXX-XX-XXXX." An agent that works inside a permitted session receives every field that session renders, including the name, the header flag and the attendance history. The rights model answers who may see a record, not what a model reads once the page is open and the fields are in front of it.
What does the model receive from one Infinite Campus student page?
Whatever the page draws for the role the agent runs under: the student's name and number, the header flag, the enrollment dates, the special-education funding fields and the attendance rows, in full. A masked SSN is one field among them, and the mask is a display rule for the role. None of the pages reviewed replaces those values before the model reads the page, so the task's scope is not the context's limit.
Who should approve an agent's attendance correction in the student system?
A named district employee, most often the attendance clerk or registrar who owns the record, approving that specific change rather than a class of changes. The approval should name the student page, the field and the value, and it should be recorded outside the model, because an approval the model chooses whether to request is not a gate. A blanket permission to update attendance is not an approval.
What record should the district keep of an agent's work in Infinite Campus?
One record per run: the screens the model received, the values it saw as tokens, each action it took, the name of the person who approved it and the time. The record should export to the district's own store rather than the vendor's dashboard, so a FERPA request or an audit can be answered without asking the vendor. A district that keeps only the vendor's copy is renting its own evidence, and retention should follow its records schedule.
Is an agent that only reads Infinite Campus screens lower risk than one that can write?
Not necessarily. A read-only agent still receives the student page, and the record it reads is the disclosure the exception governs; the write permission changes what the agent may do, not what the model has already seen. The exposure on this page is the reading, which is why replacing values on the rendered page comes before any question about write access or role design.
How RedactSure Keeps the Student Page Off the Model's Screen
A district's attendance task needs one row and one code, while the controls reviewed above govern which records an agent may open, not what its model reads. The vendor's own catalog shows the limit: "All SSNs initially display as XXX-XX-XXXX," and the header flag and the name still render.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, an agent working the student page received the name, the header flag and the attendance history. Inside the governed environment the page renders as STU_2140 and FLAG_003, and the real values resolve only when the registrar approves the correction, with the approval named in the 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
An attendance correction is the smallest task an agent can take on a student page, and it still puts the whole record in context. Bring one district task and watch, with test values, what the model reads and who approves. Book a demo