Intro
Scopes are an essential building block to achieving least-privilege access using Axiom. Scopes control what the users can request access to, and who can approve these requests.
Scopes are accessed from the left-side navigation, under the Axiom IAM heading:
Default scope
Every new user enrolled* in Axiom is assigned to the scope set as Default.
When you first start using Axiom, the built-in Global Requesters scope is set as the Default.
Only one scope can be set as Default.
* enrollment happens when the user first signs into Axiom, or when an IdP group he is a member of is synced to Axiom using IdP Sync
Built-in scopes
Axiom comes preconfigured with two special built-in Scopes:
Global Requesters
This scope initially has “Any” set as the System, and is set as the Default scope. This means that when first starting to use Axiom, every new user can request access to anything (any System/ Target/ Permission). This scope is editable.
Global Admin
This non-editable scope provides access to all parts of the Axiom User Console. It also allows making any request, and overriding approval policies. The first user added to Axiom during initial onboarding is set as a Global Admin. A Global Admin can promote other users to also be Global Admins (or demote Admins to regular users).
Creating/ editing scopes
Overview
Every scope consists of:
Scope settings
Scoping rulesets
Approval policy
Assigned users
Scope settings
Name
Min 6, max 128 chars.
Set as default toggle
All newly enrolled users are assigned to the default scope as requesters: set the default scope as one encompassing what you want all your users to be allowed to request.
Scope rulesets
A scope can include one or more rulesets. Rulesets define which resources this scope encompasses, and each is made up of:
System
Target
Permissions
System
Select a single system (e.g. AWS, PostgreSQL)
Target
Select a Target:
Explicitly (one per ruleset)
Using a glob matching string
Using tag matching
Glob matching for Targets
Glob matching for Targets is done against Axiom’s representation of a Target path.
Using glob match rules for Target matching allows you to:
Create fewer scopes and rulesets (one ruleset can cover many matching targets).
Create fine-grained scoping control. For example, all tables and views, for a specific schema, for any database that ends with “-dev” (My Integration/*-dev/xyzSchema/*).
Example target paths:
My Okta Integration
Production/test-server
Dev Env/main/general/customers
The first part of the path (the root, e.g. "Dev Env") is the integration name. This is the alias in Axiom, as entered when creating the integration.
Some integrations only have a root because there are no addressable subresources: for example, IdPs such as Okta (example #1).
Example #2 above is an AWS EC2 instance: Production (the root) is the AWS integration name, and “test-server” is the name (name tag) of the EC2 instance.
Example #3 above is a PostgreSQL schema: Dev Env is the PostgreSQL integration name, "main" is the database name, and "customers" is the schema name.
The most common way of using glob matching is with the “*” and "**" wildcards.
Learn more about the full power of target selection using glob matching
Note that any literal “/” in resource names needs to be escaped using “\”.
Tag matching for Targets
This feature will be released and documented in July 2025.
Permissions
Permissions can be selected:
Explicitly (multiple per ruleset)
By glob matching matching
Glob matching for Permissions
The match is done against the Permission name. Depending on the system and Target selected, the Permission can be a role, a permission set (AWS), or a group name.
Since there are not paths on permission names, "/" is treated literally, and "*" and "**" have the same effect.
Selecting “Any”
Selecting “Any” for either Target or Permissions is the same as entering ** as the glob match string.
Allow crafting (AWS only)
Controls whether requesters will be allowed to create requests with crafted permissions for AWS.
Approval policy
Approval policies allow you to define how many approvals are needed for requests matching that scope, and whether these approvals can be provided in parallel, or need to be provided sequentially. The default is one required approval in one step.
Eligible approvers are added to each step using the Add approvers button, and can be a combination of users and groups, or can be from an oncall schedule. However, you cannot combine users/groups with an on-call schedule.
Approval policies and automated approvals from Workflows
Workflows can provide a single automated approval to the first step in an approval policy. You can disable this by setting Max automated approvals to zero.
Workflows cannot provide automated approvals to steps beyond the first step.
Understanding how Approval policies are applied to requests
When a request is submitted a matching scope is calculated. The approval policy from that scope is used to create a static approval chain for the request. This means that any users in groups (or on-call schedules) defined as approvers in the policy are extracted and added to the request as approvers (for the appropriate step); any subsequent changes to the scope or the groups do not affect the approvers on the request.
Full details of the resulting approval chain, including a link to the matched scope can be viewed in the Approvers tab of the request's Details page.
How the matching scope is calculated
Each step in the scope’s Approval Policy adds 1000 "points".
Each required approver adds 100 points.
Each Ruleset adds 10 points.
In case of a tie, the scope that was created last takes precedence (createdDate, not lastModifiedDate).
Example: A scope with one ruleset, and a policy with two steps, each of which requires one approval, gets a score of 2,210 (1000 x 2 steps, plus 100 x 2 required approvers, plus 1 x ruleset).
Viewing a request approval chain and its progress
To view a request’s calculated approval chain and its progress, go to the Approvers tab in the request’s Details page.
Notifications
Approvers only receive notifications for approving a request when an action is needed from them. If, for instance, you create a two-step approval policy, the approvers in the second step will not receive a notification until the first step is completed (has received all required approvals).
Notifications are sent by email, and if configured, by Slack or Teams.
Approval chain resets
Approval chains are reset on most edits of a request (other than changes to justification or reducing the duration). This means the approvals need to start again from the beginning of the first step (and approvers will receive new notifications accordingly).
Partial approvals, final approval, and denials
Final approval
A request will change to status Approved, and access provisioning will be triggered only once all approvals in all steps have been granted. The request’s Principal then receives an approval notification, and the Connect button is enabled.
Partial approval
If an approval chain requires multiple approvals, then every approval creates a Partial approval. The request’s Principal will receive a notification about the approval progress, and the Requests list page, and the Request details page will also show this partial progress.
Full details can be seen in the Approvers tab of the request’s Details page.
Deny
Any Deny action by any approver in any step, will change the request status to Denied. The Principal will receive a notification (with the Deny reason as entered by the approver who denied the request), and will need to submit a new request if s/he still wants that access granted.
Role assignment
Currently, the only role a user can be assigned for a given scope is Requester. We will soon be adding additional roles such as Scope admin, Reviewer, and more.
When making requests, users only see Systems, Targets, and Permissions that they have scope for (are assigned to as a requester).
You can assign either individual users to scopes, or groups synced from your IdP. Learn more about IdP sync
Scopes and templates
Users only see templates for which they have access to all Systems, Targets, and Permissions included in the template.
Examples:
A template includes access to an AWS account (System and Target), and a MySQL database. The user has scope for the AWS account but not for the MySQL database. The user will not see the template at all.
For the same template as above, the Permission for the database is specifically “Read and write”. The user has scope for the AWS account and does have scope for the MySQL database. However, the user only has scope for “Read” Permission on that database. The user will not see the template at all.
Scopes, approvers, and bundles
In the Requests list page (where requests are grouped by bundles), Approvers only see requests for which they have approver scope. This means that when viewing a bundle, approvers may not see (or be able to approve) all the requests in the bundle.
Scoping best practices
Over time, we recommend that you limit what the Default scope can permit, until you achieve true least privilege where the Default scope does provides little or no scope, and all scoping is from explicit assignments through groups.
Keep the number of Global Admins to a minimum, ideally only one (a Global Admin can request anything and can approve his/her own requests).
Overriding a request’s approval chain
A request’s approval chain can be overridden only by your Axiom account’s admin users.
This option is most typically used for:
Time-sensitive access situations requiring immediate approval.
When normal approvers are unavailable.
When an approval chain is overridden, the request’s remaining required approvers are replaced by a single approver. The new eligible approvers are selected in the Override approvers dialog (but only one approval will be required even if multiple eligible approvers are selected).
The new eligible approvers receive an “Approval required” notification (email/ Slack/ Teams). Previous approvers can no longer approve the request and will see an error if they attempt to do so.
The override action, and the subsequent approve/ deny decision are logged in the Audit log.
To open the Override approvers dialog, go to the Approvers tab in the Request details page, and press on the “Override approvers” link.