Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Provision a New Employee Without Seeing Their SSN?
No, not on the hire record the run starts from, where the job aid says "Enter the nine-digit Social Security Number in the Identification # field". Replace the number with a token before any model reads that page, have a named person approve each account and its groups, and keep a record of what the model received.
A new employee becomes two records in the same week. One is the hire record in the HR system, where the person is placed into a position and where payroll and tax reporting get their details. The other is the account in the identity provider, which lets the person sign in on the first morning. The account is built from a name, an address that receives mail and a list of groups. The hire record is built from the placement, and it carries an identification field that takes the nine-digit number. An agent asked to provision the employee works whichever of those pages its run opens, and it receives every field the page draws rather than the fields the task description mentions. A run confined to the account screen can finish without the number. A run that starts on the hire record reads it, and provisioning runs usually start there, because the hire record is where the job profile, the location and the start date live. The example is one account created for a new hire, with the hire record one page away.
Key findings
- For a provisioning run to keep the number out of its context, the hire record would have to render a consistent token such as SSN_001 before the model reads it, with the real value released only at the destination the organization approved (What Is Render-Layer Tokenization?).
- It would also require a named person approving the account and the groups it carries, plus a record of what the model received, because an approval governs the action, not the fields already in the run (What Is an AI Control Record?).
- The hire job aid reviewed describes the identification field and describes no masking or replacement of the number on the page, so an operator and an agent read the same characters (Maryland Department of Budget and Management, 2022).
- Maryland's job aid for the Workday hire lists Hire Date, Job Profile, Time Type, Location and Pay Rate Type, then instructs the operator to "Enter the nine-digit Social Security Number in the Identification # field" (Maryland Department of Budget and Management, 2022).
- Okta's Workflows connector reference requires an HR update to "include all of these fields for the action to succeed", with SSN among them, and does not say those values are masked in Workflow logs (Okta, 2026).
- The Cloud Security Alliance reports that "Eight in ten employees use AI tools not approved by their organizations", so a provisioning run can start in a tool the identity team never reviewed (Cloud Security Alliance, 2026).
What does an agent read on the identity provider account screen?
The account screen is the short half of this question. A person record in an identity provider is normally created from a display name, a username or mail address and a set of group memberships, and the groups carry the entitlements. An agent given the create-account task reads that form and the list it picks groups from, and none of those values is the nine-digit number.
Filling a field can be separated from the model reading it. Browser Use's sensitive data documentation, quoted on Can a Browser Agent Fill In a Form Without Seeing the Values?, states that "the LLM only sees placeholders (x_user, x_pass)" and that "real values are injected directly into form fields after the LLM call", a documented way to fill a field without the model holding what goes in it. That covers values the agent types, not values a page displays, and the account has a second page: the profile it creates, which draws whatever fields the directory holds.
A hosted browser makes the read plain: the review recorded in Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser? notes that the agent observes browser screenshots and decides the next action from what it sees. A screenshot is the page, so every field the screen drew is in what the model receives.
That clean answer is not the whole run. Whether the model receives the number depends on the page the run opened before it, and the administrator account that creates an account can often open the record behind it.
Where does the Social Security number sit on the hire record?
The hire record is where a person becomes an employee, and it is the page a provisioning run reads to learn who the person is. Maryland's job aid for the Workday hire says the business process is used "to hire employees (workers paid by the Central Payroll Bureau) into a position in Workday" (Maryland Department of Budget and Management, 2022). Its Hire Details page lists Hire Date, Reason, Employee Type, Job Profile, Time Type, Location and Pay Rate Type, and for identity it instructs the operator to "Enter the nine-digit Social Security Number in the Identification # field" (Maryland Department of Budget and Management, 2022). A duplicate entry produces an alert "that social security number entered is a duplicate number", so the record treats the number as a matching key rather than a note (Maryland Department of Budget and Management, 2022).
The identity platform's own automation reaches the same record. Okta's Workflows connector reference states that when an employee is on a pay schedule that syncs with TRAXPayroll, "your update must include all of these fields for the action to succeed", and SSN is among them (Okta, 2026). The input table describes "The employee's Social Security number" as a value the action sends (Okta, 2026), and the page warns that with Pass Empty Values "any fields selected but left blank are cleared, except special fields" (Okta, 2026).
The account task needs three values. The record it starts from renders a fourth, and the agent receives the page rather than the three values.
What do the vendors themselves say?
Okta's Workflows connector reference documents an action that will "Update an employee's fields in BambooHR" (Okta, 2026). It lists the fields a pay-schedule sync requires, names SSN in the input table, and does not say those fields are masked, restricted or redacted in Workflow logs (Okta, 2026). The page covers the connector, not what an Okta administrator or an agent signed in as one receives when the person record is drawn.
Microsoft's managed identity page is about the credential the code runs under. It states that "Managed identities eliminate the need for developers to manage these credentials" and that "This token acquisition doesn't require any secrets" (Microsoft, 2026). That removes the password or client secret an agent would otherwise hold. It says nothing about the employee's data on a page, and an identity with no credential still reads whatever the screen renders.
| Page | What it documents | What a buyer should verify |
|---|---|---|
| Workday hire job aid (Maryland) | Hire Details fields; the SSN in the Identification # field; a duplicate alert | Whether the field is masked after entry, and what a model reading the hire screen receives |
| Okta Workflows connector | Required HR fields, SSN among them; Pass Empty Values clears blanks; no statement about masking in logs | Which values the action sends, and what a log or transcript keeps |
| Microsoft managed identities | A workload token acquired without a credential | That the page covers the agent's credential, not the data on the screen |
The table separates three assurances that are easy to conflate: where the number is typed, that automation carries it into the HR system, and that the agent's own login can be removed. None answers what the model receives when the hire page is open.
Who approves a new account, and what record does the run leave?
The answer has two parts: what the run may touch, and what it leaves behind. OWASP defines excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM", and lists excessive permissions among its root causes (OWASP, Excessive Agency, 2025). A run that can open the hire record, the identity console and the payroll system has permissions for three jobs when the task is one, and NIST's zero trust guide gives the rule for narrowing them: no implicit trust "based solely on their physical or network location" (NIST, Zero Trust, 2020).
The approval belongs to the entitlement grant rather than the typing. Creating an account is clerical until the group list puts the person into a finance application or an admin console, and there a named person should approve the groups.
The record is where most deployments fall short. A transcript shows what the agent typed and an identity log shows the account exists; neither shows what the model received on the hire page. DAPLab sets out the problem in one line: "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (DAPLab, 2026). NIST's guide to PII confidentiality states the rule a record exists to prove: "PII should be protected from inappropriate access, use, and disclosure" (NIST, PII, 2010).
Content on a page can also steer the run: indirect prompt injection research found that page content can "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications" (Greshake et al., 2023). The scope of the run limits which pages it can reach (How Do I Scope a Cloud Key to a Single Agent Task?), and the distance between experiment and scale is where such a run gets handed over (What Is the PII Wall?).
What does a governed environment change?
A governed environment moves the control to the point where the page is drawn. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the hire record can render SSN_001 where the nine digits sit, and later screens render the same token. The account screen is unchanged, because the name, the mail address and the groups are the values the task needs.
The real number resolves only at an approved destination, at the moment of an approved action. For a provisioning run that destination is the identification field itself, on the submit a named person approved, so the record receives the number and the model never did. A named person approves each account and its groups, and every screen as tokens, every action and every approval lands in a record that exports to the organization's monitoring.
The scope matters as much as the mechanism. The control sits on the rendered page, so a feed written directly from the HR system to the identity provider is outside it, and that path needs its own answer.
The comparison for the identity platform sets the identity-side controls next to the screen-level one (RedactSure vs Okta: 2026 Comparison & Alternative).
What the record shows
For the team provisioning a hire, what settles the answer is what the model receives on the page rather than which fields the task needs. The account screen shows a name, a mail address and groups; the hire screen shows the nine-digit number in an identification field the record matches against, and it draws that field whether or not the agent types in it. The account can be built without the number, and the run usually cannot start without the hire record, where the job profile, the location and the start date live. Neither page describes the field being masked or replaced before a model reads the screen, so the answer is no for the run as it is normally assembled, and yes only where the number is tokenized on the page. To check it, name one hire and one account, have the agent create the account with the hire record in scope, and write down the fields the model received on each screen. The comparison between those notes and what each page rendered is the test.
Methodology and limitations
Vendor and knowledge-base pages were read between October 20, 2026 and 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. The page rests on a state job aid for the Workday hire, Okta's connector reference, Microsoft's managed identity page, one OWASP entry, two NIST publications, a prompt injection preprint, a research note and a lab position paper. The job aid is a November 2022 Maryland guide whose screenshots carry a partly garbled text layer, and the connector page documents one action.
No product on this page was tested for this page. "Not described in the pages reviewed" means those pages. Vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, an account created for a new hire, and not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
Can an AI agent provision a new employee without seeing their SSN?
No, not on the run most teams assemble. The account needs a name, a mail address and groups, and none of those is the number. The run begins on the hire record, where the job profile, the location and the start date live, and that page puts the nine digits in an identification field the record matches against. An agent that opens the page reads the field, and the answer turns on that screen rather than on the instruction.
Where does the Social Security number appear on a new hire's record?
In the identification field of the hire record, at the point the person is placed into the position. Maryland's job aid directs the operator to "Enter the nine-digit Social Security Number in the Identification # field", and a duplicate raises an alert that the number is already on file (Maryland Department of Budget and Management, 2022). The record is the authority for the hire, so the field sits beside the job profile and the start date. The identity account is a separate record.
Does the identity provider need the number to create the account?
No. The account is built from a display name, a username or mail address and the groups that carry entitlements, and the number is not among them. That is why provisioning looks like a task an agent can take over. The difficulty is upstream, in the record the run reads to learn who the person is and which groups apply, and that record carries the number.
What does the model hold after a provisioning run?
Whatever the screens it opened drew. On the account form that is a name, an address and a group list. On the hire record it is the same detail plus the nine-digit number, the position and the start date, because a model receives the page rather than a field list. The context then travels into summaries, notes and any file the agent writes, so a value drawn on a screen is worth removing.
Who should approve a new account and its groups?
A named person with authority over the applications those groups open, and the approval should name both the person and the groups. Approving the agent's session is a different decision: it answers who runs the tool, not which entitlements the new employee receives. The distinction matters most when a group carries a finance or administrative application, because the account creation is routine and the group assignment is not.
What record should a security team keep after an agent provisions an account?
One that shows both sides: the screens the model received, the account action the agent took, and the name of the person who approved it. An identity log records the creation and a transcript records the typing, and neither shows what the hire page drew. Keep the rendered page beside the approval and export the set to the team's monitoring, so a reviewer can compare them.
How RedactSure Keeps a Social Security Number Off the Provisioning Screen
A provisioning run that opens the hire record reads the nine-digit number in its identification field, and nothing in the account console separates the two records. Okta's connector reference puts SSN among the fields an HR update must carry (Okta, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the hire page draws the nine digits, and the model carries them into every later step. Inside: the same page renders SSN_001, the account is created from the name, the mail address and the groups, and the number resolves at the identification field only on the submit a named person approved, with every screen and approval 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 provisioning run that opens the hire record has already read the number. Bring one account-creation task and see, with test values, what the model reads on the hire screen and what the approval and record keep. Book a demo