Deployment models
GenAuth ships in two deployment models with identical capabilities and identical APIs: SaaS-hosted, and self-hosted same-domain sidecar. Which one you pick comes down to a single question: may your delegation data, audit logs, and credentials leave your environment?
SaaS-hosted
Ready out of the box: point at api.eak.eazo.ai, use the console at dashboard.qoni.ai, run nothing yourself.
The key property in one line: GenAuth is on the authorization path, not the data path. Agents reach resources by calling your API directly, and business data — the resource content an agent actually reads and writes — never passes through GenAuth. What does leave your environment is only the metadata needed to complete delegation and audit: which agent, what scope, for how long, which user identifier.
Self-hosted same-domain sidecar
GenAuth is deployed incrementally as a component inside your Kubernetes environment, running in the same domain as your existing Human IAM (human identity and access management — the enterprise identity system you already run). "Sidecar" draws three boundaries:
- No replacement: your current IdP remains the authoritative source for who a person is and what they may do.
- No migration: the user directory stays where it is, and GenAuth performs read-only permission evaluation.
- No refactor: existing login, SSO, and permission models are untouched (for the onboarding path, see Connect your existing identity stack).
The two models differ by exactly one hop in the business sequence: self-hosted adds hop ⑧ — before consent, the user first completes OIDC federated login with their enterprise account, confirming that "Alice is the Alice in your directory". For the full sequence and the status annotation on each stage, see End-to-end sequence.
Reviewing a self-hosted proposal, an architect always asks three questions. Here are the answers.
Answer 1: the data boundary matrix
The conclusion first: in the self-hosted model, delegation data, audit logs, and credentials all stay in your environment, and GenAuth sends no business data outward. Category by category:
| Data category | SaaS-hosted | Self-hosted same-domain sidecar |
|---|---|---|
| Agent register (registration details, accountable humans) | Stored in the hosted service | Stays in your environment |
| Delegation records (authorized scope, duration, consent records) | Stored in the hosted service | Stays in your environment |
| Tokens (Delegate Token / access token) | Issued by the hosted service, circulate through your call chain | Issued and circulated inside your environment; never leave the domain |
| Audit logs | Stored in the hosted service; queryable and exportable from the console | Fully resident in your environment (data residency) |
| User identity and permission data (Human IAM side) | Never migrated: GenAuth performs evaluative reads only | Never leaves the domain: read-only access within the same domain |
| Server-side credentials such as AK/SK | The SK is held by your server | Issued and held entirely inside your environment |
Worth repeating for both models: business data never passes through GenAuth. It is not on the data path between an agent and your resource services.
Answer 2: the service-to-service authentication matrix
In the self-hosted model, every service-to-service call has to answer "authenticated on what basis, and where does the credential live":
| Call direction | Authentication | Credential form and management |
|---|---|---|
| App → GenAuth | Server-side AK/SK authentication over TLS; mTLS can be enabled in-cluster | The secret goes into your secret management stack (Kubernetes Secret or an external secrets manager), with rotation and immediate revocation |
| Agent → GenAuth | Delegate Token (presented at exchange time) | Short-lived, attenuated, recallable; no long-lived credential ever lands on the agent side |
| Agent → your resource services | Access token: signature verification + aud binding + sub / act / scope checks | The resource side only verifies the signature — no shared secret (checklist in Protect your APIs) |
| GenAuth → Human IAM | A dedicated read-only integration account | See "three rules for read-only access" below |
| Between GenAuth components | mTLS inside the same namespace (service mesh or cluster platform capability) | Certificates issued and rotated by the cluster PKI |
Read-only access to Human IAM: three rules
The boundary architects watch most closely: "can this new component reach back into my identity system?" The answer is three hard constraints:
- A dedicated read-only account — GenAuth accesses Human IAM through a separate least-privilege read-only account, isolated from any administrative credential.
- A fixed view — only pre-defined read-only views or read-only interfaces are granted; never full-database or full-directory access. API integration comes first, and direct database reads are considered only when your Human IAM offers no usable interface — and then still only through a fixed read-only view.
- Audited end to end — every read lands in the audit log: whose permissions were read, when, and for which delegation. All of it reviewable after the fact.
Writes? Not an option. GenAuth's access to Human IAM is architecturally one-way and read-only.
Answer 3: air-gapped offline mode
For physically isolated, zero-egress environments (air-gapped), the self-hosted model runs fully offline:
- Zero external runtime dependencies: consent, token issuance and exchange, signature verification (local JWKS), audit, and the console all close the loop inside the cluster, with no outbound connection required.
- Offline delivery and upgrades: component images and version upgrades are delivered as offline bundles, imported into your private registry, then rolled out.
- Full data residency: the self-hosted column of the matrix above holds automatically in air-gapped mode — with no outbound channel, there are no exceptions.
Be clear about the cost of air-gapped
Zero egress means giving up hosted-side automatic updates and remote support, so the timeliness of security patches is set by your offline upgrade cadence. Put the upgrade window into your operations plan instead of installing once and forgetting.
How to choose
| Your situation | Recommended model |
|---|---|
| Want the fastest path to a working setup, no data residency requirement | SaaS-hosted |
| Audit logs, delegation data, and credentials must stay in your own environment | Self-hosted same-domain sidecar |
| Want deep reuse of the identity and permission model in your existing Human IAM | Self-hosted same-domain sidecar |
| Physically isolated, zero egress | Self-hosted + air-gapped mode |
| Minimum operational effort | SaaS-hosted |
Zero code difference between models
The API and SDK are identical. Switching models changes exactly one thing: the host in SDK initialization goes from https://api.eak.eazo.ai to your in-cluster GenAuth address. Business code, scopes, and token handling stay exactly as they are.
Next steps
- The full business sequence for both models (7 hops vs 8 hops — the difference is ⑧) → End-to-end sequence
- The most common first step for self-hosted: onboarding without touching your current IdP → Connect your existing identity stack
- How OIDC and OAuth scopes connect to your existing identity stack → Integration principles