Skip to content
Product · RBAC for AI

Role-based AI permissions — from your IdP to every AI client, in one map.

PortEden's RBAC reads roles from Okta, Entra ID, and Google Workspace and turns them into default policy bundles for every AI client — Claude, ChatGPT, Copilot, Gemini, MCP servers. Engineering reads repos. Sales reads CRM. Legal reads everything but can't write. The 80% case is one map; PBAC handles the rest.

See pricing

Free tier · No credit card · Works with your existing IdP

Mapped to the frameworks your auditor reads
SOC 2 CC6.1SOC 2 CC6.3HIPAA §164.308GDPR Art. 32ISO 27001 A.5.15ISO 27001 A.5.18NIST 800-53 AC-2 / AC-6
The problem

The IdP knows the roles. The AI client doesn't.

Per-user AI permissioning collapses the moment your team grows past a few people or your AI stack grows past one client. Roles are how identity teams already think — but the AI tools have no idea who's in Sales versus Legal until somebody bridges the gap.

Per-user AI policies don't scale

Every new hire and every new AI tool means re-doing the same permission wiring. Multiply 200 employees by 6 AI clients and you have 1,200 individual policies to maintain — and one-by-one to audit.

Your IdP knows the roles; the AI client doesn't

Okta thinks Jamie is in "Sales". Claude has no idea — it inherits whatever OAuth scopes Jamie clicked through. The AI ends up with the same access as the CFO because nobody mapped Sales to a permission profile.

Reviewers can't tell who has what

Without role bundles, an access review is one-by-one against every integration and every AI client. The auditor gives up; the CISO signs off on a list nobody actually checked. CC6.3 evidence is reconstructed in a spreadsheet.

The map, in one view

One role bundle. Every integration. Every AI client.

Each row is a role from your IdP. Each column is an integration. The cell is the default scope a user in that role gets when any AI client acts on their behalf. You assign once. Every AI client inherits.

RoleGmailDriveSlackCalendarJiraNotion
Engineeringreadfull readfree/busyfull readread
Salesfull readreadreadfull read—read
Legalfull readfull readfull readfull readreadfull read
Financereadreadfree/busy—read
Executivefull readreadreadfull readreadread
full readread-onlyfree/busydenied— no access
Coverage

Twelve pre-built bundles. You assign. You don't author.

Most teams need 5–8 roles. PortEden ships 12, tuned for the regulated workflows we see most often. Pin them to your IdP groups; clone and customize the two or three that need it.

Engineering

Repos, tickets, and docs — no email, no secrets

  • GitHub / GitLab repos and PRs (read)
  • Jira / Linear tickets and sprints (full)
  • Notion / Confluence engineering spaces (read)
  • Slack engineering and on-call channels (full)
  • Mail and HR systems blocked at the integration boundary
  • Secrets-management consoles hard-denied
  • Calendar limited to free/busy

Sales

CRM + customer mail, pipeline-only calendar

  • Salesforce / HubSpot accounts and opportunities (full)
  • Customer email threads in Gmail / Outlook (read)
  • Calendar restricted to pipeline-tagged events (full)
  • Slack customer-facing channels (read)
  • HR data and people-ops systems hard-denied
  • Internal-only tagged threads excluded by contact rules
  • Send-on-behalf requires a user click

Legal

Read everything, write nothing, privilege-tag enforced

  • Mail, drive, chat across the org (full read)
  • Privileged-tag enforcement on attorney-client items
  • Hard-deny on send, reply, edit, delete actions
  • Matter-aware time windows on active matters
  • Opposing-counsel domains blocked by contact rules
  • Audit-trail export for matter retention obligations
  • PBAC overlay for litigation-hold matters

Finance

Financial systems, exec free/busy, PII redacted

  • ERP and GL systems (read; close-period overlay)
  • Executive calendars at free/busy only
  • Customer financial threads (read; PII redacted)
  • Drive folders tagged finance-confidential (read)
  • HR, engineering, and customer-success systems blocked
  • PII auto-redacted from all responses
  • Quiet-period PBAC overlay before earnings

HR

People data; firewall against engineering

  • HRIS (Workday, BambooHR, Rippling) — read
  • Employee mail and calendar at free/busy only
  • Slack #people and HR-private channels (full)
  • Compensation data behind PBAC overlay
  • Engineering, finance, and customer systems blocked
  • PII reversibly tokenized in AI responses
  • Hard-deny on send-on-behalf to non-HR addresses

Executive

