The permission audit your AI needs

Your permissions have probably been wrong for two years. It hasn't mattered, because finding anything in an HRIS requires knowing which report to build, which filter to apply, and which screen it lives on. Nobody was going to do that on a Tuesday afternoon to find out what a colleague earns.

Then someone puts a chat box on top of it.

The AI didn't grant anyone new access. Every vendor building this correctly makes the assistant inherit the requesting user's permissions, and both Rippling and HiBob say that's what they do. What changed is the cost of discovery. Data that was technically accessible and practically buried is now one plain-English question away.

That's the whole argument for doing this work first. Not because AI is dangerous. Because AI is efficient, and efficiency is a problem when it's pointed at a permission model nobody has looked at since go-live.

The vendors say this out loud

You don't have to take our word for the mechanism. Microsoft, which has more production experience with an AI layer over an enterprise permission model than anyone, documents it in its own guidance:

"Because of the power and speed AI can proactively surface content that might be obsolete, over-permissioned, or lack governance controls, generative AI amplifies the problem of oversharing data."

And Microsoft's separate foundational deployment guidance for Copilot sets out three pillars in a deliberate order: remediate oversharing, then set up guardrails, then meet regulations. Oversharing remediation comes before deployment, not after.

The pattern transfers cleanly to an HRIS. A shared site becomes a saved report. A "share with anyone" link becomes an all-employees permission group. An ownerless site becomes an orphaned admin profile nobody can explain. The mechanics differ; the failure is identical.

There's a supporting number worth carrying into the conversation with a skeptical exec. IBM's 2025 breach study found that 97% of organizations reporting an AI-related security incident lacked proper AI access controls, and that 63% had no AI governance policy at all. And the best-documented HR-plus-AI incident on record – the McHire/Paradox exposure in mid-2025, affecting applicant data at very large scale – had two root causes: an administrative test account that had been live and unremediated since 2019, and a missing object-level authorization check.

Neither of those is an AI failure. Both are exactly what a permission audit finds.

The legal point most HR content gets wrong

Before the procedure, a correction that changes what you're auditing for.

Three federal regimes impose an explicit separate-file, confidential-medical-record mandate on employers generally:

The ADA – information from medical examinations and inquiries must be "collected and maintained on separate forms and in separate medical files and be treated as a confidential medical record" (29 CFR 1630.14), with narrow exceptions for necessary work restrictions, emergency personnel, and government investigators.
GINA – genetic information must be maintained on forms and in files separate from personnel files and treated as a confidential medical record (29 CFR 1635.9).
The FMLA – medical certifications and histories must be maintained as confidential medical records in files separate from the usual personnel files (29 CFR 825.500(g)).

Federal contractors carry a fourth: Section 503 of the Rehabilitation Act requires disability self-identification data to be kept confidential in a data analysis file separate from personnel records.

HIPAA is not on that list, and this is the error you'll hear most often. HHS is explicit: "The Privacy Rule does not protect your employment records, even if the information in those records is health-related," and "in most cases, the Privacy Rule does not apply to the actions of an employer." Your group health plan can be a covered entity with real obligations. The sick note in an employee's HR file is not HIPAA-protected. It's ADA-protected, which is a different rule with different mechanics.

Now the consequence, which is the sharpest reason to run this audit:

If the ADA/GINA/FMLA separation exists in your system as a filing convention – a folder, a document category – but not as an access control the retrieval layer honors, an AI assistant that indexes documents will re-merge exactly what the law required you to separate.

Everything else on the sensitivity map is restricted by practice, by contract, or by state law rather than by a federal separate-file statute: SSN, date of birth, home address, bank and direct deposit, garnishments, background-check results under FCRA, I-9s (separate storage is permitted and universally recommended as an audit-exposure control, not a statutory requirement), EEO self-identification (strong practice for most employers, though federal contractors have the Section 503 duty above), compensation, discipline, termination reasons, and investigation files. For EU or UK staff, GDPR Article 9 special-category data – health, trade union membership, biometrics, ethnicity – carries its own prohibition-unless-condition-applies structure.

Being precise about this is worth the paragraph. It tells you which findings are legal exposure and which are judgment calls.

The procedure

Sized for a 15–250 person company on a modern HRIS. Plan on two to four weeks of real work, mostly in steps 3 and 4.

Step 0 – Freeze the AI rollout and take a snapshot

Fix an audit date. Export the current state before anyone starts tidying. You want a defensible before-and-after, and you will not get one if remediation begins during discovery.

Step 1 – Inventory every role and admin, with an owner

Export every permission profile or group and its membership.

On Rippling: Super Admins first – they hold full access across HR, IT, and Finance, and only a Super Admin can modify another. Rippling's own guidance is to keep that list short. Then every Custom Admin profile with its module scope, employee-group scope, and action set.

On HiBob: every permission group, its members, and how membership is determined – named individuals, all employees, or conditional groups built on attributes like lifecycle status.

For each role, answer one question: what job function justifies this? And record a named owner. A role with no owner is the HRIS equivalent of an abandoned server.

