> ## Documentation Index > Fetch the complete documentation index at: https://docs.forge.ai/llms.txt > Use this file to discover all available pages before exploring further. # Roles > Configure organization access, roles, identity providers, and service accounts. Forge access combines human organization roles, invitations, SSO and directory provisioning, group access, and scoped service accounts. Use this page to choose the right access model and configure it for your team. ## Organization roles Forge role-based access control (RBAC) determines what a person can see and change within an organization. Available roles are `Owner`, `Admin`, `Analyst`, `Viewer`, and `Employee`. A person's effective role can come from a direct role, one or more group grants, or the Employee default. Roles govern access to the Forge Console and organization-scoped operations. They do not determine which models, agents, MCP servers, or skills a person may use. That access is enforced separately by [policies](/secure/overview). For temporary access to sensitive Telemetry and Replay content, see [JIT Viewing](/secure/jit-viewing). | Role | Access | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `Owner` | Full organization administration. Can assign any role, manage Owner and Admin memberships, and transfer organization ownership. | | `Admin` | The same registered product permissions as Owner, but cannot assign the Owner role or manage Owner and Admin memberships. | | `Analyst` | Investigate activity, manage policies, work with evidence and compliance evidence, and view approval queues. Cannot administer the organization. | | `Viewer` | Read-only access to organization telemetry and compliance, plus access to submit requests and complete assigned actions. | | `Employee` | Employee self-service access only. Can submit requests and complete assigned actions, but cannot access organization-wide telemetry. | `Owner` is an ownership boundary, not an additional bundle of product permissions. Owner-only authority protects membership administration, ownership transfer, and security recovery controls. ## Permission matrix The matrix below reflects the built-in role grants. | Capability | Owner | Admin | Analyst | Viewer | Employee | | ------------------------------------------- | :---: | :---: | :-----: | :----: | :------: | | View organization and Console | ✓ | ✓ | ✓ | ✓ | No | | Manage organization settings | ✓ | ✓ | No | No | No | | Manage members and invitations | ✓ | ✓ | No | No | No | | Manage SSO and directory sync | ✓ | ✓ | No | No | No | | View the audit log | ✓ | ✓ | No | No | No | | Read organization telemetry | ✓ | ✓ | ✓ | ✓ | No | | Read evidence metadata | ✓ | ✓ | ✓ | No | No | | Read captured evidence content | ✓ | ✓ | No | No | No | | Manage security exports | ✓ | ✓ | No | No | No | | Edit investigations | ✓ | ✓ | ✓ | No | No | | Manage policies | ✓ | ✓ | ✓ | No | No | | Manage fleet and deployment | ✓ | ✓ | No | No | No | | View compliance | ✓ | ✓ | ✓ | ✓ | No | | Manage compliance evidence | ✓ | ✓ | ✓ | No | No | | Manage compliance acceptance | ✓ | ✓ | No | No | No | | Submit MCP and employee requests | ✓ | ✓ | ✓ | ✓ | ✓ | | View MCP approval review queues | ✓ | ✓ | ✓ | No | No | | Decide MCP approval requests | ✓ | ✓ | No | No | No | | View and complete assigned employee actions | ✓ | ✓ | ✓ | ✓ | ✓ | | Access the employee self-service experience | No | No | No | No | ✓ | ## Role assignment Owners and Admins manage people and roles from **Settings > Console access**. | Acting role | Roles it can assign | Memberships it can manage | | ----------- | ----------------------------------------------------- | ----------------------------------------- | | `Owner` | `Owner`, `Admin`, `Analyst`, `Viewer`, and `Employee` | Any other active organization membership | | `Admin` | `Analyst`, `Viewer`, and `Employee` | Analyst, Viewer, and Employee memberships | An Owner cannot demote themself if doing so would leave the organization without an active Owner. To replace the current Owner, transfer ownership to another active member and select the current Owner's new role. Role changes and ownership transfers are recorded in the [Audit Log](/secure/audit-log). ### Add a person Use **Add person** in Console access to send an invitation, choose the person's direct role, and set the invitation expiration. Owners can invite any role, including Owner. Admins can invite Employee, Viewer, or Analyst. Pending invitations can be resent or revoked. When the recipient accepts, Forge creates or links their directory identity and activates their organization membership. You do not need to create a separate directory-only person. ### Access overview The **Access overview** table shows effective access for everyone in the directory, including people who have not signed in. It separates: * **Role**: the effective role Forge enforces. * **Access via**: the direct role, each contributing group grant, or the Employee default. * **Status**: whether the person is active, has not signed in, was deactivated, or was removed. Use the column filters to search by name or email and filter by role, access source, or status. For active members, choose **Manage** to edit the direct role, deactivate or remove the member, or transfer ownership when permitted. Changing a direct role does not override a higher group-derived role. ### Effective role resolution Every active directory person starts with Employee access. Forge then selects the highest role granted directly or through an active group: ```text theme={"system"} Owner > Admin > Analyst > Viewer > Employee ``` Owner can only be assigned directly. Group access can grant Admin, Analyst, or Viewer. Group-derived access is calculated before first sign-in and is applied to active memberships immediately when group membership or mappings change. When a change reduces an active member's access, Forge revokes their existing Console sessions so the lower role is enforced on the next sign-in. ## SSO and SCIM Use SSO to authenticate organization members through your identity provider. Forge supports the major enterprise identity providers, including Google Workspace, Microsoft Entra ID, Okta, OneLogin, Ping Identity, and JumpCloud, through standard SAML 2.0 and OIDC connections. Use SCIM directory provisioning when you want identity lifecycle changes to follow your directory. SCIM can provision and deactivate users and synchronize groups. Map synchronized groups to Forge roles so membership changes are managed from the identity provider. ### Configure SSO 1. Confirm the identity provider, verified domains, and administrator who owns the connection. 2. Under **Settings > Console access > Sign-in setup**, select **Configure SSO** and complete the provider setup. For SAML, provide the requested issuer and metadata; for OIDC, configure the requested client values. 3. Test with a pilot user and verify the organization and assigned role. 4. Require SSO only after administrators have tested recovery access. Keep a documented break-glass process. Review authentication and directory events in the [Audit Log](/secure/audit-log). ### Configure directory sync and groups 1. Under **Settings > Console access > Sign-in setup**, select **Configure directory sync** and complete the provider setup. 2. Assign the users and groups that should be provisioned. 3. Under **Settings > Directory**, confirm the sync status and groups. 4. Under **Settings > Console access > Group access**, map groups to `Admin`, `Analyst`, or `Viewer`. 5. Test a new user, a role change, and deprovisioning before enabling the connection broadly. You can also create a Forge-managed group under **Settings > Directory** and choose its members from active directory people. Forge-managed groups can be renamed, have their membership edited, or be archived. Groups synchronized from an identity provider are read-only in Forge and must be changed at the source. Both Forge-managed and synchronized groups use the same role and policy resolution. Directory group filters support group-name search plus source and member-state filtering. Disabling a group mapping recalculates affected roles immediately. Review group membership and deprovisioning behavior whenever access changes. ## People and Directory Use **People** for identity and activity inventory across the organization. It shows who has been observed, where each person came from, device status, and recent activity. Its table supports text search and categorical filters. Use **Settings > Directory** for directory sync health and group management. Use **Settings > Console access** for invitations and effective Console roles. These surfaces share the same canonical identities and groups, so policy scope, access checks, and product attribution resolve consistently. ## Service accounts Service accounts are organization-scoped machine principals for approved Forge automation, such as CI checks, scheduled exports, SOAR workflows, policy backtests, and internal dashboards. Use them when a workflow should not depend on a human console session. Each service account has a display name, an optional description, a `permissionRole` of `viewer`, `analyst`, or `admin`, a scope allowlist, and one or more named tokens. Tokens have optional expiry, last-used timestamps, and revocation state. Service-account create, update, rotation, revocation, and disable actions are audited. Service accounts cannot be Owners or Employees. Their effective API access is the intersection of: 1. The service account's permission role. 2. The service account's allowed scopes. 3. The scopes on the presented token. 4. Any capability-specific authorization requirements and organization policy. ### Create a service account Grant only the scopes used by the automation. The raw token is returned once; store it in a secret manager immediately. Forge stores token hashes and prefixes, not the raw token value. ```bash theme={"system"} export FORGE_BASE_URL="https://api.forge.ai" export FORGE_ORG_ID="org_123" export FORGE_TOKEN="forge_sa_admin_token" forge service-accounts create \ --name ci-readonly \ --role viewer \ --scopes audit:read,findings:read,inventory:read \ --reason "CI evidence collection" \ --idempotency-key "ci-readonly-create-2026-06-29" \ --confirm ``` The equivalent REST request is: ```bash theme={"system"} curl -X POST "$FORGE_BASE_URL/api/headless/v1/organizations/$FORGE_ORG_ID/service-accounts" \ -H "Authorization: Bearer $FORGE_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "ci-readonly", "permissionRole": "viewer", "scopes": ["audit:read", "findings:read", "inventory:read"], "reason": "CI evidence collection", "idempotencyKey": "ci-readonly-create-2026-06-29", "confirm": true }' ``` The caller needs `organization.manage` permission and the `service_accounts:write` scope. ### Rotate, revoke, and disable Rotate tokens when ownership changes, a secret may have been exposed, or your rotation window requires it. Token scopes are intersected with the service account scopes, so keep the new token scope set narrow. Revoke one token when a single secret should stop working. Disable the service account when the automation is retired or compromised. Use a reason, idempotency key, and confirmation for guarded writes. | Automation | Suggested role | Suggested scopes | | ------------------------------ | -------------------- | ------------------------------------------------- | | Audit export job | `viewer` | `audit:read` | | Compliance snapshot export | `viewer` | `compliance:read` | | Inventory dashboard | `viewer` | `inventory:read`, `entities:read` | | Findings triage bot | `analyst` | `findings:read`, `findings:write` | | MCP approval queue integration | `analyst` or `admin` | `mcp_approvals:read`, `mcp_approvals:write` | | Service-account administration | `admin` | `service_accounts:read`, `service_accounts:write` | These are starting points. Validate the effective role, scopes, capability, and organization policy for each workflow. For service-account credentials, use the [CLI](/developer/cli) or [API](/developer/api) documentation. Review activity in the [Audit Log](/secure/audit-log).