Private betaZynth Auth is currently in private beta testing.New organizations are created by invitation only, and no plan can be purchased yet.Request early access →

Access requests and just-in-time grants

Standing privilege is how least-privilege erodes: access granted for one task quietly becomes permanent. Zynth Auth's access requests invert the default — a member asks for a role, a reviewer approves it for a bounded window, and the grant expires by itself. Extension is a new request, with a new justification, on the record.

Availability — two gates, both required. Access governance is an enterprise-plan capability (Plans and entitlements), and it must be enabled on the deployment. When either is missing, /api/v1/authz/requests returns 404 and the console shows a quiet "not enabled" card — the surface does not advertise itself to an organization that has not bought it.

How it works

  1. Ask. Any member requests a role — system or custom — with a written justification and a duration (1–90 days): POST /api/v1/authz/requests, or Access Requests in the console. Agents and API keys are refused: agent authority is delegations, API-key authority is scopes.
  2. Review. Anyone holding authz:assignments:manage sees the inbox and decides — the natural rule: a request is decided by someone who could have made the assignment themselves. You can never decide your own request, whatever you hold.
  3. Grant, time-bounded. Approval creates a normal role assignment with an expiry — the same assignment every other grant path uses, visible in Access Control like any other. When the window lapses, the access is simply gone at the next permission resolve; nothing needs to run for the expiry to hold.

A pending request that nobody decides expires on its own after 14 days. Requesters can withdraw a pending ask; a duplicate ask for the same role returns the existing one instead of spamming the inbox.

What you get for compliance

Every lifecycle step — who asked for what and why, who decided, and the exact grant it produced — is written to the tamper-evident audit log and mapped to SOC 2 CC6.1–CC6.3 and ISO 27001 A.5.15/A.5.18. Two built-in detections watch the surface: a burst of requests from one principal, and rapid grants by one approver.

Separation of duties

Tenants can declare mutually-exclusive role sets (/api/v1/authz/sod-rules, with seeded templates for the obvious pairs). A grant of any role in a set is refused while the grantee holds another role from the same set — wherever the grant comes from: the console, an invitation, a just-in-time approval, or your IdP's SCIM group sync. Changing someone's role from one side of a pair to the other is allowed (the change resolves the conflict), and a grant that already expired holds nothing.

When an access request would cross a SoD rule, a plain approval is refused with the rule's name. The only way through is deliberate: the reviewer approves again with an explicit sod_override, which is recorded on the request, written to the audit log, and raises a security detection every single time — an override nobody reviews is a block that does not exist. Enforcement fails closed: if the rules cannot be evaluated, the grant is refused.

Certification campaigns

Periodically prove that standing access is still justified. Opening a campaign (POST /api/v1/authz/campaigns) snapshots every live role assignment in scope as a review item; reviewers — holders of the campaign's designated reviewer permission, and never for their own access — attest (the access stands) or revoke (the access ends immediately) each item, with a reason on the record.

Closing the campaign settles whatever was not reviewed. By default, unreviewed grants are auto-revoked — a review nobody performed must not silently renew access. A campaign can opt out at creation, in which case unreviewed items are marked lapsed and the grants deliberately stand, visibly. Every step maps to the SOC 2 CC6.3 and ISO 27001 A.5.18 access-review controls, and a built-in detection flags rubber-stamp cadences (dozens of decisions by one reviewer in minutes).

Requesting a single permission

Request a role that carries it. If no role fits, a tenant admin can define a one-permission custom role (Access Control → Roles) — including over your own applications' custom permissions — and members can then request exactly that. One grant machinery, no special cases.