Approvals and privileged access

Some actions need a person's decision. Authpermit does not mark them "approved"; it opens an approval, and the action runs only when the approval is decided.

Approvals

• What opens one: an AI agent's high-risk MCP call, an automation step above its autonomy, a sign-in your policy sends for review, a just-in-time access request, and the review after a break-glass.
• N-of-M: an approval needs required_approvals distinct people holding its permission (and one of its eligible_roles, when set); required_roles must each be covered — for example a security analyst and an administrator. One refusal decides it.
• The two-person rule: nobody approves their own request, whatever their role. Only people approve: an API key, an agent or an automation can ask, never answer.
• Expiry: an approval that is not decided in time expires and the action does not run.
• Signed: every decision and every outcome is signed (Ed25519, compact JWS) over the request's digest, the approver, their roles and authentication level and the time. The public key comes with every approval, so a decision can be verified outside Authpermit; the decisions are also evidence on the resource they guarded.

Decide in Approvals in the console, or with POST /api/v1/approvals/{id}/decisions using an OAuth token issued to you (scope approval:decide).

Just-in-time access

Instead of holding a powerful role all the time, ask for it when you need it: a role or permissions, for 5 minutes to 8 hours, with a reason. The identity.access policy decides: by default an approval, from two people when the role is owner or administrator or carries sensitive permissions. An approver can only grant what they could grant themselves. The access ends on its own when the time is up, and open sessions lose it at once.

Break-glass

For emergencies, people holding access:break_glass can take access at once, for at most an hour, with multi-factor authentication and a written reason. It is loud on purpose: a critical identity.break_glass event (webhooks, live feed), evidence in the ledger, a notification to every owner, administrator and security analyst, a security incident, and a review someone else must complete. A review that refuses ends the access.

Sign-in approval

A policy on identity.authenticate that returns REVIEW makes a sign-in wait for an administrator (permission member:manage, at MFA). The person's browser waits; once approved, the sign-in completes once, in that browser.

Applications

An OAuth application can require a minimum authentication assurance level (min_aal 1–3) and a device (device_requirement: known, managed or compliant). Authpermit asks for a step-up, or refuses the authorization with access_denied, before issuing a code.