User access review automation means collecting who has access to each app, flagging accounts that should not, and keeping proof that someone reviewed them. Connector-based tools handle apps with an API or SCIM. For the rest, Sai signs in to each admin console like an admin, exports the user list, flags accounts inactive for 90 days and keeps a screenshot of every page as evidence.
What a user access review needs
A user access review is a periodic check that every account in every system still belongs to someone who needs it, with the right level of access. It produces three things: a list of accounts per system, a decision for each flagged account, and evidence that the review happened.
The list is the slow part. Companies use hundreds of SaaS apps: Torii's 2026 benchmark counted about 830 per company on average, with most of them outside formal IT approval (Torii, 2026). Okta reports access reviews among its customers grew 76% in a year (Okta, 2026).
What SOC 2, ISO 27001, PCI DSS and NIST ask for
| Framework | What it says about access | Inactive accounts |
|---|---|---|
| PCI DSS v4.0.1, 8.2.6 | Requirement 8 covers identifying users and authenticating access | Inactive accounts are removed or disabled within 90 days (requirement 8.2.6) |
| NIST SP 800-53, AC-2 | Review accounts at an organization-defined frequency (AC-2) | Disable accounts inactive for an organization-defined period (AC-2(3)) |
| SOC 2, CC6.3 | Access to data and software is authorized, modified or removed (CC6.3) | No fixed number; auditors commonly expect quarterly reviews |
| ISO 27001:2022, A.5.18 | Access rights are reviewed periodically (summary; the standard itself is paywalled) | Set by your own policy; 90 days is a common choice |
This is a summary, not compliance advice. Your auditor and your own policy decide the interval and the evidence.
Why connector-based tools miss some apps
- No API, SCIM or SSO. Governance and GRC tools pull users through integrations. Apps without one fall back to "upload a CSV", which someone has to export by hand.
- The IdP does not know about direct logins. An account created with a password inside the app never shows up in your SSO directory.
- Inactivity lives in the app. The 90-day rule is about the last sign-in to that app. A user who never signs in again never triggers a login hook, which is exactly the question people raise on the Auth0 community.
- Removal is still manual. Even where reviews are automated, revoking access in an app with no write integration is a ticket for someone to click through.
Uday Gajavalli of Truto put it directly: apps without admin API access "force IT to scrape UIs" (Truto). That is the part Sai does.
SaaS admin console automation
SaaS admin console automation means operating an app's admin pages the way an administrator would, to export users, read last sign-in dates or change an account, when the app offers no API for that job.
Sai opens each console in a browser on a cloud computer, signs in through an approval link you complete, uses the console's export button or reads the users table page by page, and saves a dated screenshot of the page it read.
Ways to run a user access review, compared
| Approach | Apps covered | Inactive accounts | Evidence | Removing access |
|---|---|---|---|---|
| Spreadsheet and manual exports | Any, by hand | If someone checks last sign-in | Screenshots you take | By hand |
| IdP reviews (Entra ID Governance, Okta Identity Governance) | Apps behind your SSO | From IdP sign-in data | Built in | Through the IdP |
| Governance and SaaS management tools (ConductorOne, Zluri, Lumos, Torii) | Apps with a connector; CSV upload for the rest | Where the connector reports it | Built in | Automatic where a write connector exists |
| Sai | Any admin console a person can use | From each app's own users page | Exports plus dated screenshots | After your approval, through the console |
If most of your apps are behind SSO with SCIM, start with your IdP or a governance tool. Use Sai for the apps they cannot connect, and feed its export into the same review.
How to automate a user access review with Sai
- List the consoles. The admin URL of each app, and any app with no export so Sai reads the table instead.
- Attach the HR list. Active employees with email and status, so Sai can flag accounts that belong to nobody.
- Approve each sign-in. Sai sends an approval link per console. Passwords and MFA codes stay with you. See approvals.
- Review the flags. Inactive for 90 days, not in the HR list, admin accounts. Record a decision for each.
- Approve the changes. Sai suspends or removes only the accounts you approve, and screenshots the result.
- Repeat next quarter. Ask Sai to save the review as a replayable skill.
The full prompt is in the Start with a prompt tab above.
Run it from your agent or a schedule
Send the review as a task with typed output, so your code gets one row per account and can open tickets for the flags:
curl -s https://api.simular.ai/v1/agents/message \
-H "Authorization: Bearer $SAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"message": "Sign in to {{console}}, export every user with role and last sign-in date, and screenshot the users page. Change nothing.",
"options": {
"inputs": { "console": "https://partners.example.com/admin/users" },
"output_schema": {
"type": "object",
"properties": { "users": { "type": "array", "items": { "type": "object",
"properties": { "email": { "type": "string" }, "role": { "type": "string" }, "lastSignIn": { "type": "string" } } } } }
},
"recordTrajectory": true
},
"wait": false
}'The sign-in arrives as a link-only approval, which a person completes even in unattended runs. Read output.users from /turns, and see structured output for the schema rules and the quick start for keys.
User access review checklist
- Every app in scope, including ones outside SSO.
- For each account: owner, role, admin or not, last sign-in.
- Flags: inactive past your threshold, never signed in, not in the HR list, terminated, shared or generic accounts.
- A decision and a reason for every flag, made by the app owner or manager, not by the person running the export.
- Evidence: the export file, a dated screenshot of the source page and the decision log.
- Removal done and confirmed, with the date.
Limitations
- Each sign-in needs you. Admin logins and MFA are link-only approvals, so a review across many consoles has a person in the loop for each one.
- Some consoles do not show last sign-in. Sai records what the console shows; if an app has no activity data, that column stays empty and the report says so.
- It is not a governance platform. Sai collects and acts on what you ask; certification campaigns, reminders and reviewer workflows belong in your GRC or IGA tool.
- Not compliance advice. Your auditor decides what evidence is enough.
Related use cases: turn a runbook into a scheduled job, give your agent a computer as a tool and enter CSV rows into a web app with no import.
Last reviewed October 17, 2026.