Access Requests

Access Requests provide a streamlined way to request and grant access to Toolkit resources. Instead of manually creating policies, users can request specific access levels (like “read-data” or “view-job-logs”) and administrators can approve or reject these requests through a simple workflow.

Overview 

The access request system allows users to:

Request access to resources (data, jobs, services, accounts) for themselves, a team, or a role
Track the status of their requests
Approve or reject requests from other users (if you’re an administrator)

When a request is approved, the system automatically creates the appropriate policies with the correct permissions.

Request States 

Access requests can be in one of the following states:

State	Description
`PENDING`	Request is awaiting approval from an administrator
`APPROVED`	Request was approved and access has been granted
`REJECTED`	Request was rejected by an administrator
`CANCELLED`	Request was cancelled by the requester
`EXPIRED`	Request expired before being processed

Creating Access Requests 

You can request access to a resource for a user, team, or role. The access request specifies:

Target: The user, team, or role that should receive access
Resource: The resource to grant access to
Action: The type of access being requested (see Available Actions)

Request Access for a User 

# Request read access to a data resource for yourself
eai user request-access <user-id> --action read-data --resource <data-id> --reason "Need access for project X"

# Request access with an expiration date
eai user request-access <user-id> --action read-data --resource <data-id> --expiration 2026-12-31T23:59:59Z

# Request shareable access (can be shared with others)
eai user request-access <user-id> --action read-data --resource <data-id> --shareable

Request Access for a Team 

# Request read access to a data resource for a team
eai team request-access <team-id> --action read-data --resource <data-id> --reason "Team needs access for project"

# Request write access with expiration
eai team request-access <team-id> --action write-data --resource <data-id> --expiration 2026-06-30T23:59:59Z

Request Access for a Role 

# Request read access to a data resource for a role
eai role request-access <role-id> --action read-data --resource <data-id> --reason "Role members need access"

# Request access with cascading permissions (applies to children)
eai role request-access <role-id> --action view-jobs-account --resource <account-id> --cascades

Request Flags 

Flag	Description
`--action`	Required. The action to request (see Available Actions)
`--resource`	Required. The resource ID or full name to request access to
`--reason`	Reason for the access request (recommended)
`--expiration`	Access expiration time in RFC3339 format
`--shareable`	Whether the granted access can be shared with others
`--scope`	Scope of the access (for policy sharability)
`--cascades`	Whether access cascades to child resources (roles only)

Managing Your Access Requests 

List Your Requests 

# List your access requests (default: shows only your requests)
eai accessrequest ls

# List only your pending requests
eai accessrequest ls --state PENDING

# List all your requests regardless of state
eai accessrequest ls --state in:PENDING,APPROVED,REJECTED,CANCELLED

Get Request Details 

# Get details about a specific request
eai accessrequest get <request-id>

Update a Pending Request 

You can update the reason for a pending request:

# Update the request reason
eai accessrequest set <request-id> --request-reason "Updated reason for access"

Cancel a Request 

You can cancel your own pending requests:

# Cancel a single request
eai accessrequest cancel <request-id>

# Cancel multiple requests
eai accessrequest cancel <request-id-1> <request-id-2>

Processing Access Requests (Admins)

If you are an administrator of the requested resource (the resource someone is asking access to), you can approve or reject access requests.

List Actionable Requests 

# List requests you can approve/reject (pending requests where you're a recipient)
eai accessrequest ls --actionable

# List all access requests (requires appropriate permissions)
eai accessrequest ls --all

# Filter by various criteria
eai accessrequest ls --all --state PENDING
eai accessrequest ls --all --action read-data
eai accessrequest ls --all --resource <resource-id>

Approve a Request 

# Approve an access request
eai accessrequest approve <request-id>

# Approve with remarks
eai accessrequest approve <request-id> --remarks "Approved for project X"

When you approve a request:

The system creates the appropriate policies for the target (user/team/role)
An email notification is sent to the requester
The request state changes to APPROVED

Reject a Request 

# Reject an access request
eai accessrequest reject <request-id>

# Reject with remarks (recommended)
eai accessrequest reject <request-id> --remarks "Access not justified for this resource"

When you reject a request:

An email notification is sent to the requester explaining the rejection
The request state changes to REJECTED

Available Actions 

The following actions can be requested. Each action maps to specific permissions that will be granted when the request is approved.

Data Actions 

Action	Description
`read-data`	View properties and read contents of a data resource
`write-data`	View properties and read/write contents of a data resource
`update-data`	View and update properties of a data resource

