SaaSLayer

Access Requests

Access requests provide a managed workflow for asking for permissions instead of granting them directly.

Use access requests when:

  • Users need temporary elevated access.
  • Managers or resource owners must approve access.
  • You need an audit trail for who requested, approved, denied, or changed access.
  • Permissions should be applied automatically only after approval.

Request types

Common request types include:

  • role_assignment
  • policy_attachment
  • resource_grant
  • operation_approval
  • principal_delegation

Each request has a requester, target, scope, reason, status, approvals, and timeline.

The requester field is typed and supports USER, AGENT, and SERVICE_ACCOUNT:

{
  "requester": { "type": "AGENT", "id": "support-bot" }
}

For backwards compatibility, the older requesterId / requesterType shape is still accepted and normalizes to the same internal representation.

principal_delegation is documented separately in Agent Delegation — it has its own target shape (grantor, actions, resources, grantMode, etc.) and its own session-minting flow.

Create a request

POST /access-requests
Content-Type: application/json

{
  "requesterId": "user-alice",
  "type": "role_assignment",
  "target": {
    "principalType": "USER",
    "principalId": "user-alice",
    "roleId": "role-billing-manager"
  },
  "scope": "tenant-acme-prod",
  "reason": "Need to reconcile invoices for month-end close",
  "ttlHours": 8
}

If the request matches an approval rule, it waits for the required reviewers. If the request is a safe de-escalation, such as removing the requester's own access, it may apply immediately.

Approval rules

Approval rules define who can approve what.

POST /approval-rules
Content-Type: application/json

{
  "scope": "tenant-acme-prod",
  "requestType": "role_assignment",
  "target": {
    "roleId": "role-billing-manager"
  },
  "approvers": [
    { "type": "role", "id": "role-tenant-admin" }
  ],
  "requireCount": 1
}

Design approval rules around ownership and risk. Low-risk role requests may need one tenant admin. High-risk requests may need multiple approvers.

Review pending requests

GET /access-requests/pending-reviews?userId=user-manager

This returns requests the reviewer can act on.

Approve a request

POST /access-requests/req_01h.../approve
Content-Type: application/json

{
  "approverId": "user-manager",
  "comment": "Approved for month-end close"
}

When the approval threshold is reached, SaaSLayer Permissions applies the approved entitlement change.

Deny or counter-offer

Deny a request:

POST /access-requests/req_01h.../deny
Content-Type: application/json

{
  "approverId": "user-manager",
  "reason": "Use read-only access instead"
}

Some workflows support counter-offers, where a reviewer approves a safer alternative instead of the exact requested entitlement.

Request lifecycle

Typical statuses:

  • PENDING
  • APPROVED
  • DENIED
  • CANCELLED
  • EXPIRED

Use the timeline endpoint to show request history in an admin UI:

GET /access-requests/req_01h.../timeline

Practical guidance

  • Require reasons for privileged access.
  • Use TTLs for temporary access.
  • Keep reviewer groups small enough to be accountable.
  • Route high-risk roles through stricter approval rules.
  • Make de-escalation easy.
  • Review access-request audit data periodically.
  • For approval notifications outside the SaaSLayer admin UI, configure a webhook or EventBridge subscription on access_request.* events.