Broad read; AI write requires human approval

  • Mail, drive, chat, calendar across the org (read)
  • Board materials and M&A folders behind PBAC overlay
  • AI write actions (send, edit, share) require approval
  • Privileged legal items still respect attorney-client
  • Per-AI-client policy: stricter scopes for general-purpose chat
  • Audit-trail export ready for board and audit committee
  • Quarterly access review pre-built for the board CSV
How it works

Map. Bundle. Inherit. Review.

1. Map

Connect your IdP — Okta, Entra ID, Google Workspace — over SAML or OIDC and map IdP groups to PortEden roles. The 12 pre-built bundles cover the common patterns; clone and edit if you need a Legal-Privileged or a Finance-Auditor variant.

2. Bundle

Assign a default policy bundle to each role. Engineering reads repos, tickets, docs. Sales reads CRM and customer email. Legal reads everything but cannot write. The bundle defines visibility, contact rules, action limits, time windows, account scope, and data reduction.

3. Inherit

Policies cascade — org → role → team → user — with explicit overrides at each level. A Sales rep on the M&A working group inherits Sales scopes plus the M&A confidentiality overlay. The resolved effective policy is visible in the admin console and the audit trail.

4. Review

Export role membership, bundle definitions, and per-request enforcement logs for periodic access review. Hand the CSV to your auditor; sign-off becomes a one-page review instead of a per-user spreadsheet. Quarterly reviews drop from days to hours.

See it in action

A user logs in. The bundle resolves automatically.

Here's the resolution PortEden runs the moment a user opens any AI client. IdP groups in. Resolved role and policy outcome out. Every layer is decided before the first prompt.

Role assignment · resolved
Live
From your IdP
UserJamie Rivera
Emailjamie@yourcompany.com
IdPOkta
IdP groups
Sales-AMERPipeline-LeadsAll-Employees
PortEden role
Sales (default bundle)
Resolved policy outcome
Visibility profile
CRM full · customer mail read · pipeline calendar full
Contact rules
Internal-only tagged threads excluded · @competitor.com blocked
Action limits
Read · draft · send-on-behalf with user click · no delete
Time window
Last 90 days of mail · this quarter on calendar · CRM all-time
Account scope
Work mailbox · Sales-AMER drives · #cs-amer Slack workspace
Data reduction
PII tokenized in AI responses · revenue figures kept exact
Resolution is recomputed on every request. A change to the IdP group, the bundle definition, or a PBAC overlay applies on the next prompt with the full reasoning recorded in the audit trail.
With and without RBAC

Same workflow, two very different operational costs.

Onboarding a new sales hire
Without
IT files a ticket per AI tool, per integration. Day 1 the new rep has Claude with no scopes; day 9 they finally have CRM read; day 14 someone overgrants and the rep has access to leadership Slack.
With
Add to the Sales group in Okta. PortEden inherits the Sales bundle automatically. Day 1 the rep has CRM, customer mail, and pipeline calendar — and nothing else.
Reassigning someone from sales to legal
Without
Old AI scopes linger because nobody remembers which tools to revoke. The transferred employee has Sales-tier mail access for 90 days while Legal-tier scopes get layered on top.
With
Move them from the Sales group to the Legal group in your IdP. PortEden swaps bundles within 60 seconds. Old Sales scopes drop; Legal scopes apply on the next prompt.
Quarterly access review for SOC 2 CC6.3
Without
Spreadsheet of every user × every integration × every AI client. Review takes a week; auditor finds gaps; sign-off is theatrical.
With
Export role membership and bundle scopes to CSV. One-page review with the bundle definition attached. Sign-off in an afternoon, evidence the auditor accepts.
Adding a new AI client to the stack
Without
Re-create per-user policies for every employee in the new client. Multi-week project; partial coverage on day one; risk of drift between clients.
With
Connect the new client. Existing role bundles apply automatically — Engineering, Sales, Legal, Finance all keep the same scopes they had on the previous AI tools.
Deprovisioning a contractor when their engagement ends
Without
Manual audit of every AI tool the contractor was given. Tokens linger; access reviews surface them weeks later. The contractor reads the source code on the way out.
With
Deactivate them in your IdP. PortEden revokes the Contractor bundle within 60 seconds across every AI client. The next prompt returns a hard-deny.
Auditor asks: who can read finance data through AI?
Without
Nobody knows. You build a query against OAuth grants, cross-reference HR, and produce a list with footnotes nobody trusts.
With
Export the Finance and Executive bundle membership. The list is exact, dated, and signed. The auditor checks the bundle scopes once and accepts the membership list as evidence.
Auditor-readable

Citations, not vague reassurances.

Role bundles map directly to the access-control clauses your auditor reads. Evidence — bundle definitions, membership exports, change logs — is exportable from the audit trail.

