> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms.md). # 1.2 RBAC across AI platforms How each vendor exposes roles and permissions, and how to design access models that grant the right capabilities without over-granting. *Last reviewed: August 18, 2026* {% hint style="info" %} AI RBAC should control capabilities as well as admin pages. A useful role design decides who can use agents, connectors, web access, skills, code execution, publishing, and audit exports. {% endhint %} **Primer** Traditional SaaS RBAC often starts with admin, editor, and viewer. AI platforms need a finer model because many end-user features carry security meaning. A user who can run a coding agent, install a connector, publish a skill, browse the web, or enable code execution can change the risk profile of a workspace without touching an admin page. Good AI RBAC starts with job function, but it is tested against capability. Ask what the user can cause the tool to do. Can it read files, write to a connected system, send messages, run code, access the internet, remember information, publish assets to other users, or create reusable instructions? Those are the permissions that matter. Group-based assignment is the safer pattern. Users enter groups through the identity provider, groups receive roles in the AI platform, and exceptions expire. This gives security teams a reviewable access map and keeps user moves from turning into quiet privilege drift. **Common failure modes** * Admin roles are separated, but high-risk end-user capabilities are enabled for everyone. * Multiple group roles are additive, and one broad group silently grants a capability the security team meant to restrict. * Workspace defaults remain permissive after custom roles are created. * Connector access is controlled in the AI platform, but the connected SaaS app still grants broad read or write permissions. * Role names describe departments rather than permitted actions. * A role grants identity administration to people who can also edit their own role or group path. **Controls checklist** * Build roles from capabilities first, then map them to departments. * Separate workspace administration from high-risk end-user actions. * Review additive-permission behavior before assigning multiple roles to the same group. * Keep default roles narrow, then grant higher-risk capabilities by group. * Split roles for chat, web access, coding agents, connector use, connector write actions, skill or plugin publishing, API administration, and audit access. * Require separate approval for roles that can change identity settings, groups, provisioning, domains, or role definitions. * Test a pilot user after every role change. The UI should match the intended effective access. * Review effective permissions quarterly, and after major vendor feature releases. **Anthropic** **Overview** Anthropic documents two relevant RBAC areas. Claude Console has roles such as User, Claude Code User, Limited Developer, Developer, Billing, and Admin. These govern Console and API-oriented administration, including API keys, billing, usage, and workspace-level permissions. Claude Enterprise custom roles cover product capabilities such as chat, code execution, memory, web search, public projects, skills, Claude Code, Cowork, Claude for Chrome, connectors, models, and admin areas. Anthropic states that custom roles are assigned to groups and that permissions are additive across roles. If any assigned role grants a capability, the member has it. The practical control is to avoid using one broad baseline role for everyone. Keep the baseline small, then create purpose-built roles for developers, connector users, skill authors, auditors, and admins. **Anthropic documentation** * [Claude Console roles and permissions](https://support.claude.com/en/articles/10186004-claude-console-roles-and-permissions) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) **OpenAI** **Overview** OpenAI separates workspace roles from product and runtime access. Built-in workspace roles include Owner, Admin, Member, and Analytics Viewer, while access to ChatGPT, Work, Codex developer tools, Codex cloud, and the Platform API is governed through additional workspace, group, runtime, and organization controls. Review role and capability assignments together; neither one proves that every execution path is governed. OpenAI's custom roles control end-user capabilities, while managed Codex requirements constrain security-sensitive local behavior across supported desktop, CLI, and IDE surfaces. Codex cloud eligibility and Platform API organization access remain separate boundaries. Users can inherit multiple custom roles through groups, so review effective access rather than one role assignment in isolation. For OpenAI, review three things together: seat type, workspace role, and custom-role permissions. A narrow custom role will not help if a broader seat or default workspace setting still grants access. **OpenAI documentation** * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) **Applicable Harmonic guides for OpenAI** * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) **Practitioner FAQs** **Who should own AI RBAC?** Identity teams should own the group lifecycle. Product or platform owners should own feature intent. Security should own the control standard and review exceptions. No single team sees the whole picture alone. **Should admins also be power users?** Keep the roles separate where the platform allows it. Admins need configuration authority. Power users need product capabilities. Combining both makes audits harder and gives one compromised account a wider blast radius. **How often should AI roles be reviewed?** Review high-risk roles at least quarterly. Review identity administration, connector write access, skill publishing, API key administration, and agent automation access after every material vendor release. **What AI permissions should never be granted by default?** Keep connector write actions, code execution, skill publishing, API key administration, broad agent access, and identity administration out of default roles. Grant them through reviewed groups. **Why do additive AI roles create risk?** Additive roles make the broadest grant win. A user in several groups may receive a capability from a role that no one thinks of as their primary access path. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [1. Identity & Access](/handbook/1.-identity-and-access.md) * [1.1 SSO & SCIM for AI platforms](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms.md) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.