--- title: "AI Admin Separation of Duties: Who Sees the Policies Tab" slug: "ai-admin-separation-of-duties-policies-tab" author: "ibl.ai Engineering" date: "2026-10-17 09:00:00" category: "Premium" topics: "separation of duties, RBAC, AI governance, least privilege, NIST SP 800-53, AC-5, AI admin console, audit log, self-hosted AI, role-based access control" summary: "ibl.ai's organization settings split Management into eight sub-tabs and gate six of them behind their own permission, which means user administration and policy administration are separate grants. This post gives the shipped permission names, maps them onto NIST SP 800-53's AC-5 separation-of-duties and AC-6 least-privilege controls, credits the in-tenant admin RBAC the managed platforms do ship, and shows where it stops: you audit the provider plane through someone else's attestation rather than by reading the enforcement code and the audit log yourself." banner: "" thumbnail: "" linkedin: | Separation of duties is the oldest control in the book. Most AI platforms now split their admin console somehow — what almost none of them let you do is read the code that enforces the split. Give the managed vendors their due first. Claude Enterprise ships a membership_admin role distinct from owner, plus a read-only read:org_audit scope for security-audit integrations. Glean's Admin role cannot assign Super Admin. Microsoft splits user administration from role administration. In-tenant separation of duties is real and it is shipping. The question is where it stops. ibl.ai's organization settings now split Management into eight sub-tabs — Users, Groups, Roles, Policies, Teams, Alerts, Applications and Onboarding — and six of them are gated by their own permission: can_manage_users, can_invite, and list permissions on groups, roles, policies, user groups and watched groups. The consequence is the point. A help-desk administrator holding can_manage_users can invite, deactivate and reassign people, and still cannot open Roles or Policies, because /roles/#list and /policies/#list are different grants. Reading the audit log is a third grant again: without Ibl.Analytics/Core/read the panel renders a 403 state rather than quietly showing nothing. NIST SP 800-53 has had AC-5 Separation of Duties and AC-6 Least Privilege in its Access Control family for years. The novelty is not the control. It is that the control now applies to the AI platform's own configuration surface, where the high-value actions actually live. It stops at the tenant boundary. Your RBAC governs your users; the provider plane above it is governed by the provider's own process — sometimes with a customer approval prompt like Azure Customer Lockbox, sometimes with a named vendor role inside an account you own, as in Glean's cloud-prem model. Either way you audit it through someone else's attestation rather than by reading the code and the log yourself. At ibl.ai you own all the code and the data. The enforcement code is in your repository, the audit store is in your perimeter, and the set of identities that can reach the admin console is one you enumerate, grant and revoke — including any ibl.ai support access, which is a role in your directory, not a plane above it. #iblai #AgenticAI #EnterpriseAI #RBAC #AIGovernance #SeparationOfDuties --- ## 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](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), 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](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), 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](/blog/agent-governance-new-shadow-it-day-one-controls): 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](https://github.com/iblai/vibe/blob/main/skills/organizations/iblai-vibe-account/SKILL.md) in [github.com/iblai/vibe](https://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](https://github.com/iblai/vibe/releases/tag/v2.12.0) 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](/docs/os/organization-settings/users), [Groups](/docs/os/organization-settings/groups), [Roles](/docs/os/organization-settings/roles), [Policies](/docs/os/organization-settings/policies), [Teams](/docs/os/organization-settings/teams) and [Alerts](/docs/os/organization-settings/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](/blog/students-as-agent-builders-how-role-based-access-rbac-makes-it-possible). 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](https://github.com/iblai/vibe/blob/main/skills/users/iblai-vibe-rbac/SKILL.md). 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](https://github.com/iblai/vibe/blob/main/skills/agents/iblai-vibe-agent-audit/SKILL.md) 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](/docs/os/analytics/audit) and [Agent Settings: Audit](/docs/os/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](https://github.com/iblai/vibe/blob/main/skills/organizations/iblai-vibe-account/SKILL.md) 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](https://github.com/iblai/os) carries the application under the MIT licence; [github.com/iblai/vibe](https://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](https://platform.claude.com/docs/en/manage-claude/user-management) 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](https://docs.glean.com/administration/identity/roles/admin-roles) states that its Admin role cannot assign Super Admin. [Microsoft Entra](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/delegate-by-task), which Copilot inherits, assigns user administration to User Administrator while role assignment and role settings require Privileged Role Administrator. [ChatGPT Enterprise](https://help.openai.com/en/articles/11750701-managing-feature-access-with-role-based-access-control-in-chatgpt) 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](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-openai-security-baseline) 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](https://aws.amazon.com/confidential-computing/). [Glean's cloud-prem model](https://docs.glean.com/security/cloud-prem/aws/account-access-and-deployment-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](https://www.cisa.gov/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](/blog/agent-observability-fragmenting-stack-own-the-audit-trail) — 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](https://cal.com/iblai/30min) or [talk to the ibl.ai team](/contact). --- *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](https://github.com/iblai/vibe/blob/main/skills/organizations/iblai-vibe-account/SKILL.md) in [github.com/iblai/vibe](https://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](https://github.com/iblai/vibe/blob/main/skills/users/iblai-vibe-rbac/SKILL.md); the audit panel's `Ibl.Analytics/Core/read` requirement and its empty / error / 403 states from the [`iblai-vibe-agent-audit` skill](https://github.com/iblai/vibe/blob/main/skills/agents/iblai-vibe-agent-audit/SKILL.md); the 12 October 2026 ship date from the [v2.12.0 release tag](https://github.com/iblai/vibe/releases/tag/v2.12.0); the per-tab behaviour, the policy-clearing on role change and the protected built-in roles from the ibl.ai docs for [Users](/docs/os/organization-settings/users), [Roles](/docs/os/organization-settings/roles), [Policies](/docs/os/organization-settings/policies) and [Analytics: Audit](/docs/os/analytics/audit); the application source licence from [github.com/iblai/os](https://github.com/iblai/os); control families from [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final), the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), the [AICPA SOC suite](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services) and [CISA's Zero Trust Maturity Model](https://www.cisa.gov/zero-trust-maturity-model). The feature walkthrough with screenshots is [Organization Settings, Rebuilt](/updates/organization-management-roles-policies-groups-alerts).* *Competitor facts come from vendor documentation, cited inline: [Claude Enterprise user management](https://platform.claude.com/docs/en/manage-claude/user-management), [Glean admin roles](https://docs.glean.com/administration/identity/roles/admin-roles) and [cloud-prem account access](https://docs.glean.com/security/cloud-prem/aws/account-access-and-deployment-model), [Microsoft Entra role delegation](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/delegate-by-task), [ChatGPT Enterprise RBAC](https://help.openai.com/en/articles/11750701-managing-feature-access-with-role-based-access-control-in-chatgpt), [the Azure OpenAI security baseline](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-openai-security-baseline) and [AWS confidential computing](https://aws.amazon.com/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.](/blog/agent-governance-new-shadow-it-day-one-controls) — the same controls at the moment an agent is first registered. · [Students as Agent Builders: How Role-Based Access (RBAC) Makes It Possible](/blog/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](/blog/agent-observability-fragmenting-stack-own-the-audit-trail) — why owning the audit store matters while the tracing conventions are unreleased.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 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.