Access Control for Internal Tools: SSO, Roles and Audit Logs (2026)
How to decide who can sign in to an internal tool, what each role can see and change, and what to log, with a practical role matrix and where SSO and audit logs sit on common platforms’ plans.
Key Takeaways
- Separate sign-in from permissions. SSO answers who you are. Roles answer what you may do. A tool with perfect SSO and one “admin” role for everyone is still wide open inside.
- Start from deny by default. Give each role the minimum it needs, as NIST’s least-privilege principle and OWASP’s access-control guidance both recommend, and add access when someone asks for it.
- Record-level rules are where leaks happen. “Employees see only their own requests” and “managers see their team’s” must be enforced on the server, not just hidden in the interface.
- Log changes to sensitive records and to permissions themselves. Who, what, when and from where. OWASP’s logging guidance lists those four as the core of every log entry.
- Check the plan, not just the product. On most internal tool platforms, SAML SSO, SCIM and audit logs sit on business or enterprise tiers. Confirm the tier before you build.
Quick-Start Prioritization Framework
| Control | What it answers | Minimum for a small team | When to require more |
|---|---|---|---|
| Authentication | Who is this person? | Company Google or Microsoft sign-in, or invited accounts only | SAML SSO through your identity provider when policy requires it |
| Provisioning | Who should have an account at all? | Manual invite and a leaver checklist | SCIM from your identity provider at larger headcounts |
| Roles | What may this person do? | 3 to 5 roles with written definitions | Custom or attribute-based roles for complex orgs |
| Record-level rules | Which records may they see? | Own records, team records, all records | Field-level rules for salary, bank or health data |
| Audit logging | Who changed what, and when? | A change-history table on sensitive records | Platform audit logs with export or streaming to a SIEM |
Internal tools hold the data people care most about: salaries in an HR app, vendor bank details in a purchase flow, admin passwords half-pasted into an IT ticket. Yet they are often built with one rule, “everyone at the company can see everything,” because that is the fastest way to ship. Access control for an internal tool comes down to three questions. Who can get in (authentication, including single sign-on)? What can each person see and do once inside (authorization, usually roles)? And can you later reconstruct who did what (audit logging)? This guide covers each in plain terms, with a role matrix you can copy, the record-level rules most tools miss, and a realistic view of which platform plans include SSO and audit logs.
Authentication: who gets in
Authentication is the front door. For an internal tool you have three common options, and the right one depends mostly on your company’s identity setup and policies.
Invited accounts only
Only people an admin invites can sign in. Simple, and fine for small teams. The weakness is offboarding: if someone leaves, an admin must remember to remove them. Pair it with a leaver checklist item, “remove from internal tools,” owned by IT.
Sign in with Google or Microsoft
Users sign in with their work Google Workspace or Microsoft account. Passwords and multi-factor authentication stay with your identity provider, and when IT disables the work account the person can no longer sign in. Restrict sign-up to your company’s email domain so a personal Gmail can’t create an account.
SAML or OIDC single sign-on
Full SSO connects the tool to an identity provider such as Okta or Microsoft Entra ID, so access is granted and revoked centrally, often with group-based rules. Many security policies and customer questionnaires require it for any app holding company data. It is also the feature most often reserved for higher plans; see the plan table below.
Provisioning and offboarding
Most access problems in small companies are not hackers. They are former employees, contractors whose project ended, and interns who still have admin rights two years later.
Joiners
Decide the default role for a new account. It should be the least privileged one, usually “requester” or “viewer,” never “admin.” Managers request elevated access, and the tool owner grants it.
Movers
When someone changes team, their old access rarely gets removed. Review roles whenever HR records a transfer, and run a quarterly access review: export the user list with roles and have each team lead confirm it.
Leavers and SCIM
With Google or Microsoft sign-in or SSO, disabling the work account blocks sign-in. SCIM goes further: the identity provider creates, updates and deactivates accounts in the tool automatically. It earns its keep once you have many tools and frequent joiners and leavers; for one or two internal tools, a checklist is usually enough.
Roles: what each person may do
Roles turn “who are you” into “what can you do.” Keep them few, named after jobs people recognize, and written down.
| Role | Create | See | Edit | Approve | Admin |
|---|---|---|---|---|---|
| Requester | Own requests | Own requests | Own requests while in Draft | No | No |
| Agent (works the queue) | On behalf of others | All requests in their queue | Status, assignee, internal notes | No | No |
| Approver (e.g. manager) | Own requests | Own team’s requests | Comments only | Their team, up to a limit | No |
| Finance or HR reviewer | No | All requests in their domain, including sensitive fields | Sensitive fields | Final sign-off | No |
| Auditor or viewer | No | All, read-only | No | No | No |
| Admin | Yes | All | All | No by default | Users, roles, settings |
Least privilege
NIST defines least privilege as restricting users’ access privileges to the minimum necessary to accomplish their tasks. In practice, every role starts with nothing and gains only what the table says.
Separation of duties
NIST describes separation of duty as the principle that no user should have enough privileges to misuse the system on their own. For internal tools that means: the person who submits a purchase can’t approve it, the admin who manages roles doesn’t approve payments by default, and the person who enters vendor bank details isn’t the one who releases payment.
Avoid role sprawl
If you have more roles than teams, you have too many. When someone needs one extra permission, consider whether it belongs in an existing role rather than creating “Agent plus” and “Agent plus 2.”
Record-level and field-level rules
Roles say what kind of thing someone can do. Record-level rules say which records they can do it to. This is where most internal tool leaks happen, and OWASP ranks broken access control first in its 2021 Top 10.
Enforce ownership on the server
OWASP’s guidance is that access controls should enforce record ownership. A requester should get an error, not just a hidden button, if they change a URL from request 1041 to 1042. Ask whoever builds the tool, or check the platform’s docs, to confirm the filtering happens on the server or in the query, not only in the page.
Team scoping
Managers see their direct reports’ records. That requires the tool to know the reporting line, either from a manager field on each user or from your directory. Keep that field current, or approvals go to the wrong person.
Sensitive fields
Some fields deserve their own rule: salary in an onboarding app, bank details in a vendor form, medical notes in a leave request. Either store them in a separate table only the right role can read, or hide them from every role except the one that needs them. Don’t put them in free-text comments, where they escape every rule.
Audit logs: reconstructing who did what
An audit log lets you answer “who approved this?” or “who changed the bank details?” months later. It also deters misuse, because people know changes are recorded.
What to record
OWASP’s Logging Cheat Sheet organizes log content around when, where, who and what. For an internal tool that becomes: timestamp; which screen or action; the user and their address or device; and the event, including old and new values for changed fields.
What to log, at minimum
- Sign-ins and failed sign-ins.
- Every change to roles and permissions.
- Approvals and rejections, with the approver and the amount.
- Changes to sensitive fields (bank details, salary, access rights).
- Exports and bulk deletes.
- Access-control failures, which OWASP recommends logging and alerting on when repeated.
Platform audit logs versus your own history table
Platform audit logs record what builders and users did in the platform. A change-history table inside your app records business events: “status changed from Pending to Approved by J. Lee at 14:02.” Many teams need both. If the platform plan you can afford has no audit log, a history table on sensitive records covers most day-to-day questions.
Where SSO and audit logs sit on common platforms
Before you build, check that the plan you will buy includes what your policy requires. This table summarizes each vendor’s own pricing page on 11 November 2026. Plans change, so confirm on the page before committing.
| Platform | SAML or enterprise SSO | Audit logs | Notes from the pricing page |
|---|---|---|---|
| Retool | Enterprise (SSO, SAML, SCIM, 2FA) | Business and Enterprise (streaming on Enterprise) | Rich permissions on Business; granular roles on Enterprise |
| Appsmith | Enterprise (SAML, OIDC) | Business and Enterprise | Free plan lists Google SSO; Business adds custom roles |
| ToolJet | Team plan and above (Google, GitHub, OIDC, LDAP, SAML) | 14 days on Team; unlimited on Enterprise | Team is $199 per builder a month billed annually |
| Softr | Enterprise (SAML, OpenID) and SCIM | Enterprise | Business adds 2FA and domain-restricted signup |
A practical setup for a 50 to 300 person company
If you have no formal security team, this baseline covers most of the risk without enterprise pricing.
- Sign-in with company Google or Microsoft accounts, restricted to your domain, or invited accounts only.
- Three to five roles, written down in one short document, with “requester” as the default.
- Server-side rules so people see only their own, their team’s or their queue’s records.
- Sensitive fields readable only by the role that needs them.
- A change-history table on approvals, roles and sensitive fields.
- A quarterly access review and a leaver checklist item for every internal tool.
- One named owner who approves any new admin.
Common mistakes
- Treating SSO as the whole answer and giving every signed-in user full access.
- Hiding data in the interface without enforcing the rule on the server.
- Making the builder the permanent admin of every tool.
- Letting the submitter also approve their own request.
- Storing sensitive details in comment fields.
- No offboarding step, so contractors keep access for years.
- Discovering after building that the required SSO is on a plan three times the budget.
If you’d rather not build this yourself
If you’d rather not do this yourself, Floot, the AI app builder that publishes this site, can build an internal tool with its own sign-in (email, Google or Microsoft), the roles and record rules you describe, and a change-history table, and can publish it so only invited people can open it. Floot does not document built-in SAML SSO, SCIM or a platform audit log, so if those are hard requirements, choose a platform plan that lists them.
Frequently Asked Questions
Do internal tools need single sign-on?
Not always. Sign-in with company Google or Microsoft accounts restricted to your domain covers many small teams. SAML or OIDC SSO through an identity provider becomes necessary when security policy, an auditor or a customer contract requires central access control.
What is the difference between SSO and SCIM?
SSO lets people sign in with their company identity. SCIM lets the identity provider create, update and deactivate their accounts in the tool automatically, so leavers lose access without manual steps.
How many roles should an internal tool have?
Usually three to five: requester, the people who work the queue, approver, read-only viewer and admin. More roles than teams is a sign of sprawl.
What should an audit log capture?
When, where, who and what, following OWASP’s logging guidance: timestamp, the action or screen, the user and their address or device, and the event with old and new values for changed fields.
Which internal tool platforms include audit logs?
On their pricing pages in November 2026, Retool lists audit logs on Business and Enterprise, Appsmith on Business and Enterprise, ToolJet on Team (14 days) and Enterprise, and Softr on Enterprise.
How do I stop someone approving their own request?
Apply separation of duties in the approval rule: the approver must be a different user from the requester, and if the requester is the usual approver, route to their manager or a named backup.
Sources
- NIST, Glossary: least privilege, 2026 https://csrc.nist.gov/glossary/term/least_privilege
- NIST, Glossary: separation of duty, 2026 https://csrc.nist.gov/glossary/term/separation_of_duty
- OWASP, Top 10 A01:2021 Broken Access Control, 2021 https://top10.owasp.org/2021/A01_2021-Broken_Access_Control
- OWASP, Logging Cheat Sheet, 2026 https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- Retool, Pricing, 2026 https://retool.com/pricing
- Appsmith, Pricing, 2026 https://www.appsmith.com/pricing
- ToolJet, Pricing, 2026 https://www.tooljet.com/pricing
- Softr, Pricing, 2026 https://www.softr.io/pricing