Skip to main content
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. For temporary access to sensitive Telemetry and Replay content, see JIT Viewing.
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.

​
Role assignment

Owners and Admins manage people and roles from Settings > Console access. 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.

​
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:
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.

​
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.
The equivalent REST request is:
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. These are starting points. Validate the effective role, scopes, capability, and organization policy for each workflow. For service-account credentials, use the CLI or API documentation. Review activity in the Audit Log.