The ERP User Access Review That Argues With Itself

You know the drill. Security exports a user listing. It lands in your inbox as a 40,000-row spreadsheet with column names like BNAME, GLTGB, TRDAT. You rebuild the same pivot tables you built last quarter. You highlight the dormant accounts in yellow. You email the business owner. They reply that six of your exceptions are approved service accounts that have been on the whitelist since 2019.

The tedious part was never the detection. It was the triage — the gap between “the spreadsheet flagged it” and “I would put my name on it”. That gap is where an access review actually consumes your quarter, and it is the specific problem the new access analytics feature in the GrcAI Assistant was built for.

Attach an ERP user or role extract and it runs a deterministic pass across seven exception families before the model writes a single word:

Plus the patterns that fall outside those families and still matter: accounts past their end date but still marked active, active accounts with no owner recorded, and accounts created but never used.

Nobody should test an unfamiliar tool on production access data. So here are two anonymised extracts with invented names and realistic column conventions.

• ⬇ sample-sap-user-access-extract.csv — SAP-shaped: 50 rows, 42 users, headers BNAME, USTYP, TRDAT, GLTGB, AGR_NAME.
• ⬇ sample-oracle-ebs-user-access-extract.csv — Oracle EBS-shaped: 22 rows, 18 users, headers USER_NAME, RESPONSIBILITY_NAME, END_DATE.

Run both. Same tool, no mapping screen, no configuration — the second file proves the column detection is pattern-based rather than hardcoded to one vendor.

Open the assistant, click + in the message box, choose 📊 Upload access data, and attach the file. Then run these three prompts in order. They are one-click suggestions in the interface, but here they are in full so you can adapt them to your own methodology.

Prompt 1 — findings, not a description

Note the last sentence. Most AI audit demos reward the model for producing a long list. This one gives it explicit permission to say “this is not a finding” — which is the difference between a work product and a word count.

Prompt 2 — show me the records

This is the prompt that makes the output defensible. A finding without a row reference is an opinion. A finding that reads row 24 · BNAME=SAP* · AGR_NAME=SAP_ALL is evidence you can paste into a workpaper.

The detection itself is deterministic code, not model output. Row numbers, counts and field values are computed first, then handed to the model as grounded facts it is instructed not to depart from. The model writes the narrative. It does not invent the row references.

Prompt 3 — now argue against yourself

This is the prompt that matters. And the sample file is rigged to test it.

Run prompt 1 on the SAP file and you get 25 findings. Eight of them say “user ID appears on 2 rows.”

Those eight are wrong.

It is a role-assignment extract — one row per user per role. A user with two roles produces two rows. That is not a duplicate account; that is the file format working correctly. Any tool that reports it as an exception is generating work for you, not saving it.

So when you run prompt 3, watch what happens to those eight. If they come back restated as real exceptions, the tool has failed and you should close the tab. If they come back identified as an artefact of the extract’s grain — with the reasoning spelled out — then the third pass is doing the thing that separates useful automation from an exception factory.

Every detector in the engine declares, in code, what it is known to get wrong. Duplicate detection declares row-per-role grain. Dormancy declares seasonal roles and approved service accounts. Generic-account detection declares legitimate naming standards. The third pass reads those declarations. It is not the model being modest — it is the engine being honest about its own precision.

While you are in there, look for J.SMITH and JSMITH. Same name, two accounts, and one of them holds Z_ADMIN_SECURITY. That one is real.

A finding you can hand to a control owner has four parts. Judge any tool — this one included — on whether it produces all four.

Two out of four is a spreadsheet. Four out of four is an audit finding.

The realistic use is not replacing your access review. It is the first pass:

• Scoping — run it on the raw extract before you build the review population, so you know what you are dealing with.
• Interim testing — catch the dormant and terminated-but-active accounts early enough that remediation lands inside the period.
• Reviewing someone else’s work — run the third prompt against a completed access review and see which conclusions survive.
• Training — hand a new joiner the sample file and the three prompts. They will learn more about access review judgement in twenty minutes than from a methodology deck.