Step 2 – Produce a user-by-permission matrix, as data

Not screenshots. A table you can diff.

This is also the evidence artifact your SOC 2 auditor tests against – criterion CC6.3 requires that access is authorized, modified, or removed "giving consideration to the concepts of least privilege and segregation of duties." Retain reviewer identity, decision, justification, and grant date for each line.

Step 3 – Diff granted access against current job function

For every person, compare what they can reach against the role they hold today, not the role they held when access was granted.

This is the mover check, and it's the one that finds the most. Rights get added on transfer and never subtracted. The formal name is privilege creep; the practical version is the person who ran payroll for six months in 2024 and still can.

The frameworks all point at this specifically. NIST SP 800-53 AC-2, item l. requires aligning account management with personnel termination and transfer processes. AC-6(7), titled Review of User Privileges, requires both reviewing privileges and reassigning or removing them – most organizations do the first half. ISO/IEC 27001:2022 A.5.18 uses the verbs "provisioned, reviewed, modified and removed."

Note what none of them do: mandate a cadence. Every one of them leaves frequency to you. You pick it, then you're audited against your own choice. Don't let anyone tell you quarterly is "required."

Step 4 – Check sensitive-field visibility, class by class

Go through the list: SSN and national ID; bank and direct deposit; date of birth; home address; I-9 and work authorization; ADA accommodation and medical records; FMLA and leave certifications; genetic information; EEO self-ID; garnishments; background-check results; performance and discipline; compensation; termination reasons; investigation and whistleblower files.

For each, list every role that can see it. Then ask the question from the section above: is the legal separation expressed as an access control, or only as a folder?

One platform-specific trap. On HiBob, permissions attach to categories, not individual fields – the developer documentation states it plainly: "permissions are always assigned to categories rather than individual fields." So if a sensitive field sits inside a broadly granted category, adjusting the grant doesn't fix it. You have to move the field. On Rippling, the documented model restricts data types; we have not found a documented control for masking an individual field inside an otherwise-visible record. Confirm the behavior you need in your own tenant rather than assuming it.

Step 5 – Enumerate API tokens, service users, and integration scopes

Not just which ones exist. What each one can reach.

Then answer the question that determines your AI blast radius: for each AI feature, does it run as the asking user, or as a service principal?

This is not academic. HiBob's in-product AI enforces the requesting user's permissions at query time. Its MCP server, at launch, authenticated with a service user – meaning that one service user's permission group defined everything the connected AI client could see, regardless of who was asking. HiBob moved to OAuth in mid-2026 so clients connect on behalf of the signed-in user, but its own documentation was inconsistent on this for a period, and un-migrated integrations may still be running the old way.

Both statements from that vendor are true. They describe different things. Knowing which one applies to your tenant is the single most actionable technical finding this audit produces.

The wider security guidance has caught up to this. Microsoft's July 2026 guidance on least privilege for AI agents puts it directly: "is the agent acting under its own identity, a delegated user scope, or some mix of both? That ambiguity matters because it determines who's accountable when something goes wrong." Its prescription is to treat agents as first-class principals – lifecycle-managed identity, explicit roles, tightly scoped permissions, and an allowlist of tools. The Model Context Protocol specification takes the same line, explicitly prohibiting token passthrough and warning against wildcard or omnibus scopes.

While you're here: no *, no all, no full-access tokens. If one exists, that's the finding.

Step 6 – Third-party app access

Every connected application, its OAuth grants, who authorized it, and when. Verizon's 2026 breach report put third-party involvement at 48% of breaches, up from 30% – roughly a 60% year-over-year increase. Workday's August 2025 incidents came through a malicious OAuth app approval and a compromised third-party integration token, not through the platform itself.

Step 7 – Offboarded users and dormant accounts

Every account with no login in 90 days. Every terminated employee's residual access. Every contractor whose engagement ended.

On Rippling, verify that offboarding automation is actually configured – app access provisioned through Rippling IT revokes automatically only if it is, and unconnected apps always require manual deprovisioning.

Varonis' analysis across 1,000 organizations found 88% had "ghost users" – dormant or orphaned identities – in their environments. The McHire root cause was a test account from 2019.

Step 8 – Break-glass and shared accounts

Identify every emergency or elevated account. Confirm each is individually attributable, or at minimum monitored. Confirm there's a process for rotating shared credentials when someone leaves the group. Log privileged use.

Step 9 – Every automation: which one runs as whom

This is the step almost everyone skips, and it's the confused-deputy surface sitting inside your HRIS already.

For each workflow, approval chain, and scheduled job: what triggers it, what it does, where the output goes, and under whose authority it executes. On Rippling, Workflow Automator can trigger on salary changes among many other events, and workflow-building is not restricted to admins. A notification that fires on a comp change into a broad Slack channel is a disclosure vector that has nothing to do with AI – and everything to do with what an AI assistant makes easy to find and clone.

