Role-Based Access Control (RBAC)

SailPoint Entro's RBAC feature provides granular control over user permissions, ensuring only authorized users can take actions and view relevant information across the platform.

Each user may be assigned one or more roles. When multiple roles are assigned, the user's effective permissions are the union of the capabilities of all assigned roles. Access restrictions are enforced both in the UI (hiding navigation items, buttons, and pages) and at the API layer, every endpoint re-checks the user's role server-side, and unauthorized actions return 403 Forbidden.

Roles at a Glance

SailPoint Entro defines six roles, five primary roles and one specialized integration role:

Role	Intended Persona	Scope
Admin	Security leads, platform owners	Full access to every feature, setting, and admin operation.
Operator	SOC analysts, security engineers handling day-to-day ops	View and act on secrets, risks, NHIs, and notifications, no settings.
Viewer	Auditors, executives, read-only stakeholders	Read-only access to all operational data, plus exports and comments.
Engineer	DevOps and application engineers responsible for remediation	Secrets, risks, NHIs and API-key self-service, seeing only items related to them.
API Key Manager	Automation owners who only need to provision keys	Create and delete REST API keys; minimal visibility elsewhere.
Integrator	Users onboarding cloud accounts and SaaS integrations	Add, edit, validate, and tag accounts, no secrets, NHIs or risk data.

Most users will have a single role. When multiple roles are assigned, effective permissions are the union of every role held.

Role Hierarchy

Admin, Operator, Viewer, Engineer, and API Key Manager form a partial hierarchy, stronger roles implicitly include the privileges of weaker ones for relative-strength checks (used for "who can act on behalf of whom" logic):

Admin
  └── Operator
        ├── Viewer
        │     └── API Key Manager
        └── Engineer
              ├── API Key Manager
              └── Integrator

Admin is the apex role and is stronger than every other role.
Operator is stronger than Viewer, Engineer, and API Key Manager.
Viewer is stronger than API Key Manager.
Engineer is stronger than API Key Manager and Integrator.
Integrator sits outside the main chain and is intended to complement another role rather than stand alone.
API Key Manager sits at the bottom of the chain.

The hierarchy governs relative strength only. The actual set of actions each role can perform is defined explicitly per role in the sections below, a role does not automatically inherit every action from the role beneath it.

Roles Defined

1. ADMIN

Persona: Security leadership, platform administrators, tenant owners.

Default landing page: Main Dashboard.

Admins have full, unrestricted access to the application. Admin is the only role that can change platform settings, manage organization policies, run operational tooling, and govern NHI owner attestation campaigns and zero trust policies.

Permissions:

All capabilities available to Operator, Viewer, Engineer, API Key Manager, and Integrator, plus the admin-exclusive capabilities listed below.
Full access to every Settings section: Alert Configuration, Risk Configuration, Organization Configuration, Webhooks, Exposed Secrets, Beta Features, Scanned Repositories Rules, Exclusion Rules, DLP Custom Patterns, User Management, Secret Type Control.
Manage customer configuration, organization policies, and group-to-role mapping.
Full access to the Employee Audit and Employee Management pages.
View, create, and manage NHI Owner Attestation Campaigns, including approving, disabling, and rotating campaign tokens and changing campaign owners.
Create, update, and delete Zero Trust Policies.
Manage AI Governance policy.
Operational tooling: create remote agents, trigger scans, generate QBR reports, accept EULA on behalf of the tenant, apply data migrations, retrieve overview stats, invoke troubleshooting APIs, and access Storybook.

Exclusions:

None.

2. OPERATOR

Persona: SOC analysts and security engineers running day-to-day secret and risk operations.

Default landing page: Main Dashboard.

Operators have broad view and action access across all operational surfaces. They can investigate, triage, remediate, and communicate with stakeholders, but cannot change platform settings, manage accounts, or perform admin-only operations.

Permissions:

Views: All Exposed Secrets (table, drawer, export), Risks (table, drawer, dashboard, comments, export), Non-Human Identities (table, drawer, dashboard, export), NHIDR Risks (table, drawer), Vault Secrets (table, drawer, dashboard, export), AI Agents (table, dashboard), Agentic AI NHI table, AI MCP table, Accounts (table, drawer), Employees (table, drawer, export), Main Dashboard, Zero Trust Policies.
Triage actions: Mark exposed secrets and exposed risks as "not a secret"; revalidate exposed secrets and exposed risks; revoke NHI tokens; change risk status and severity; archive risks.
Tagging and comments: Add and remove employee tags and exposed-secret tags; add comments to risks.
Remediation and communication: Create Jira tickets; send Slack, Teams, and email notifications; redact Slack messages.
Update zero trust state on entities.

Exclusions:

No access to any Settings page (including API Keys).
Cannot add, edit, validate, or enable/disable accounts.
Cannot manage organization policies or customer configuration.
Cannot create API keys.
Cannot manage NHI owner attestation campaigns.
Cannot create, update, or delete zero trust policies.
No access to admin-only operational tooling (remote agents, scans, QBR reports, troubleshooting, migrations).
No access to the Employee Audit or Employee Management pages.

