Skip to content

End-to-end sequence

This page is the authoritative source for sequence across the whole site: 7 hops in the SaaS model, 8 hops in the self-hosted same-domain sidecar model, in two complete swimlane diagrams. Every sequence fragment elsewhere is a crop of one of these two. The models differ by a single hop: ⑧ identity federation.

Two numbering systems in these diagrams

The 1–N produced by autonumber are message numbers (one per arrow). ①–⑧ are stage numbers — when the docs say "hop N" anywhere on this site, they mean the latter. One stage number usually covers several messages.

SaaS model: 7 hops

Your app points at api.eak.eazo.ai. Here is the full loop, from registration to revocation:

Useremployee / end userAppyour app and resource servicesAgentGenAuthHuman IAM① Registration and approval (one-time, control plane)Register the agent (Owner + Sponsor in place)1Approved; the agent enters the registry2② Start the delegation (per task / session)Hand off the task(“put together the customer weekly report”)3Delegation request (interactive)4Consent page (scope + duration)5③ Attenuation check: real permissions ∩ explicit delegation ∩ approved boundaryEvaluate the user's real permissions6Permission assertion7④ Issue the Delegate TokenApprove8Delegate Token(short-lived · attenuated · carries audit_id)9⑤ Token exchange (RFC 8693)Request a resource access tokenwith the Delegate Token10Access token (sub = user, act = agent)11⑥ Constrained access (resource-side checks)Call the API with the access token12Check the sub / act / scopeintersection13Return only data insidethe granted scope14⑦ Audit and revocation (throughout)Audit chain is queryable(who granted · on whose behalf · what was done)15Stop further issuance (see e5 for timing)16

Self-hosted same-domain sidecar model: 8 hops

GenAuth runs inside your environment, and the authority on a person's identity is the Human IAM you already have — so one extra hop appears before consent: ⑧ identity federation (inserted between ② and ③). The user first completes OIDC federated login with their enterprise account, and GenAuth thereby confirms that "Alice is the Alice in your directory".

Useremployee / end userAppyour app and resource servicesAgentGenAuthdeployed in your environmentHuman IAMyour existing identity system① Registration and approval (one-time, control plane)Register the agent (Owner + Sponsor in place)1Approved; the agent enters the registry2② Start a delegationHand off the task3Delegation request (interactive)4⑧ Identity federation: sign in with your existing enterprise account (OIDC)Federated login redirect5Authenticate with the enterprise account6Identity assertion(Alice = the Alice in your directory)7② (continued) ConsentConsent page (scope + duration)8③ Attenuation check: real permissions ∩ explicit delegation ∩ approved boundaryEvaluate the user's real permissions(in-domain API / read-only view)9Permission assertion10④ Issue the Delegate TokenApprove11Delegate Token(short-lived · attenuated · carries audit_id)12⑤ Token exchange (RFC 8693)Request a resource access tokenwith the Delegate Token13Access token (sub = user, act = agent)14⑥ Constrained access (resource-side checks)Call the API with the access token15Check the sub / act / scopeintersection16Return only data insidethe granted scope17⑦ Audit and revocation (throughout; data never leaves the customer domain)Audit chain is queryable(who granted · on whose behalf · what was done)18Stop further issuance (see e5 for timing)19

Which page covers each hop

The diagrams give you the whole picture; the details each have their own page. Below, in the self-hosted narrative order (① ② ⑧ ③ ④ ⑤ ⑥ ⑦) — for the SaaS model, skip ⑧:

HopStage (responsible parties)API / mechanismRelated pageNote
Registration and approval (App admin × GenAuth)Control plane: agent registration, approval, binding accountable humansRegister and manage your agents · The agent identity modelRoadmap
Start a delegation + consent (User × App × GenAuth)POST /api/v3/eak/delegations (interactive) → GET /api/v3/eak/delegations/:grantId/approval-contextPOST /api/v3/eak/delegations/:grantId/approveConsent and approval
Identity federation, self-hosted only (GenAuth × Human IAM)OIDC federated login + user mappingIntegration principlesRoadmap
Attenuation check: the three-way intersection (GenAuth × Human IAM)Evaluation of the user's real permissionsDelegate Token and attenuationRoadmap
Issue the Delegate Token (GenAuth)POST /api/v3/eak/delegations/callback/consume → Delegate TokenDelegate Token and attenuation · Token and claim reference
Token exchange (Agent × GenAuth)POST /api/v3/eak/token-exchange (RFC 8693)Delegate Token and attenuation · Let agents call your APIs on behalf of users
Resource-side checks (App: resource service / gateway)sub / act / scope intersection checksProtect your APIs: resource-side integrationRoadmap
Audit and revocation (GenAuth × user / admin)audit_id threads the whole chain; POST /api/v3/eak/delegations/introspect; layered revocationAudit and accountability chain · Revocation and emergency response

How to read the hops marked Roadmap

For stages marked Roadmap, the concepts and design are settled — both diagrams are drawn to that target state — and interfaces and steps are subject to the final release. The corresponding pages carry the same badge above the fold.

The difference between the models is ⑧

There is exactly one difference:

  • SaaS model: user identity is confirmed on the hosted side, the consent screen opens directly, 7 hops end to end.
  • Self-hosted model: the authority on a person's identity is your Human IAM, so ⑧ comes before consent — OIDC federated login plus user mapping, anchoring "the person confirming this authorization" to a real employee in your directory. 8 hops end to end.

The other seven hops match line for line across both models: same concepts, same APIs, same audit chain. That is what backs the claim of "zero code difference between models" (see Deployment models).

Next steps