Job Actions 

Action	Description
`view-job-logs`	View properties and logs of a job
`access-job`	View properties and access a job via URL
`update-job`	View and update properties of a job
`exec-into-job`	View properties and exec into a job

Service Actions 

Action	Description
`view-service`	View properties of a service
`update-service`	View and update properties of a service
`view-job-logs-service`	View properties and logs of jobs under a service
`access-job-service`	Access jobs under a service via URL
`update-job-service`	Update properties of jobs under a service
`exec-into-job-service`	Exec into jobs under a service

Account Actions 

Action	Description
`view-account`	View properties of an account
`update-account`	View and update properties of an account
`view-subaccounts`	View properties of account and all subaccounts
`update-subaccounts`	Update properties of account and all subaccounts
`read-data-account`	Read all data under an account
`write-data-account`	Read/write all data under an account
`update-data-account`	Update properties of all data under an account
`create-jobs-account`	Create new jobs in an account
`view-jobs-account`	View all jobs under an account
`exec-jobs-account`	Exec into all jobs under an account
`create-service-account`	Create new services in an account
`pull-image-account`	Pull images from registry under an account
`push-image-account`	Push images to registry under an account

Filtering and Sorting 

The eai accessrequest ls command supports powerful filtering and sorting options.

Filter Fields 

Field	Description
`requestId`	The unique request ID
`requestedBy`	The user who created the request
`action`	The requested action
`resource`	The target resource ID
`target`	The user/team/role that would receive access
`state`	The request state (PENDING, APPROVED, etc.)
`createdAt`	When the request was created
`processedAt`	When the request was processed
`expiresAt`	When the request expires
`recipients`	The administrators who can process the request

Filter Operators 

Filters support the following operators:

# Exact match
eai accessrequest ls --all --state PENDING

# In list (any of these values)
eai accessrequest ls --all --state in:PENDING,APPROVED

# Not equal
eai accessrequest ls --all --state ne:REJECTED

# Greater than / Less than (for dates)
eai accessrequest ls --all --createdAt gt:2026-01-01

Sorting 

Use the --order flag to sort results:

# Sort by creation date (descending)
eai accessrequest ls --order -createdAt

# Sort by action, then by creation date (descending)
eai accessrequest ls --order action,-createdAt

# Sort by expiration date
eai accessrequest ls --order expiresAt

Valid order fields: action, state, createdAt, processedAt, expiresAt

Examples 

Example 1: Request Data Access for Your Team 

# 1. Find the team ID
eai team ls

# 2. Request read access to a dataset
eai team request-access acme.ml-team --action read-data --resource acme.datasets.training-data \
    --reason "Team needs access for model training"

# 3. Check the status of your request
eai accessrequest ls

Example 2: Approve Requests as an Admin 

# 1. List pending requests you can approve
eai accessrequest ls --actionable

# 2. Review request details
eai accessrequest get <request-id>

# 3. Approve the request
eai accessrequest approve <request-id> --remarks "Approved for Q1 project"

Example 3: Request Job Access with Expiration 

# Request access to view and exec into a job for 30 days
eai user request-access $(eai user get --field id) \
    --action exec-into-job \
    --resource <job-id> \
    --expiration $(date -u -d '+30 days' +%Y-%m-%dT%H:%M:%SZ) \
    --reason "Need to debug production issue"

API Endpoints 

For programmatic access, the following REST API endpoints are available:

Endpoint	Method	Description
`/v1/resource-access-requests`	GET	List all access requests
`/v1/resource-access-requests/<id>`	GET	Get a specific request
`/v1/resource-access-requests/<id>`	PUT	Update a pending request
`/v1/resource-access-requests/<id>`	DELETE	Cancel a pending request
`/v1/resource-access-requests/<id>/process`	POST	Approve or reject a request
`/v1/user/<id>/request-access`	POST	Create request for a user
`/v1/team/<id>/request-access`	POST	Create request for a team
`/v1/role/<id>/request-access`	POST	Create request for a role

Email Notifications 

The access request system sends email notifications at key stages:

Request Created: Administrators of the target resource receive an email about the new request
Request Approved: The requester receives an email confirming access was granted
Request Rejected: The requester receives an email explaining the rejection
Request Expiring: Reminders are sent before requests expire (if not yet processed)

Limitations 

Access requests cannot be raised for personal accounts or legacy accounts without an admin role
Only one pending request can exist for the same action, resource, and target combination
Only the original requester can cancel or update a pending request
Only designated recipients (administrators) can approve or reject requests