3. VIEWER

Persona: Auditors, compliance stakeholders, executives, or any read-only consumer of platform data.

Default landing page: Main Dashboard.

Viewers have full visibility into operational data with the ability to export reports and add comments on risks, but cannot change the state of anything.

Permissions:

Views: The same surface as Operator, All Exposed Secrets, Exposed Risks, NHI Inventory, NHIDR Risks, Vault Secrets, AI Agents, Accounts, Employees (table and drawer), Main Dashboard, Zero Trust Policies.
Exports: All Exposed Secrets, NHIs, Vaults, Employees, Risks.
Add comments to risks.

Exclusions:

Any state-changing action: cannot mark as "not a secret," revalidate, revoke tokens, change risk status or severity, archive, or tag.
Cannot send notifications (Slack, Teams, email) or create Jira tickets.
Cannot manage accounts, employees, campaigns, zero trust policies, or AI policy.
No access to any Settings page.
Cannot update zero trust state on entities.

4. ENGINEER

Persona: DevOps and application engineers responsible for triaging and fixing exposed secrets and NHIs for risks in their own services, and for provisioning their own automation API keys.

Default landing page: Exposed Inventory - Engineers skip the Main Dashboard and land directly on the remediation work queue.

Engineer is a technical remediation role with a narrower lens than Operator. Engineers can work on secrets, NHIs, risks, and API keys, but do not have visibility into employees, vaults, or AI agents.

Permissions:

Views: All Exposed Secrets (table, drawer, export), Exposed Risks (table, drawer), NHI Inventory, NHIDR Risks, All Risks (drawer, dashboard, comments, export), Accounts (table only, no drawer), the Settings sidebar button and the Settings → API Keys tab.
Triage actions: Mark exposed secrets and exposed risks as "not a secret"; revalidate exposed secrets and exposed risks; revoke NHI tokens; change risk status and severity; archive risks.
Tagging and comments: Add comments to risks; add and remove exposed-secret tags.
Remediation and communication: Create Jira tickets; send Slack, Teams, and email notifications; redact Slack messages.
API Keys: Create and delete REST API keys.
Update zero trust state on entities.

Exclusions:

Cannot view Employees, Vault Secrets, or AI Agents.
Cannot add, edit, validate, or manage accounts (view-only, table, no drawer).
No access to any Settings section other than API Keys.
Cannot view or manage NHI owner attestation campaigns.
Cannot create, update, or delete zero trust policies.
Cannot manage AI policy, customer configuration, or organization policy.
No access to admin operational tooling.

5. API KEY MANAGER

Persona: Owners of automation or CI/CD pipelines whose only need is provisioning and rotating REST API keys - typically assigned in tightly-scoped, least-privilege environments.

Default landing page: Settings → API Keys. The role lands directly on the one page it can use.

API Key Manager is the most restricted primary role. It exists so that an individual or service identity can manage keys without being granted access to operational data. The narrow scope makes it safe to assign to service accounts or individuals who only need key-lifecycle access.

Permissions:

Views: The Settings sidebar button and the Settings → API Keys tab, the Exposed Secrets table (list only).
Actions: Create and delete REST API keys.

Exclusions:

Everything else. No ability to export data, modify secrets, change risk status, send notifications, or view Employees, NHI, Vaults, Accounts, Dashboards, or any Settings section other than API Keys.

6. INTEGRATOR

Persona: Users responsible for onboarding and maintaining cloud-account and SaaS integrations, without a need to see findings data.

Default landing page: Accounts & Integration page.

Integrator is a specialized role scoped to the Accounts surface. It is intended for users whose job is to connect and maintain integrations but who should not have access to the secrets, risks, or employee data those integrations produce. Integrator is commonly assigned alongside another role when a user needs integration responsibilities in addition to another scope.

Permissions:

Views: Accounts (table and drawer).
Actions: Add new accounts; edit account credentials; edit account environment configuration; enable or disable accounts; validate accounts; add and remove account tags.

Exclusions:

Cannot view or act on secrets, exposed secrets, exposed risks, risks, NHIs, NHIDR, vault secrets, or employees.
No access to any Settings page.
Cannot send notifications, create tickets, or manage API keys.
Cannot manage zero trust policies, AI policy, or NHI campaigns.
No access to admin-only operations.

Capability Matrix

Legend: ✅ allowed · ⬜ not allowed

