Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Work in Banner or PeopleSoft Without Seeing Student Social Security Numbers?
No. The Social Security number sits on the identity page as a field the role can open, and an agent working that page receives whatever the screen renders, so the answer changes only when the value is replaced with a consistent token before the model reads it.
A registrar can picture the task: clear a registration hold, confirm a financial aid packaging decision, correct a name on a diploma record. Each one runs through a page that shows the student's identity, and in Banner and PeopleSoft Campus Solutions that page carries the Social Security number as a field. A staff member with the right role opens it, reads the number when the work needs it and moves on. An agent given the same role opens the same page, and the model behind it receives the field the way the application draws it.
The controls around these systems were built for people. Banner security classes, PeopleSoft roles, data-owner approval and a national ID mask decide who may open a page and how it prints. None of them decides what a model reads once the page is open. Higher education concentrates the risk: a student record holds the number beside aid, tax and enrollment data, and an agent that reads the record collects all of it at once.
A registrar's office can therefore answer the question in one place: what the screen hands the model when the agent opens the identity page, and what would have to change for the number not to be in that hand. Both systems keep the value in the same kind of place, so one answer covers both.
Key findings
- For an agent to work a Banner or PeopleSoft identity page without the Social Security number, the page would have to render a consistent token such as SSN_001 before any model reads it, with the real number resolving only at the record change a named person approves (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change and a log that makes every action attributable to a person or an agent, because "audit logs attribute every action unambiguously" to one or the other (AWS, 2026).
- The Banner and PeopleSoft pages reviewed describe role security, data-owner approval and a display mask, and none of them describes a control that changes what the model receives once the page is open (Nashville State Community College, 2026).
- PeopleSoft Campus Solutions delivers a United States national ID type, PR: "The delivered national ID type for Canada and the United States is PR", and the setup page states "You cannot delete this value" (Oracle, 2026).
- Tulane's Banner procedure puts the number in a field staff edit: "In the SSN/SIN/TIN field enter or update the social security number" on SPAIDEN's Biographical tab (Tulane University, 2026).
- Harvard's guidance names the combination that makes an agent setup riskiest, "access to private data, exposure to untrusted content, and the ability to send data outward", and says to remove one part if you can (Harvard University Information Security and Data Privacy, 2026).
What does an agent read when it opens a Banner identity page?
The record here is a student's SPAIDEN page opened for a name correction. RMU's Banner guide describes SPAIDEN as an ID field with tabs for Address, Telephone and Biographical, plus an Additional Identification tab that shows "the student's ID card # and login ID", and it adds that "you can modify student information via SPAIDEN" when the person has the appropriate level of security (RMU, 2026).
Tulane's registrar knowledge base shows what the Biographical tab carries: "In the SSN/SIN/TIN field enter or update the social security number" (Tulane University, 2026). A correction needs "A social security card and valid photo identification with SSN", and a W-2 or 1099 "must have the entire SSN on it, not just the last 4 digits" (Tulane University, 2026). The number is not a hidden field on a back-end table. It is on the page the work happens on, in a box a staff member fills.
Read that as an agent's task. The agent opens SPAIDEN, clicks the Biographical tab, finds the field, compares the number with the document and either confirms it or types a correction. Every step depends on the screen holding the number, and the model receives the page as the application renders it. A permission check decides whether the page opens. It says nothing about what the model reads after it does.
The same reading applies to a payroll profile, where the number sits on a page the run screens never show but the same account can open (Can an AI Agent Run Payroll in Gusto Without Seeing Social Security Numbers?).
What does PeopleSoft Campus Solutions render on the same record?
PeopleSoft Campus Solutions stores the number as a national ID. The PeopleBooks setup page for National ID Types states that "The delivered national ID type for Canada and the United States is PR", which corresponds to the Canadian Social Insurance Number and the American Social Security Number, and adds "You cannot delete this value" (Oracle, 2026). The type is delivered configuration rather than a field an institution adds.
The same page describes how the number can print with a mask. A format string of X and @ characters is applied to the ID, so 123-45-6789 with "the masking format is XXX@XX@@@@@" is displayed "as XXX-XX-6789" (Oracle, 2026). Three limits sit around that setting: the format length must equal the ID length, "the mask governs display only" with a separate stored value, and the page is setup documentation for the National ID Type Table rather than a data-protection policy (Oracle, 2026). The page also warns that record logic performs special validation on a list of national IDs, so mask behaviour is not uniform across countries.
For an agent, the mask changes what one configured page prints. It does not describe what the model receives from an unmasked page, or from a screen where the task needs the whole number. A W-2 or a correction is that kind of task, and the number is the point of it. A mask that shortens one field is not a control over what a run collects from every screen it touches.
What do the vendors themselves say?
Two kinds of page carry the record: Oracle's setup documentation for the national ID type, and the Banner procedures and access policies that institutions publish for the staff who use the screens. None of it is written for an agent deployment, so each row pairs what the page documents with the question a buyer still has to answer.
| Dimension | What the pages document | What a buyer should verify |
|---|---|---|
| The identifier | "The delivered national ID type for Canada and the United States is PR", and it cannot be deleted (Oracle, 2026) | Whether the institution uses a different type for sponsored students or applicants |
| The field | SPAIDEN's Biographical tab has an SSN/SIN/TIN field staff enter and update (Tulane University, 2026) | Which task screens in the agent's scope draw that field |
| Page access | Banner classes and roles follow job function, and Query Access views without updating (Nashville State Community College, 2026) | Whether the agent's account holds query rights to the identity page |
| What a role may change | "you can modify student information via SPAIDEN" with the appropriate security level (RMU, 2026) | Whether the agent's task includes writes, and who approves them |
| Masking | A format string can print the number as XXX-XX-6789, and the mask governs display only | Whether the mask is configured for this ID type, and what the unmasked pages show |
| What the model receives | Not described in the pages reviewed | Ask for the rendered page and the model context side by side |
Read the rows together and the pattern is consistent. The documented controls decide who may open a page, what a role may change and how a number prints for a person. The pages do not describe a control that sits between the rendered page and a model, which is the control this question turns on. A buyer who asks only for the role matrix has asked half the question.
The menu of enterprise agents that can work on screens with PII is longer than the two systems on this page, and each one raises the same reading question (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
Who approves a record change, and what does the log show?
The approval that Banner policies describe is approval of access. Nashville State's policy states that "Banner security classes and roles are established based upon job function", that Query Access is "Access enabling the user to view but not update Banner data", and that access is not granted "without approval of the appropriate Data Owner(s)" (Nashville State Community College, 2026). Those are decisions about a person's role before the work starts.
The action inside a session is a different decision. An agent with a query role opens the identity page and reads the number without changing anything, and the policy describes no person approving that read. When the task does change a record, the approval the page documents is evidence for a correction, the social security card and photo identification Tulane requires, not a named person authorizing this agent's change to this record (Tulane University, 2026). The law rarely names that approver: the National Conference of State Legislatures documents 1,143 AI bills in its 2025 table as of July 10, 2025, of which 9 addressed human review of an AI decision and 1 was enacted (How Many AI Laws Require Human Review of AI Decisions?).
The log is the third piece. AWS's guidance for agent workloads asks for separation so that "audit logs attribute every action unambiguously" to an agent or a person (AWS, 2026). A Banner log keyed to the staff account the agent ran under answers which account acted. It does not answer what the model read on the page before it acted. Guardrails do not close that gap either, because a rail that inspects the request or the tool call does not change the page the request describes (What Are AI Agent Guardrails?).
What should a registrar ask for in writing before an agent works these screens?
Five questions settle most of it, and each answer can be checked against the vendor's own pages.
- What does the model receive from the rendered page, field by field, for each screen in the task?
- Which values are replaced before the model reads them, and what does the token look like on the identity page and on the aid page?
- Who approves each record change by name, and does the approval cover the action or only the access?
- What does the log export: the page as the model saw it, the action taken and the name of the approver?
- Is a mask being offered as the control, and if so, which pages does it cover and which pages still print the whole number?
The first question is the one that decides the others. A vendor that answers it with a role matrix has described the door, not the page. A vendor that answers it with a token pattern has described the page, and the reviewer can check that answer on one task.
The wall is where this stops for most programs. The work turns out to run on the number, the security team will not approve the model seeing it, and the project either shrinks or pauses (What Is the PII Wall?). The way past it is not a stronger promise from the model. It is a policy that names which fields are replaced, applied on every screen in the run, with an approval and a record around the changes.
A registrar who wants the policy to survive an audit should write it once and apply it to every AI tool the office uses. Shadow adoption is the baseline condition: eight in ten employees use AI tools their organizations have not approved, so a policy that lives inside one approved tool governs a minority of the work (How Do You Keep Data Access Policies Consistent Across AI Tools?).
What does a governed environment change?
A governed environment changes the layer at which the decision is made. It does not ask the student system to withhold a field from a role that needs it, and it does not rely on the model ignoring a value it was shown. It replaces the value on the rendered screen before any model reads it, keeps a consistent token such as SSN_001 for the whole run, and releases the real number only at the destination a named person approves.
The research record supports placing the control there rather than at the model's judgment. Work on permissive information-flow analysis for language models shows how far a value travels once it enters a pipeline: "poisoned data retrieved from one component can change the model's behavior" and can end with the model coerced into spreading confidential data to untrusted components (Siddiqui et al., 2025). A filter at the agent-tool interface can strip a value before the model acts on it, which is the same logic one layer earlier: "aggressively redacts input arguments" is the paper's description of its minimizer (Bhagwatkar et al., 2026).
Three properties follow. The page the agent works is the rendered page, so the substitution happens where the value would otherwise appear. The run keeps one token per value, so a student is the same STUDENT_014 on the identity page and on the aid page. And the record is written for the reviewer: what the model received, what it did and who approved it.
A form can fill on placeholders while the page behind it still renders the number, so the replacement has to cover the screen and not the field alone (Can a Browser Agent Fill In a Form Without Seeing the Values?).
A control described this way is testable in a way a permission model is not. The reviewer can open the identity page, compare what the screen shows with what the model holds, and see whether the number appears in both. If it does, the system is working as documented and the exposure is still there.
What the record shows
An identity page that renders a Social Security number as a field hands that number to the model that reads the page, and the role around the page governs who may open it rather than what it displays. That is the finding across both systems: the person page holds the field on its Biographical tab, the national ID type stores the number, and the documented controls are access, approval of access and a display mask. To run the test on one system, open the identity page the agent's task uses with the account the agent runs under, capture what the page shows, then inspect the agent's context or trace for the same values. If the number appears in both, the permission model is working and the exposure control is absent.
Methodology and limitations
Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries its date. The page rests on Oracle's PeopleSoft Campus Solutions setup documentation, the Banner procedures and access policies that Tulane University, RMU and Nashville State Community College publish, peer-reviewed research on information flow and agent-tool filtering, and university guidance on generative AI. Public documentation read in full gives a sound view of where each product applies its control, which here is the access, approval and display layer.
No product on this page was tested for it, and none of the pages reviewed describes a control over what a model receives from a rendered page; "not described" means the pages reviewed, not a claim about what a vendor does elsewhere. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The worked record describes a record type, not an organization. Determinations about FERPA, GLBA or state privacy law belong to counsel and the institution's compliance officers, and nothing here replaces a pilot of one workflow on its own screens.
Frequently asked questions
Can an AI agent work in Banner or PeopleSoft without seeing student Social Security numbers?
No, not as the two systems deliver the identity page. Banner's SPAIDEN record carries the number in a field staff enter and update, and PeopleSoft stores it as a national ID that cannot be deleted, so an agent holding the role that opens the page receives the value the page renders. The answer changes only when the number is replaced with a consistent token before the model reads the screen, with a named person approving each record change and a record of what the model received.
Where does the Social Security number appear in a Banner record?
On the identity page. SPAIDEN is the general person page, and its Biographical tab holds the SSN/SIN/TIN field that Tulane's registrar guide tells staff to complete. The same page carries the student's ID card number and login on the Additional Identification tab. Query rights can open the page without allowing an update, which is the read an agent usually needs. The number sits in the same place for the agent as for the staff member who trains it.
Does the PeopleSoft national ID mask keep the number out of a model's context?
Only on a page where the mask is configured, and only for the digits it covers. The PeopleBooks page describes a display format that turns 123-45-6789 into XXX-XX-6789 for a national ID type, and it says the mask governs display while a separate stored value remains. It does not describe an agent's context, and a task that needs the whole number, such as a tax form or a correction, still needs the value on screen.
Do Banner security classes stop an agent from reading the number?
They stop the wrong person from opening the page. Nashville State's policy ties Banner classes and roles to job function and treats Query Access as permission to view but not update, with a data owner approving access. An agent given a query role therefore satisfies the policy while reading every field the page draws. The class governs the door, and the page behind it still carries the number.
Who should approve an agent's record change in a student system?
A named person with authority over that record, and the approval should cover the specific change. The approvals the Banner policy documents are access approvals before the work starts, and Tulane's correction evidence, a social security card and photo identification, verifies a person's identity rather than authorizing an agent's edit. The approver should see the field, the old value and the new value, and the approval should be recorded against that action.
What record should a registrar keep after an agent works these screens?
One that shows what the model received, what the agent did and who approved it. An access log answers the middle question at best, and a Banner log keyed to the staff account does not separate the agent's read from the person's. Keep the rendered page as the model saw it, the action submitted and the approver's name, exported to the institution's own monitoring so a reviewer can compare the screen with the context.
How RedactSure Keeps Student Social Security Numbers Off the Identity Screen
A Banner agent that opens an identity page for a record change reads the Social Security number that page draws. Tulane's procedure tells staff to "enter or update the social security number" in the SSN/SIN/TIN field (Tulane University, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the identity page renders the number, and the aid and tax screens behind it render it again. Inside: the same page renders SSN_001, the student appears as STUDENT_014, and the real number resolves only at the record change a named person approves; every screen and approval lands in the AI Control 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 Banner identity page can look routine and still carry the number that governs a student's aid. Bring one student-records task and see, with test values, what the model reads, who approves the change and what the record keeps. Book a demo