Identity proves who is acting; IAM decides what they may reach in general. Decionis decides whether the specific action in front of it may execute — allow, hold for a person, or block, with a signed record of the decision. Teams keep their IdP and role model exactly as they are and add per-action authority on the handful of actions where a correct login is not enough.
the actor is already authenticated and authorized in the IAM sense, and the risk lives in the particular action: an agent with a legitimate tool grant stacking discounts below cost, a service account with write access releasing a payment twice, a privileged operator deleting production data at 2am. You need a judgement about this action, now — policy and evidence evaluated inline, a person pulled in when the rules require one, and signed proof afterwards.
you are answering who someone is and what standing access they should hold: joiner-mover-leaver lifecycle, SSO and MFA, role design, entitlement reviews, least-privilege cleanup. Identity platforms and access-governance tools are built for exactly that, and a per-action decision gate is the wrong place to run a workforce directory or a quarterly access certification.
Identity is an input to authority, not a rival to it. The gate consumes who is acting — human or agent, and on whose behalf — from the identity layer you already run, then answers the question that layer never asks: may this specific action execute now. Escalations route to a named approver, the approval is bound to the action itself rather than to a session, and where step-up matters the approver proves presence on their own device instead of merely holding a valid login.
Agent SSO reached general availability in August 2026, giving AI agents a first-class identity at the point of connection on the open Cross App Access protocol, included in core Okta SSO plans.
Checked 2026-09-06 · Okta — Agent SSO press release (retrieved 6 Sep 2026)
Auth0 for AI Agents is generally available, including Token Vault, which holds and refreshes third-party API tokens on an agent's behalf so the agent never handles the raw credential.
Checked 2026-09-06 · Auth0 — Auth0 for AI Agents is generally available (retrieved 6 Sep 2026)
WorkOS argues that agents need identity, authorization and audit in the same place, so that which agent did something, and on whose authority, can be answered from one system — the question an execution authority answers per action, with evidence.
Checked 2026-09-06 · WorkOS — Agents need identity, authorization, and audit in the same place (retrieved 6 Sep 2026)
CrowdStrike introduced an identity provider for AI agents: cryptographically verifiable agent identities, short-lived access scoped to each task, and attribution of every agent action to the human or workload it acts for. Those are the identity and access inputs an execution authority reads; the announcement does not describe deciding whether the exact business action has authority, or evidence a third party could verify afterwards.
Checked 2026-09-07 · CrowdStrike — Agentic Identity Provider (press release) (2 Sep 2026, retrieved 7 Sep 2026)
Each of these is an input to the authority decision, not a substitute for it — see “Running both” above.
| Dimension | Decionis | Identity and access management |
|---|---|---|
| Question answered | May this specific action execute, now, under this policy and evidence? | Who is this, and what may they reach in general? |
| Unit of control | One intended action, with its amounts, counterparty, and context. | A user, role, group, or entitlement, granted ahead of time. |
| When it decides | At the moment of execution, inline in the action's own path. | At grant time — hours, weeks, or years before any given action. |
| The agent problem | Each tool call is evaluated per action, so a legitimate credential cannot quietly stack discounts below cost. | An agent holding a valid token is indistinguishable from any other authorized caller. |
| Human involvement | A named person approves when policy requires it, bound to the specific action. | Approval happens at access-request time; individual actions proceed on standing access. |
| Evidence afterwards | A signed decision record per action — policy version, evidence, verdict, approver. | Access logs and certification history — who could act, not why an action was permitted. |
| Cost of a gap | A policy gap surfaces as one held or escalated action, visible the same day. | An over-broad grant surfaces as everything that credential did until the next review. |
Least privilege narrows what a credential can reach, and it is worth doing — but a purchase within scope can still be the wrong purchase. The agent allowed to spend can overspend; the operator allowed to refund can refund twice. Scope bounds the blast radius; authority judges the action inside the scope, against amounts, counterparties, and rules a role model cannot express.
The privileged-access patternNothing you run today goes away. PAM controls who may hold powerful credentials and records the session; reviews certify standing access after the fact. Neither stands in the path of a single action, and neither can hold one payment while approving the next. The gate adds that step, and its signed record is the artifact the next review reads instead of reconstructing intent from logs.
Where the controls sitGive them one — workload identity for agents is the right direction, and the gate assumes it. But identity for agents solves attribution, not permission: knowing which agent acted does not decide whether the action was within policy. Decionis binds each verdict to the acting identity and, when the rules require it, to the human the agent was acting for.
AI agent governanceNo. A session proves someone logged in at some point; an approval has to prove that the right person consciously authorized this action. Escalations carry the action's own content to the approver, and where the rules demand presence, the approver completes a passkey ceremony on their own device — evidence that survives an auditor asking who approved this, and how you know.
How approvals arriveNo, and that is the case identity cannot see: the agent's identity is real, its credential current, its API permitted — and what it asks for is not what anyone authorised. Authority is bound to the exact action, never to the principal, so a valid principal with an unauthorized intent is refused or held, and a change to the action after authorization fails the binding. The reference implementation states it as the Compromised Principal Test: one page, three ways to run it in under a minute, and what each proves and does not.
Run the Compromised Principal TestRun a scenario in the sandbox and download the signed Decision Dossier it produces, or install shadow mode and watch what would have been held on your own traffic.
Start Now