Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Process Student Enrollment Without Seeing Birth Certificates?
No. An enrollment screen prints the student's date of birth beside the packet, so an agent working that record reads what the certificate proves even when it never opens the scan; ask for consistent tokens on those fields and a packet the model cannot render.
A district registrar opens a new-student packet in the student information system and works through it: the enrollment form, the proof of residence, the immunization record and the birth certificate the family uploaded. The registrar checks that each item is present, that the names match, that the date of birth agrees with the form, and then routes the packet to an approval. The sequence is repetitive, rule-bound and measured in minutes per student, which is why it looks delegable.
The certificate is the item districts worry about, and the worry usually aims at the wrong place. Most enrollment work never draws the certificate's pages; it reads the record the district keys around them. The state's enrollment guide treats the date of birth as a required field on the enrollment form, and the form cannot be submitted until every required field is in (North Carolina Department of Public Instruction, 2017). An agent working the screen reads that field whether or not the attachment is ever opened.
The answer therefore turns on the screen the agent reads. A packet that arrives as a filename and a status can be checked without the model holding the certificate, while a record that prints the birth date hands the data over anyway. Two people carry the risk: the registrar whose name sits on the enrollment, and the family whose child's date of birth and address would sit in a transcript for the rest of the run. A district should settle what the model receives, field by field, before it delegates the packet.
Key findings
- For an enrollment packet to be checked without the model holding a birth certificate, the packet has to reach the agent as an attachment row with a name, a size and a status, and the fields the enrollment screen renders have to carry consistent tokens before any model reads them (What Is Render-Layer Tokenization?).
- It would also require a named person approving the enrollment and a record of what each screen showed the model, because the enrollment becomes the record the district keeps, and human approval is "a standard way to limit egregious failures" (Shavit et al., 2023).
- Infinite Campus's catalog describes the fields a clerk keys and the tool rights a group holds, and it does not describe what a packet viewer draws when a certificate is opened (Infinite Campus, Tool Rights, 2026).
- North Carolina's guide places "the student's date of birth in the DOB field (format: MM/DD/YYYY)" on the same form as the name, gender and enrollment date, before the state UID lookup runs (North Carolina Department of Public Instruction, 2017).
- Infinite Campus masks the number and not the rest of the record: "All SSNs initially display as XXX-XX-XXXX", and a user needs SSN rights plus calendar rights to view the number, while the date of birth, name and address stay on the page (Infinite Campus, Tool Rights, 2026).
- Web agents "are prone to inadvertent use of unnecessary sensitive information", the failure an enrollment packet invites when the certificate is one of several documents and the screen shows the rest (Zharmagambetov et al., 2025).
What does an agent read when it opens an enrollment packet?
Take one new-student packet for a transfer student: a birth certificate, a proof of residence, an immunization record and the district's enrollment form, attached to a record that carries the name, date of birth, grade and entry code. The agent confirms the packet is complete, checks that the names and the date of birth agree across the four items, and routes it to a registrar.
If the system lists each upload as a row with a filename, a document type, a size and a received date, the agent can work from the rows. The check finishes without the model holding the child's birth record, the split an unrendered W-9 relies on (see Can an AI Agent Submit a W-9 on Your Behalf Without Reading It?).
The record beside the rows is a different surface. The enrollment form carries the date of birth as a required field, and an agent completing or verifying that form reads the date the certificate attests to. The Social Security Number is optional, so the record can be narrower on that value and still not on the date.
Under FERPA the certificate is an education record in any format, because the definition covers records "directly related to a student and that are maintained by an educational agency or institution or a party acting for or on behalf of" it (U.S. Department of Education, Education Record, 2026). The examples include "grades, transcripts, class lists, student course schedules, health records (at the K-12 level)", and format is irrelevant ("handwriting, print, computer media"). The certificate and the DOB field are both in scope, which is why an unrendered packet is only a partial answer.
What the agent receives is therefore two things: an attachment list that can stay opaque, and a record whose fields are rendered. Only the second is load-bearing, and it is the one a page can change before the model reads it (What Is Render-Layer Tokenization?).
What does the enrollment screen show that the certificate also proves?
A birth certificate's working content for an enrollment is the child's name, the date of birth and the parents' names. The enrollment form asks for the first two and adds gender, grade, entry code, enrollment date, ethnicity and race. The certificate is the proof behind the date; the form is the copy the district uses.
| What the packet asks for | Where the district gets it | What the agent needs |
|---|---|---|
| Student name | Enrollment form and certificate | The field, to match the two |
| Date of birth | DOB field on the enrollment form | The field, to check it against the certificate |
| Residence | Proof-of-residence upload | An address, or the district's residency flag |
| Immunization dates | Immunization record upload | Dates and the requirement they meet |
| The certificate itself | The uploaded file | A filename and a received status |
The first two rows are why the answer is no on a normal screen. The agent that matches the certificate to the record has to read the name and the date of birth on the record, and those are the values the certificate exists to prove. The scan can stay closed and the data still crosses into the model.
The Social Security Number is the one field the guide marks optional, with the prompt "It is permissible to ask; if provided, enter; if denied, leave blank" (North Carolina Department of Public Instruction, 2017). A district can leave it blank. It cannot leave the date of birth blank, because the state UID lookup depends on the record.
The regulation points the same way: institutions "must use reasonable methods to ensure that school officials obtain access to only those education records" in which they have "legitimate educational interests" (Electronic Code of Federal Regulations, 2026). An agent that reads the whole record to check one document is the case that sentence is written against.
Dr. Judy White, retired Riverside County Superintendent of Schools, summed up that standard on a HAL podcast: "If something's not needed to know, take it out." (Does the Need-to-Know Rule Survive AI? A Former County Superintendent on Student Records).
A screen that renders the name and the date as tokens, and keeps the certificate as an attachment row, gives the agent the match without the values (Does Masking Data on Screen Break Browser Agents?).
What do the vendors themselves say?
The student information systems districts use describe fields, rights and display rules. None of the pages reviewed describes a packet viewer that withholds a document's pages from the person who opens it.
| Dimension | Infinite Campus, per its documentation | What a buyer should verify |
|---|---|---|
| SSN display | "All SSNs initially display as XXX-XX-XXXX" | Whether the mask covers the date of birth, name and address too |
| Who can see the number | SSN rights plus "appropriate calendar rights" | Whether the agent's account holds either right |
| Rights model | The catalog calls its rights "suggestions" | Whether the district configures them or inherits them |
"Users must be assigned appropriate calendar rights in addition to SSN rights to view the person's SSN", and the catalog calls its rights "suggestions" rather than requirements (Infinite Campus, Tool Rights, 2026). That is a rule about who may open the field, not about what the page renders to an agent that already holds the rights.
Read together, the pages cover three surfaces: the field a clerk keys, the right a group holds, and the cell a display mask changes. None of them is a statement about what a page draws for a model, which is the surface the enrollment question turns on. The district-level version of the question is the one the Infinite Campus page takes up (Can a School District Use AI Agents on Infinite Campus Without Exposing Student Data?).
Skyward's module catalogue says "Student Entry and Withdrawal data and grade level progression are all housed within the Enrollment module", and the "Security module allows you to manage your staff, student, and guardian users and their access to the database" through Security Groups and Roles, while the catalogue gives no screen-level steps or field definitions (WSIPC, 2025). A role model says who may reach the module; it does not say what the module prints.
Oracle's PeopleSoft page shows how a national ID is masked for display: with "the masking format is XXX@XX@@@@@" the number 123-45-6789 "is displayed as XXX-XX-6789", and the page states that "the mask governs display only" with a separate stored value (Oracle, 2026). That is the closest the vendor pages come to a screen-level control, and it covers one identifier.
What should a district ask for in writing before an agent enrolls a student?
Five questions settle most of it, and each answer can be checked against a vendor's own pages.
- What the model receives from a rendered enrollment screen, field by field, and whether those values are tokens or the district's data.
- Whether the packet viewer draws an uploaded certificate, or lists it as a name, a size and a status.
- Who approves the enrollment, whether the approval names the person, and which values resolve at that moment.
- What record shows the page as the model read it and the values that resolved at approval, in a form the district can export.
- Whether the vendor's staff can be a school official under FERPA, and on what terms.
The FERPA conditions are specific. A contractor can be a school official only if it "Performs an institutional service or function for which the agency or institution would otherwise use employees" and is "under the direct control of the agency or institution", and its use of PII is limited to the purpose of the disclosure (U.S. Department of Education, School Official, 2026). A vendor that cannot describe its purpose limitation in writing has not met the condition.
If the agent's output becomes a factor in an enrollment decision rather than a completeness check, another regime attaches. Colorado's ADMT Act, most of whose provisions take effect on January 1, 2027, treats an output as covered when it is "a non-de minimis factor that is used in making a consequential decision" in a domain that includes "educational enrollment or opportunity", and it adds "recordkeeping requirements for at least three years" (Goodwin, 2026). The alert is a law firm's summary, not the statute, so the district's counsel reads the text before relying on the dates.
A vendor that can name the token on the screen and the approval record has described a control; one that answers with a role or a setting has described where the agent is allowed to go (How Do You Know Which Pages and Records an AI Agent Accessed?).
Does masking the Social Security number make the screen safe for an agent?
No, and the reason is the shape of a mask. The Infinite Campus mask described above hides one field on one page, for the users who lack the extra right. The date of birth, the name and the address sit outside it, and they are the values the enrollment check consumes.
Oracle's page is explicit that the mask is a display property: "the mask governs display only", with a separate stored value, and the format length "must be equal to the length of the National ID" (Oracle, 2026). A display mask is a property of the cell, not of the record, and it does not follow the value into the copy the model reads.
Web agents compound the problem because they do not stay on the field a person would. The AgentDAM evaluation found that agents "are prone to inadvertent use of unnecessary sensitive information", which is what happens when a checklist task reads the whole record (Zharmagambetov et al., 2025). A masked SSN is one cell in a page of values the task does not need.
Filling a field from a store while the model sees a placeholder is a documented pattern (Can a Browser Agent Fill In a Form Without Seeing the Values?), and it settles the typed value rather than the record beside it. The certificate's working content is the name and the date of birth, and neither is masked on the enrollment form. A district that wants the agent to check the packet without holding that content needs the substitution to happen before the page reaches the model, not in one column after it.
The documentation stops at the mask. 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 these student systems were not part of either review (Do AI Agents Ask Before Making a Payment?).
Masking changes what one cell shows. It does not change what the screen hands the agent (Does Masking Data Still Let an AI Agent Complete Its Task?).
What does a governed environment change?
A governed environment puts the substitution where the page is drawn. The enrollment record renders STU_1042, DOB_001 and a packet row such as CERT_003, and the real name, date and file resolve only at the SIS write and the state UID submission, at the moment a named registrar approves the enrollment.
The agent still does the work: it matches the token on the certificate row to the token in the record, confirms that the four items are present, checks the immunization dates against the district's requirement, and routes the packet. What it never holds is the date the certificate proves or the pages the scan contains.
The approval and the record are the other half. A named person approves the enrollment, and every screen, action and approval lands in a record the district can export, so the family's question about what the system saw has an answer that does not depend on the model's summary.
Two limits belong with the claim. The control governs the pages the agent reads, not the SIS database, the state UID system or a direct API, and it ends at the registrar's own screen after approval. The checklist has to stay readable, so the control substitutes the values the task does not need and leaves the rest alone.
That is the difference the title turns on: the certificate can stay an attachment, and the record can stop printing the birth date (What Is Render-Layer Tokenization?).
What the record shows
The control that changes this answer sits at the render layer, where the page is composed: tokens in place of the student's name and date of birth, an attachment row in place of a drawn certificate, a named registrar approving the enrollment, and a record of what the model received. On the documentation reviewed, the enrollment screens districts use print the date of birth as a required field and leave the packet viewer undescribed, so the answer to the title is no until the page changes. A district can check the claim on one workflow: take a packet with test values, capture the page the model receives, mark every field that carries the certificate's content, and compare that list with the fields the SIS stored after the approval. That comparison also shows whether the mask on one field is doing the work the district thinks it is.
Methodology and limitations
This page rests on state enrollment guidance, three vendor documentation pages for student information systems and identity masking, two federal student-privacy FAQs, the FERPA regulation text, one law-firm alert on Colorado's automated decision law, and one evaluation of web-agent privacy. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product named here was tested for this page; the products are described from documentation, and "not described in the pages reviewed" means the recorded facts for a page do not cover it. 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 new-student enrollment packet, and not an organization. Determinations about whether an enrollment workflow meets FERPA, state law or a contract belong to counsel, assessors and the organization'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 an AI agent process student enrollment without seeing birth certificates?
No, not while it works the enrollment screen. The screen keys the date of birth in a required field, and the agent has to read that field to match the certificate to the record. The scan can stay unopened, and the data it proves still reaches the model. A screen that renders DOB_001 and an attachment row changes the answer, because the model then holds a token and a filename.
What does the model receive from a rendered enrollment screen?
The fields the page draws: the student's name, date of birth, grade and entry code, the packet's attachment list, and any preview pane the page opens when a clerk clicks a document. The model also receives the actions the signed-in account is allowed to take, because the page offers only those. What it does not receive, on the pages reviewed, is a record of which values were replaced before it read them.
Who should approve an enrollment an agent prepares?
A named registrar or enrollment officer, not the agent. The approval is where a person accepts that the packet is complete and the record is correct, and it is the place to resolve the real values the agent worked as tokens. OpenAI's governance paper calls human approval "a standard way to limit egregious failures", which is the role it plays here (Shavit et al., 2023).
What record should the district keep of the agent's enrollment work?
One record per enrollment that shows the page as the model read it, the token or attachment row it acted on, the fields that resolved at approval and the name of the person who approved. That record answers the family's question about what the system saw, and it gives the district something to compare when a vendor changes a field or a role. A log of actions alone cannot answer either.
Does masking the Social Security number protect the rest of the record?
No. A display mask covers the field it is configured on, and the page keeps working the same way. Infinite Campus shows SSNs as XXX-XX-XXXX, and Oracle's national ID mask displays 123-45-6789 as XXX-XX-6789 and governs display only, with a separate stored value. Neither mask touches the date of birth, the name or the address, which are the values the certificate exists to prove.
Does FERPA allow a vendor's agent to work enrollment records?
Only where the vendor meets the school-official conditions: it performs a function the district would otherwise use employees for, it is under the district's direct control for the use and maintenance of education records, and the data is used only for the purpose of the disclosure. The district must also use reasonable methods to limit access to records with a legitimate educational interest, and the agent's access is part of that analysis (Electronic Code of Federal Regulations, 2026).
How RedactSure Keeps a Birth Certificate Out of the Enrollment Screen
The enrollment screen prints the student's date of birth in the field the agent reads, and the masks above leave that field in place. North Carolina's guide treats the date of birth as a required field before the form can be submitted.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the record draws the name and the date of birth, and the packet lists a certificate the agent can open, so the model reads the content beside the checklist. Inside: STU_1042 and DOB_001 render, the packet appears as CERT_003, the registrar approves, and the real values resolve into the SIS record and the state UID submission.
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 packet that prints the birth date beside the checklist puts a child's identifier in every note the model writes. Bring one enrollment packet and see, with test values, what the model reads and where the real date resolves. Book a demo