Know who is asking, and what they may do.
Status: In build
IAM is the identity and access foundation every other product builds on.
Every product asks the same two questions.
One identity, one policy answer, one place to audit both.
Read the full project overview
This is an experiment on the layer: IAM answers two questions for every product: who is making a request, and whether they are allowed. Every other promise on this site depends on those answers being consistent, portable, and auditable.
What it is
IAM is one product with a small, stable surface:
An authentication engine. One identity serves the entire platform: people, services, and devices, through standard OIDC.
An authorization engine. One policy service, one policy structure, with each consuming product contributing policies in its own namespace.
Operators. Small IAM-owned controllers that keep identity and policy state in sync with declarative source.
Contracts. The issuer, the policy endpoint, the token claims, and the resource and action vocabulary that consumers depend on.
Why identity is its own product
Identity infrastructure attached to no product's vision drifts, and identity infrastructure owned by one product quietly makes that product the platform. Both fail the ecosystem principle.
Three reasons IAM stands alone:
Naming reflects intent. A named product creates the place where identity-shaped decisions belong.
The dependency graph becomes honest. When IAM is a peer of One, Cortex, and the other siblings, the diagram matches the runtime.
The plumbing and the product split cleanly. The user-facing management experience lives in One; the engines live in IAM. Each side can evolve without capturing the other.
The three contracts
Authentication
Standard OIDC discovery, token issuance, and user info; service-account tokens for machine identities; certificate flows for device identities.
Authorization
One policy evaluation endpoint; one resource and action vocabulary per consumer, namespaced by consumer; policies reviewed and versioned like code.
Management
The user, organization, and role management experience lives in One's Portal and calls IAM through a thin, stable adapter. Communities and operators interact with that experience; IAM itself never grows a second face.
Who it is for
Product owners of sibling products, who want one stable identity and policy contract to build against without depending on One.
Platform engineers, who want a single release surface for authentication and authorization when reasoning about blast radius, upgrades, and incidents.
Security and compliance reviewers, who want one place to audit identity configuration, policy evaluation, token lifetimes, and credential rotation.
What this enables
Every sibling product consumes the same issuer and the same policy endpoint, with its own policy namespace.
New identity types (devices, sites, agents) extend the shared realm without becoming any one product's private extension.
Workloads on Alpha authenticate with the same identity system humans use.
Agents acting for a community carry auditable identity from the same foundation, which is what makes governed automation possible.