Framework
Citation
PortEden control
SOC 2
CC6.1 — Logical access
Logical access security software, infrastructure, and architectures restrict access to authorized users. Role bundles enforced at the integration boundary with per-request evidence.
SOC 2
CC6.3 — Authorization
Access is authorized based on roles and responsibilities, with periodic review. Versioned role bundles, signed membership exports, and CC6.3 evidence template included.
HIPAA
§164.308(a)(3) Workforce security
Role-based provisioning, supervision, and termination procedures for workforce members handling ePHI. PortEden role bundles + IdP-driven deprovisioning.
HIPAA
§164.308(a)(4) Information access management
Authorization, establishment, and modification of access to ePHI. Bundle definitions and access modifications produce signed audit events for the access management policy.
GDPR
Art. 32 — Security of processing
Technical and organizational measures to ensure least-privilege access. Roles enforce least privilege before personal data reaches an AI processor.
ISO 27001
A.5.15 — Access control
Access control policy mapped to PortEden roles and bundles. Documented, versioned, and reviewed on a defined cadence.
ISO 27001
A.5.18 — Access rights
Provision, review, and remove access rights through the IdP-to-bundle pipeline. Every membership change is a signed audit event.
NIST 800-53
AC-2 + AC-6
Account management and least privilege. Role bundles enforce AC-6 by default; AC-2 evidence is the IdP-to-bundle membership history with signed change events.
Where role bundles apply

Your IdP roles, enforced at every integration.

Connect your IdP first; then every integration the bundle touches inherits the right scopes for every AI client. New integrations and new AI tools land inside the role bundle automatically.

Entra ID
Entra ID
Gmail
Gmail
Outlook
Outlook
Google Calendar
Google Calendar
Google Drive
Google Drive
Slack
Slack
Microsoft Teams
Microsoft Teams
Jira
Jira
Confluence
Confluence
Notion
Notion
Asana
Asana
Linear
Linear
See all integrations
Use cases

Six industries, six role-bundle layouts.

Architecture

One source of truth, one bundle, two engines.

PortEden's RBAC is opinionated about three things: identity belongs in your IdP, bundles beat custom rules, and roles compose with attributes. Get those three right and the rest of access management becomes a one-page review.

IdP is the source of truth

Don't manage identity twice. PortEden reads from Okta, Entra ID, or Google Workspace and stays in sync via SCIM. Deprovisioning happens upstream — remove the user from the IdP and every AI client loses access on the next prompt.

Bundles, not custom rules

Most teams need 5–8 roles; PortEden ships 12. You assign bundles to IdP groups; you don't author per-user policies. A custom bundle is one fork from a default — versioned, change-controlled, and audit-logged the same way.

RBAC + PBAC compose

RBAC handles 80% of policy with role bundles. PBAC handles the attribute-level edge cases — quiet periods, location overlays, resource-tag conditions. Same engine, same audit log, same compliance evidence path.

Available in: Pro, Business, Enterprise tiers · See pricing

Pairs well with

RBAC for AI questions

