The Short Answer
On ibl.ai, separation of duties is enforced inside the admin console itself: the Management panel splits into eight sub-tabs — Users, Groups, Roles, Policies, Teams, Alerts, Applications and Onboarding — and six are gated by their own permission, so an administrator who can manage users cannot read role or policy configuration unless that grant is made explicitly. Because you own all the code and the data, every identity that can reach those settings is one you grant and revoke.
That is a narrower claim than "we have RBAC," and the narrowness is the point.
Administrative RBAC is now common on managed AI platforms, and this post says so before it says anything else. What varies between them is granularity. What is uniform is that the code enforcing the split belongs to the vendor, and so does the log that records who crossed it.
This post gives the shipped permission names, maps them onto the access-control family in NIST SP 800-53 Rev. 5, and states plainly where a managed tenant runs out of road.
What is separation of duties in an AI platform?
Separation of duties is the requirement that no single person hold every step of a sensitive process. It is control AC-5 in the access-control family of NIST SP 800-53 Rev. 5, and it travels with AC-6, least privilege, in the same family.
AC-5's own discussion names the case this post is about: "ensuring that security personnel who administer access control functions do not also administer audit functions."
Applied to an AI platform, the sensitive process is not a wire transfer. It is the chain that runs from who is in the organization, through what a role may do, to which resources that role reaches — and then to the log that records who changed any of it.
Collapse that chain into one administrator account and you have built the thing the control exists to prevent. The same identity can grant itself a capability, point it at the whole tenant, and then read — or stop reading — the record.
The failure is not hypothetical in the AI era, because the capability being granted is no longer "read this folder." It is "call this model, with these credentials, against this dataset, on behalf of this agent." That is why day-one controls matter more for agents than they did for shadow IT: an unapproved file store held data, whereas an over-granted agent takes actions.
Which ibl.ai organization settings tabs are permission-gated?
ibl.ai's organization settings dialog groups its tabs under four headings — Workspace, Finance, AI & data and System — and the Management tab under Workspace is itself split into eight sub-tabs.
Six of the eight are gated by their own permission, enumerated in the public iblai-vibe-account skill in github.com/iblai/vibe.
| Management sub-tab | What it administers | Permission required |
|---|---|---|
| Users | The organization-wide directory: role, attached policies, active status | can_manage_users |
| Groups | RBAC groups that bundle users for policy assignment | /groups/#list |
| Roles | Named bundles of permissions, as actions and field-level data actions | /roles/#list |
| Policies | Bindings of a role to users or groups on a set of resources | /policies/#list |
| Teams | Curated, shareable sets of users — for analytics visibility or notifications | /usergroups/#list or can_invite |
| Alerts | Watched users paired with watchers, each on its own event subscription | /watchedgroups/#list |
| Applications | Applications to join the organization, and the questions applicants answer | Anyone who can open Management (watchers excepted) |
| Onboarding | Which agents greet new members, and how each introduces itself | Anyone who can open Management (watchers excepted) |
Six sub-tabs, seven permission names. The rebuild was released in v2.12.0 on 12 October 2026 — the release tag is public, as is the skill that documents the props.
Every other tab in the dialog — Organization, Integrations, Monetization, Benchmarks, Memory and Advanced — requires organization-admin status, with Monetization also requiring can_sell_items.
Management and Billing are the two that answer to RBAC instead: Billing renders for an admin or a can_sell_items holder once the organization's paywall is on.
Can an administrator who manages users also edit AI access policies?
Not unless that second grant was made deliberately. can_manage_users and /policies/#list are different permissions on ibl.ai, so holding the first does not confer the second, and a sub-tab a person cannot use is not rendered for them.
The practical shape is a help-desk role. It can invite people, flip a user active or inactive, and reassign the predefined Admin/User role on a row — and it cannot open Roles or Policies to see, let alone change, what those roles actually reach.
A second useful detail: on the Users sub-tab, changing a person's role clears their attached policies, so permissions are reassigned explicitly for the new role rather than accumulating silently.
Walkthroughs for each tab are in the docs — Users, Groups, Roles, Policies, Teams and Alerts.
This is the same granularity ibl.ai applies to agent-level access, where role-based access control is what makes it safe to let non-administrators build agents at all. The difference is that here the resource being protected is the permission model itself.
How does role-based access control actually work on ibl.ai?
Three objects, and they are deliberately boring — the same decomposition a security team already knows from cloud IAM.
A role is a named bundle of permissions. Its actions take the form Namespace/Resource/verb and accept wildcards, and a role may additionally carry data actions that reach an individual field rather than a whole object.
A policy grants a role's permissions to a set of users or groups on a set of resources. A group bundles users so one policy assignment covers all of them.
Resources are hierarchical paths. A policy granted on the collection of all agents covers every agent in the organization; granted on a single agent's path, it stops at that agent. That hierarchy is what makes least privilege expressible rather than aspirational.
The platform seeds 29 default roles as starting points — a tenant admin holding Ibl.*, read-only and editor roles scoped to one agent, an analytics viewer, a notification manager, an enrollment manager, billing and CRM tiers, and list-only roles that exist purely to populate pickers.
They are enumerated in the public iblai-vibe-rbac skill.
Built-in roles and policies are protected: their delete buttons are disabled, with the tooltips "Cannot delete internal roles" and "Cannot delete internal policies."
Who can read the AI audit log?
A third grant again, separate from both user administration and policy administration. On ibl.ai the audit log requires Ibl.Analytics/Core/read — or the Ibl.* wildcard an organization admin holds — and a caller without it gets an explicit 403 state rather than an empty table.
That distinction matters more than it looks. A panel that renders blank for an unauthorized reader is indistinguishable from a panel with nothing to show, which is exactly the ambiguity an investigator cannot afford.
The agent audit skill states the three states the component renders: empty, error, and 403.
What the log holds is who changed what and when: an actor email, a humanized description of the change naming the fields it touched, and a timestamp — filterable by actor, by date range, and by action type across create, update and delete.
The walkthroughs are Analytics: Audit and Agent Settings: Audit.
Separating reading the log from changing the configuration is the second half of AC-5. An administrator who can rewrite a policy and also curate the record of having done so has not been separated from anything.
What happens if you enable RBAC and pass no permissions?
Management disappears — even for an organization admin. This is the fail-closed default, and it is worth stating because the opposite choice is the common one.
The check function behind every gate returns true when RBAC is off, and denies everything when RBAC is on and the permissions object is empty.
The permissions themselves come from a single platform endpoint, POST /dm/api/core/rbac/permissions/check/.
The account skill puts the rule in one line: pass both, or pass neither — enabling the flag alone is strictly worse than omitting it.
A related nicety: asking the dialog to open a tab the viewer may not open lands them on the first tab they can see, rather than on a denial screen. A watcher sent to the Organization tab gets the tab they are entitled to.
Fail-closed is the correct direction for an access model, and it is checkable here because the code is open. github.com/iblai/os carries the application under the MIT licence; github.com/iblai/vibe carries the skills quoted throughout this post.
Where does separation of duties stop on a managed AI platform?
At the tenant boundary — and the concession comes first, because the opposite claim is false. The major managed AI platforms do ship administrative separation of duties inside your tenant, and several document it well.
Claude Enterprise has a membership_admin role distinct from owner, custom roles pairing a resource with an action, and a read-only read:org_audit scope described as being for security-audit integrations.
Glean states that its Admin role cannot assign Super Admin.
Microsoft Entra, which Copilot inherits, assigns user administration to User Administrator while role assignment and role settings require Privileged Role Administrator.
ChatGPT Enterprise ships reusable custom roles gating per-feature access.
So the real difference is not whether a managed platform can divide its admin console.
It is that on a managed platform there is, by construction, a provider-side plane above your tenant — support engineers, platform operators, an incident process — and your roles and policies do not reach it.
That is not an accusation of bad faith. It is what "managed" means: someone else operates the control plane, and operation requires access. Several vendors govern that access explicitly rather than hiding it.
Azure's security baseline for Azure OpenAI supports Customer Lockbox, so a customer reviews and approves or rejects each Microsoft data-access request.
AWS states that no AWS operator can access customer instances inside the Nitro System.
Glean's cloud-prem model names the roles Glean itself assumes in a customer's AWS account, and recommends the customer create an auditable admin service role whose access can be turned off with a Service Control Policy.
Those are real controls, and they are the right thing to ask a vendor for.
What they share is their instrument: you audit the provider plane through someone else's attestation — a SOC 2 report, or an approval prompt — rather than by reading the enforcement code and the log yourself.
On ibl.ai you own all the code and the data.
You receive the source under a perpetual licence and run it inside your own perimeter, so the user directory, the roles, the policies, the permission-check endpoint and the audit store are all on infrastructure your own staff administer.
Three things follow. The permission model is auditable rather than attested, because the enforcement code is in your repository and the audit rows are in your database.
It is extensible — a control your regulator asks for is a change you make, not a feature request you file. And it is bounded: the set of identities that can reach the admin console is one you enumerate, grant and revoke.
That last point is the honest version of the ownership argument, and it is deliberately not "nobody outside your organization has access." Self-hosted enterprise software is usually installed and upgraded with a vendor-held path, and ours can be too.
The difference is that any ibl.ai support access is a role in your directory rather than a plane above it — created by a policy you wrote, scoped to resources you chose, visible in your audit log, and revocable by you without asking us.
That is checkable in diligence, which "nobody has access" never is.
| Question an auditor asks | Managed AI SaaS | ibl.ai, self-hosted |
|---|---|---|
| Can user administration be split from policy administration? | Usually yes — several ship customer-defined custom roles (Claude Enterprise, ChatGPT Enterprise), scoped to the vendor’s own permission catalog | Yes — can_manage_users vs /policies/#list, and you can define more |
| Can we read the enforcement code? | No | Yes — MIT-licensed, in your repository |
| Who can reach the admin console outside our staff? | Provider operations, under the provider's process — sometimes approved per request (Azure Customer Lockbox), sometimes a named vendor role inside an account you own (Glean cloud-prem) | Only identities in your own directory — vendor support included, as a policy you grant and revoke |
| Where does the audit record live? | Vendor's store, vendor's retention | Your store, your retention policy |
Which frameworks does an AI admin console have to answer to?
Four documents cover most of what a reviewer will ask for, and none of them is AI-specific in the parts that bite.
| Framework | What it asks of an admin surface | The ibl.ai object that answers it |
|---|---|---|
| NIST SP 800-53 Rev. 5 AC-5, AC-6 |
Divide duties so no individual holds the whole process; grant least privilege | Per-sub-tab permissions; roles scoped by hierarchical resource path |
| NIST AI RMF 1.0 GOVERN function |
Document roles, responsibilities and accountability for AI systems | Named roles and policies as the artifact, not a spreadsheet beside it |
| NIST SP 800-207 Zero Trust Architecture |
Grant access to individual resources on a per-session basis, not once at the perimeter | A permission-check endpoint consulted per tab and per resource path |
| AICPA SOC 2 Trust Services Criteria |
Evidence that logical access is restricted and changes are recorded | The audit log, gated on its own read permission |
CISA's Zero Trust Maturity Model pushes the same identity pillar further, toward per-session authorization.
The thing worth noticing across all four is that the controls are old and the surface is new: the AI platform's own configuration screen is where the privileged actions moved, and it inherited no access model by default.
How do you map an existing org chart onto roles and policies?
Start from the duties that are already separate on paper, then express each as the narrowest role that performs it.
A workable first pass for most organizations is five grants.
A help-desk role holding can_manage_users and can_invite, and nothing else. A security role holding /roles/#list and /policies/#list, which reads the permission model and cannot administer people.
A supervisor role holding /usergroups/#list and /watchedgroups/#list, which runs teams and alerts.
An auditor role holding Ibl.Analytics/Core/read and no write actions anywhere. And a break-glass tenant admin holding Ibl.*, used rarely and covered by the alert the supervisor configured and the auditor reads.
The reason to write it as roles rather than as policy prose is that only one of the two is enforced. A governance document describing who should be able to open the Policies tab and a permission that decides who can are different artifacts, and the second one is the control.
Where this gets harder is the evidence trail across layers, because agent observability still has no standard to buy — the gen-AI semantic conventions that would let you trace a decision from orchestration through model to tool were moved out of OpenTelemetry's main repository in June 2026 and still have no tagged release.
Owning the store is how you survive that gap: the schema is yours to reshape when the standard lands.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
For U.S. government, defense and regulated buyers, that matters alongside the control model: the roles are yours, the audit store is yours, and the company you negotiate them with is answerable in your jurisdiction.
Want your access model shown as roles and policies?
Bring your org chart and we will map it onto roles, policies and groups on a live tenant, including the break-glass path and the auditor role. Book a 30-minute demo or talk to the ibl.ai team.
Sources: the eight Management sub-tabs, the seven gating permissions, the enableRbac / rbacPermissions contract, the fail-closed behaviour of the permission check, the POST /dm/api/core/rbac/permissions/check/ endpoint and the targetTab fallback are all stated in the public iblai-vibe-account skill in github.com/iblai/vibe; the role / policy / group decomposition, the Namespace/Resource/verb action syntax, data actions, the hierarchical resource paths and the seeded default roles from the iblai-vibe-rbac skill; the audit panel's Ibl.Analytics/Core/read requirement and its empty / error / 403 states from the iblai-vibe-agent-audit skill; the 12 October 2026 ship date from the v2.12.0 release tag; the per-tab behaviour, the policy-clearing on role change and the protected built-in roles from the ibl.ai docs for Users, Roles, Policies and Analytics: Audit; the application source licence from github.com/iblai/os; control families from NIST SP 800-53 Rev. 5, NIST SP 800-207, the NIST AI Risk Management Framework, the AICPA SOC suite and CISA's Zero Trust Maturity Model. The feature walkthrough with screenshots is Organization Settings, Rebuilt.
Competitor facts come from vendor documentation, cited inline: Claude Enterprise user management, Glean admin roles and cloud-prem account access, Microsoft Entra role delegation, ChatGPT Enterprise RBAC, the Azure OpenAI security baseline and AWS confidential computing.
Four claims were deliberately dropped or softened. The brief this post came from called the eighth tab "Apps"; the tab is named Applications, and it is one of the two that are not individually permission-gated. The brief also offered "AI governance your inspector general can audit" — ibl.ai ships a permission-gated audit log with actor, action and timestamp, which is what this post claims; no assertion is made about any specific agency's audit programme or certification. An earlier draft of this post claimed that almost no AI platform applies separation of duties to its own admin console, and that a managed platform therefore cannot provide it; both were wrong, and the vendor documentation above is why the concession now leads the section. The same draft said nobody outside your organization can reach a self-hosted admin console; the accurate claim, and the one a buyer can test, is that vendor support access is a role in your own directory rather than a plane above it.
Related: Shadow IT Stored Data. Shadow Agents Take Actions. — the same controls at the moment an agent is first registered. · Students as Agent Builders: How Role-Based Access (RBAC) Makes It Possible — the same model applied to agent creation rather than administration. · AI Agent Observability Has No Standard to Buy Yet — why owning the audit store matters while the tracing conventions are unreleased.