The OWASP Top 10 for LLM Applications names this category directly. LLM06, Excessive Agency, has three root causes: excessive functionality, excessive permissions, excessive autonomy. Its core mitigation is the same question as Step 5 – run actions in the context of the specific user, with minimum privileges.

Step 10 – Reports, dashboards, and scheduled exports

A saved report is a permission bypass with a friendly name. Enumerate every one, every recipient of every scheduled export, and every shared dashboard link. Then check who can build new reports, because report builders frequently escape field-level restriction.

Step 11 – Documents, knowledge base, and whatever the AI will retrieve from

Every document category and its permission scope – and then the question that matters: does the AI's retrieval index respect those scopes, or flatten them?

This is where the ADA/GINA/FMLA problem from earlier actually lands. It is also the least-documented aspect of every HR AI product we've evaluated. Ask your vendor whether there is an equivalent of Microsoft's Restricted Content Discovery – a control that keeps content out of AI retrieval without changing its underlying permissions. Archive or exclude stale content. Curate the corpus you point the assistant at rather than pointing it at everything.

Step 12 – External and contractor access

Contractors, staffing agencies, your PEO or benefits broker, and any guest identity. On Rippling, contractors get limited self-service plus optionally provisioned apps – verify what "optionally" resolved to in practice.

Step 13 – Remediate, then re-test

Revoke, re-scope, move fields between categories, tighten tokens. Then re-run the Step 2 export and diff it.

The re-test is what separates an audit from a spreadsheet exercise. Only then do you enable the AI feature – in a scoped pilot, with logging on, and with a deliberate adversarial pass: try to reach compensation, medical, and termination data you shouldn't be able to reach, directly and by aggregate.

The aggregation problem, which is worse at your size

Row-level scoping protects rows. It does not protect against re-identification in a small denominator.

"What's the average salary on the sales team" is a permissible query for a lot of people. If sales has three people and the asker knows two of them, it is individual compensation disclosure with a math step in front of it.

We have found no public evidence that either Rippling or HiBob applies minimum-group-size thresholds to aggregate queries. Test it on your own data before anyone else gets access. If the assistant will happily average over n=2, you need a policy answer, because there isn't a product one.

The related structural problem: at 40 employees there is no segregation of duties. The Head of Ops is the HR admin, the IT admin, and the Finance admin, because there is one of her. One permission profile spans the entire graph. NIST AC-5 exists to prevent abuse of authorized privilege absent collusion – which is a control that assumes there are enough people to collude. You don't have that. You have to compensate with narrower profiles, tighter field-level restriction, and actual logging, not with an org chart.

Two questions to put to your vendor, in writing

Everything above is work you can do yourself. These two you cannot.

Does the AI run as the asking user, or as a service principal? Ask about each surface separately – the in-product assistant, the MCP or API layer, and any chat integration.
Are AI queries logged, or only AI actions? Actions almost certainly are, because they execute through normal paths and inherit normal logging. The read is the risk. "Who asked what, and which records came back" is the audit record you'll want the first time something goes wrong, and neither major vendor documents it publicly.

Add a third if you have EU staff: where does model inference happen, and under what transfer basis?

Cadence, once you've done it once

Privileged and admin access: quarterly.
Standard access: semi-annually or annually.
Event-driven: every leaver, every mover, every incident – and old rights come off before new ones go on.
AI-specific: re-review whenever an agent's scope or tool set changes.

Pick your cadence, write it down, and follow it. You'll be measured against your own documented standard, not against someone else's.

The audit on one page

Freeze the rollout; snapshot current state
Inventory every role and admin, each with a named owner
Export a user × permission matrix – data, not screenshots
Diff granted access against current job function (the mover check)
Sensitive fields, class by class: is the legal separation an access control or a folder?
API tokens and service users – scopes, and whether each AI surface runs as the user or a service principal
Third-party app OAuth grants
Dormant accounts, offboarded users, ex-contractors
Break-glass and shared accounts – attributable, rotated, logged
Every automation: which runs as whom
Saved reports, scheduled exports, dashboards – and who can build reports
Documents and the retrieval corpus – does the AI index respect scopes or flatten them?
External and contractor access
Remediate, re-export, diff – then pilot with logging on and an adversarial pass

Cadence: privileged quarterly, standard annually, event-driven on every leaver and mover, and a re-review whenever an AI agent's scope changes.

People Street's take

Nobody wants to run a permission audit. It has no launch, no demo, and no slide. It's three weeks of exports and uncomfortable questions about who gave the former ops contractor admin rights.

But it is the only thing standing between "our AI inherits your permissions" and an actual guarantee. The vendors have engineered that sentence carefully, and they mean it. What they haven't said – because it isn't their job to – is that the sentence hands the entire safety question back to you.

The companies that turn AI on safely aren't the ones that read the vendor's security page hardest. They're the ones who could already produce a table of who can see compensation, because they built the system that way and never let it drift.

If you can't produce that table today, that's the gap – and it's a gap whether or not you ever enable a single AI feature. Book a 20-minute call and we'll tell you exactly what we'd look at first.