What is RBAC and how does it apply to AI?
Role-based access control assigns permissions to roles, not individuals. RBAC for AI extends that idea to every AI client — Claude, ChatGPT, Copilot, Gemini, MCP servers — so the access an assistant gets is determined by the role of the person it's acting on behalf of, not by whatever OAuth scopes the user happened to grant. PortEden ships pre-built role bundles for Engineering, Sales, Legal, Finance, HR, and Executives. Map your IdP groups to those bundles once, and every AI tool, present and future, inherits the right scopes the moment a user logs in.
How is this different from OAuth scopes or my IdP's RBAC?
OAuth scopes apply to a single connection — "read calendar" or "read drive" — and they're identical for every user who installs the app. Your IdP's RBAC controls who can log into what application, not what an AI agent does once it's authenticated. PortEden's RBAC sits in the middle: it reads role membership from your IdP and translates it into per-prompt, per-resource enforcement at the integration boundary. You keep one source of truth for identity. PortEden adds the missing layer between authentication and execution that decides what an AI client can actually see and do.
Which IdPs are supported?
Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, JumpCloud, OneLogin, and Ping Identity via SAML 2.0 and OIDC. SCIM 2.0 is supported for user and group provisioning, so role membership stays in sync automatically. Custom directories work via the management API. The Enterprise tier ships a SCIM connector with bidirectional sync, group filtering, and just-in-time user provisioning so a new hire's first AI session is already scoped to their role.
Can I customize the pre-built role bundles?
Yes. The 12 bundles PortEden ships — Engineering, SRE, Sales, Customer Success, Marketing, Legal, Finance, HR, Executive, Contractor, Auditor, Support — are starting points. You can clone any bundle, edit its scopes, rename it, and pin it to specific IdP groups. You can also author entirely new bundles. Bundle changes are versioned, change-controlled, and audit-logged like any other policy edit. Most teams ship with the defaults and customize Legal and Finance based on their internal information barriers; the others rarely need changes.
Does RBAC compose with PBAC?
Yes — they share the same engine and the same audit log. RBAC handles the 80% case: assign a role bundle to each IdP group and let it cascade. PBAC handles the edge cases: "deny if requester role is contractor AND resource label is confidential AND time is outside business hours." In practice, RBAC sets the baseline (what a Sales rep can normally do) and PBAC overrides for specific contexts (extra restrictions during a quiet period before earnings, for example). Most organizations land at 5–8 roles and 10–20 PBAC overrides — far less to maintain than per-user policies.
How are deprovisioning and offboarding handled?
Deprovisioning happens upstream in your IdP. The moment a user is removed from a group or deactivated, PortEden picks up the change via SCIM (typically under 60 seconds) and revokes the corresponding role bundle. Active AI sessions are terminated; new prompts return a hard-deny with the policy that fired. There's no parallel directory to keep in sync. Offboarding a contractor or a departing employee is the same single action it always was — remove them from the IdP — and every AI client they were using loses access at the same moment.
Can a user be in multiple roles?
Yes. PortEden resolves multi-role membership by union for permissive scopes and by intersection for hard-deny rules. A Sales rep who's also on a confidential M&A working group will get the union of their CRM scopes, but the intersection of their hard-denies — meaning the most restrictive deny wins. You can also pin a precedence order at the role level if union/intersection isn't what you want for a particular pair of bundles. The resolved effective policy for any user is visible in the admin console, with the contributing bundles listed.
How do role changes propagate — instant or batched?
Membership changes from your IdP are applied within 60 seconds via SCIM streaming. Bundle definition changes (you edit the Legal role's scopes, for example) propagate within 30 seconds and apply to the next request from any session. Active long-running sessions can be configured to either honor the new policy mid-session or finish on the policy that was live when they started — the Enterprise tier defaults to the latter, so audit reasoning stays consistent. Every propagation is logged with the affected users, the old bundle hash, and the new one.
What if my org structure is matrixed (people in 2 teams)?
Matrix structures are first-class. A user can hold multiple role bundles simultaneously — for example, a person who's both on Engineering and embedded with the Finance team for a transformation project gets both bundles, with conflicts resolved by the union/intersection rules above. You can also model project-based roles that expire on a date, so the temporary Finance access drops automatically when the project ends. The audit trail records every role membership change with the source IdP group, the effective dates, and the policy outcome at every point in time.
What evidence does this produce for SOC 2 CC6.3 auditors?
CC6.3 covers authorization of access based on roles and responsibilities, with periodic review. PortEden's RBAC produces direct evidence: role bundles are documented with their scopes, IdP-to-bundle mappings are versioned, and every role membership change is logged with who made it, when, and why. Access reviews export role membership and current bundle scopes to CSV for sign-off. Auditors typically accept the export plus the bundle definition plus a sample of audit-trail entries showing enforcement at request time. We also publish a CC6.3 evidence template you can hand to your auditor on day one. Compliance with SOC 2 remains your responsibility — PortEden provides the technical control, you operate the program around it.
Are role-membership changes themselves audited?
Yes — every change is an audit event. Adding a user to an IdP group, removing them, changing a bundle's scopes, creating a new bundle, deleting one, pinning a bundle to a group: each generates a signed log entry with actor, timestamp, before/after diff, and the request ID that triggered it. SCIM-driven changes record the upstream IdP event ID for traceability. Logs export to SIEM (Splunk, Datadog, Elastic) and to a signed CSV for evidence collection. You can replay the role membership of any user at any point in time and see exactly which bundles applied.
What pricing tier includes RBAC?
Core RBAC with the 12 pre-built bundles and IdP integration is included on the Pro tier. Custom bundle authoring, SCIM provisioning, multi-role union/intersection rules, and matrix-org modeling are on Business. Change-control workflows on bundle edits, SSO/SAML, SCIM, SIEM export of role events, and per-AI-client role overrides are on the Enterprise tier. See pricing for the full breakdown by tier.

Ready to map your IdP to every AI client in one step?

Connect your IdP, assign default bundles to your roles, and every AI tool inherits the right scopes the moment a user logs in. Free tier covers solo users; Enterprise adds SSO/SAML, SCIM, change-control workflows, and SIEM export.

Talk to sales