AI agent governance infrastructure
for autonomous software
The decision
Every agent request meets a gate
Identity, then delegated scope, then policy — and a human when the action warrants one. Allowed, held, or denied, and every outcome is audited.
- allowed
- held for human approval
- denied
None of this is a mock-up of an intention. Parked writes, approvals that are fingerprint-bound and single-use, and a kill switch that severs a live session at the transport all run in production today.
- OIDC discovery live
- RS256 + JWKS
- PKCE S256 required
- cosign-verified images
- Postgres row-level security
- hash-chained audit log
AI-agent-native
Identity that governs autonomous agents
Agents are first-class principals — issued identities, delegated authority, and enforcement at the moment they act, not just when they are configured.
- 01
Issue an identity
Every agent gets its own cryptographic credential and a risk profile that scales how much oversight it attracts. It is never a shared service account wearing a human's badge.
- 02
Bound the delegation
Authority flows from the human the agent acts for, and it can only ever tighten — never widen. A fail-closed gateway checks allowlist, delegation scope, and rate and budget caps on every tool call.
- 03
Keep a hand on the switch
Sensitive actions park for real-time human approval, fingerprint-bound and single-use. A separately-permissioned kill switch severs an agent mid-session, at the transport, without waiting for it to finish.
Priya Raman
delegating principal
billing-reconciler
3 live sessions · invoices:read
MCP tool calls
gateway open · 4 tools allowlisted
Delegation valid. Writes park for approval; reads flow.
The platform
One IAM control plane, every identity
Standards-native authentication and authorization for your workforce, your customers, and the machines in between — multi-tenant down to the row.
Issuer
https://auth.zynthmedia.comDiscovery document https://auth.zynthmedia.com/.well-known/openid-configuration — your OIDC library derives this from the issuer, so configure the issuer, not this URL.
ID tokens carry that issuer as iss. The platform’s own API access tokens are a separate credential and carry zynth-auth instead — verify each against its own issuer.
OpenID Provider
A certified-shape OIDC issuer: discovery, /authorize with mandatory PKCE, /token, JWKS, /userinfo, logout. Point any OIDC library at the issuer — integration in minutes, not a project.
Workforce & customer IAM
Federation over SAML and OIDC, SCIM provisioning, passkeys, TOTP, magic links, social login, and a fail-closed RBAC plus ABAC engine — one surface for employees and end-users alike.
Multi-tenant by construction
Postgres row-level security beneath an always-scoped repository layer, so the tenant boundary is a database property rather than a hand-written query you have to trust.
Security embedded
Hardened by default, evidenced for buyers
The controls a regulated buyer asks about on first contact are built in — and the supply chain that produces the platform is signed end to end.
Fail-closed everywhere
A missing key, unreachable dependency, or ambiguous authorization results in denial rather than insecure degradation. Argon2id hashing, breached-password screening, RS256 + JWKS, strict CORS.
Signed, digest-pinned supply chain
Images are built in CI and signed keyless. The server never builds — it verifies every signature and deploys the exact verified digests, aborting on any failure. Containers run non-root behind an egress allowlist.
Continuous compliance
Every action must emit telemetry, carry a detection decision, carry an audit decision, and map to a compliance control — enforced in CI, so evidence is produced by construction rather than assembled before an audit.
Assurance
Evidence produced by construction
Most platforms assemble their evidence in the weeks before a review. This one cannot ship a change that would leave a gap in it.
240+ registered actions
Every action the platform can take is declared, and each one must carry telemetry, a detection decision, an audit decision, and a control mapping — or an explicitly recorded exemption with a reason.
CI enforces it
That requirement is a build gate rather than a policy document. Code that skips the evidence does not merge, so observability and audit coverage cannot silently rot between reviews.
40+ control identifiers
Actions map onto a control catalogue covering access, monitoring, change management, privacy, and AI oversight — so the record is organised the way a reviewer reads it.
We hold no third-party attestation today and will not imply otherwise with a badge. The Trust Centre states exactly what is enforced — and which parts you can verify yourself.
Two ways to run it
One codebase. Managed or self-hosted.
The same platform and the same standards surface, delivered the way your organization needs. Move between them without re-integrating.
Managed cloud
We run it. You ship in minutes.
- Self-serve signup — opens after the private beta
- Pooled tenancy, isolated twice — a scoped data layer and Postgres row-level security
- Automatic updates & signed releases
- Usage-based billing once plans are published — no infrastructure to run
Sign-ups open after the private beta — accounts are created by invitation for now.
Self-hosted
Your infrastructure. Your data residency. Built today — licences open after the private beta.
- The reference deployment is the artifact — Docker Compose
- Air-gap-friendly, full data control, offline bundle of cosign-signed images
- Cosign-verified, digest-pinned images
- Licensed with enterprise support & backports
FAQ
Frequently asked questions
Is Zynth Auth an OpenID Provider?
Yes. Zynth Auth is an OpenID Provider (OIDC): it exposes discovery, authorization, token, and JWKS endpoints, so you point your existing OIDC library at the issuer instead of writing custom verification code.
Can I self-host Zynth Auth?
The software is built today: every version tag builds an offline bundle of cosign-signed images, and the reference deployment is that artifact — Docker Compose, cosign-verified, digest-pinned images that verify without calling home. What the private beta gates is the licence, not the capability, so there is nothing to buy yet. Your tier is a configuration and entitlement, not a different product.
How does Zynth Auth handle AI agents?
Agents are first-class identities with tighten-never-weaken delegation from the human they act for, a fail-closed MCP per-call authorization gateway, human-in-the-loop approvals for sensitive actions, and a separately-permissioned kill switch.
How are tenants isolated?
Multi-tenancy is enforced at the database with Postgres row-level security and a scoped repository layer, so the tenant boundary is a database property rather than a query you have to trust.
Are you certified, and how do you handle audit evidence?
We hold no third-party attestation today and will not imply one with a badge. What runs instead is mechanical: more than 240 registered actions each must carry telemetry, a detection decision, an audit decision, and a control mapping before the code can merge, and the resulting record is hash-chained and tamper-evident. Independent assessment is on the roadmap. The Trust Centre states exactly what is enforced and which parts you can verify yourself.
Where is data hosted?
The managed offering is hosted in Singapore (APAC region) for data residency and sovereignty. Self-hosted deployments keep all data within your own infrastructure.
Documentation that cannot go stale
Most platforms document what they meant to build. Ours fails its own build when the docs stop matching the code: a module that is not described in the architecture page breaks CI, and an engineering rule that claims an enforcement which does not exist breaks CI too. What you read is what is deployed.
- 40
- published product pages
- guides, concepts and reference
- 48
- documented endpoints
- every endpoint, every refusal
- 115
- architecture decisions
- why, not just what
- 30
- guard-backed engineering rules
- each one wired to a CI guard