Capability	Admin	Operator	Viewer	Engineer	API Key Manager	Integrator
Secrets
View Exposed Secrets table	✅	✅	✅	✅ (related to the user)	✅	⬜
View Exposed Secrets drawer	✅	✅	✅	✅	⬜	⬜
View Exposed Secrets dashboard	✅	✅	✅	⬜	⬜	⬜
Export Exposed Secrets	✅	✅	✅	✅	⬜	⬜
Mark exposed secret as "not a secret"	✅	✅	⬜	✅	⬜	⬜
Revalidate exposed secret	✅	✅	⬜	✅	⬜	⬜
Add / remove exposed-secret tags	✅	✅	⬜	✅	⬜	⬜
View Prevention Logs	✅	✅	✅	✅	✅	⬜
Risks
View Risks table	✅	✅	✅	✅ (related to the user)	⬜	⬜
View Risks drawer / dashboard / comments	✅	✅	✅	✅	⬜	⬜
Export Risks	✅	✅	✅	✅	⬜	⬜
Change risk status / severity	✅	✅	⬜	✅	⬜	⬜
Archive risks	✅	✅	⬜	✅	⬜	⬜
Add comments to risks	✅	✅	✅	✅	⬜	⬜
View Exposed Risks (table, drawer)	✅	✅	✅	✅	⬜	⬜
View Exposed Risks dashboard	✅	✅	✅	⬜	⬜	⬜
Mark exposed risk as "not a secret"	✅	✅	⬜	✅	⬜	⬜
Revalidate exposed risk	✅	✅	⬜	✅	⬜	⬜
NHI / AI
View NHI / NHIDR / Vault	✅	✅	✅	✅ (related to the user)	⬜	⬜
Export NHI / Vault	✅	✅	✅	✅	⬜	⬜
Revoke NHI tokens	✅	✅	⬜	✅	⬜	⬜
View AI Agents / Agentic NHI	✅	✅	✅	⬜	⬜	⬜
View AI MCP table	✅	✅	✅	⬜	⬜	⬜
Manage AI Policy	✅	⬜	⬜	⬜	⬜	⬜
Accounts
View Accounts table	✅	✅	✅	⬜	⬜	✅
View Accounts drawer	✅	✅	✅	⬜	⬜	✅
Add / edit / validate / enable / tag accounts	✅	⬜	⬜	⬜	⬜	✅
Employees
View Employees table / drawer	✅	✅	✅	⬜	⬜	⬜
Export Employees	✅	✅	✅	⬜	⬜	⬜
Add / remove employee tags	✅	✅	⬜	⬜	⬜	⬜
Employee Audit / Management pages	✅	⬜	⬜	⬜	⬜	⬜
Notifications & Tickets
Send Slack / Teams / Email	✅	✅	⬜	✅	⬜	⬜
Redact Slack message	✅	✅	⬜	✅	⬜	⬜
Create Jira ticket	✅	✅	⬜	✅	⬜	⬜
API Keys
View Settings → API Keys	✅	✅	⬜	✅	✅	⬜
Create / delete REST API key	✅	✅	⬜	✅	✅	⬜
Zero Trust
View Zero Trust Policies	✅	✅	✅	⬜	⬜	⬜
Update zero trust state	✅	✅	⬜	✅	⬜	⬜
Create / update / delete zero trust policy	✅	⬜	⬜	⬜	⬜	⬜
Settings (Admin-only)
Alert / Risk / Org Config, Webhooks, Scanned Repos Rules, Exclusion Rules, User Management, Secret Type Control, Org Policies	✅	⬜	⬜	⬜	⬜	⬜
Change customer configuration	✅	⬜	⬜	⬜	⬜	⬜
Request new secret pattern	✅	⬜	⬜	⬜	⬜	⬜
Configure group-to-role mapping	✅	⬜	⬜	⬜	⬜	⬜
NHI Campaigns
View / create / manage campaigns and tokens	✅	⬜	⬜	⬜	⬜	⬜
Help Center	✅	✅	✅	✅	✅	✅

Choosing the Right Role

If the user needs to…	Assign
Run the platform end-to-end, including settings and policies	Admin
Work daily with secrets, risks, and NHIs, and communicate with stakeholders	Operator
See everything for reporting or audit, but make no changes	Viewer
Remediate exposed secrets and NHI risks in their own services only	Engineer
Only rotate automation API keys	API Key Manager
Onboard and maintain cloud / SaaS integrations	Integrator (typically alongside another role)

FAQ

Can a user have more than one role? Yes. Effective permissions are the union of all their roles' capabilities.

What happens when RBAC is disabled for a tenant? Every authenticated user behaves as an Admin. This is a legacy compatibility mode; most tenants run with RBAC enabled.

Where are roles assigned? Once SSO and SCIM are configured, managing the roles is available in Settings → User Management. Administrators manage role membership; changes take effect on the user's next sign-in.

Are role checks enforced on the API, or just the UI? Both. The UI hides items the user cannot use, and every API endpoint re-checks the user's role server-side. Bypassing the UI is not a way to gain additional privileges.

What happens if an API endpoint has no role configuration? Access defaults to Admin-only.

Groups-Roles Mapping

SAML and SCIM Provisioning allows you to define user groups within your IdP. These groups can be mapped directly to specific SailPoint Entro roles via a service provided by SailPoint Entro's authentication provider. When a user logs in via SAML, their group membership is sent in the SAML assertion, and the authentication provider maps those groups to roles within SailPoint Entro, allowing you to control access based on the user's group.

Detailed provisioning instructions for Okta and Entra ID are documented separately, see Configure Okta Groups Provisioning and Configure Entra ID Groups Provisioning.