Identity, with respect.
NamoID authenticates the people who use your product and gives the AI clients they approve a separate access boundary. We build on open standards, operate from India, and label the difference between available software and future work.
Why we’re building it
Customer login and AI-client permission should share an identity model—not a session.
A growing product authenticates customers and increasingly lets AI clients reach tools and data on their behalf. Those clients should receive their own resource, scope, expiry, grant, and revocation boundary—not inherit the user’s whole session. Customer Identity and MCP Authorization are available now. Workforce Identity and broader Agent Access remain in-development directions. India is our operating context; DPDP readiness is engineering work, not a badge.
What we believe
Store less identity data
Identity data is minimised, provider tokens are encrypted at rest with AES-256-GCM, and governed actions create privacy-conscious audit evidence.
Use the standards your stack already knows
Read OpenID Connect discovery from one environment issuer and validate signed tokens through its public JWKS. Use PKCE and WebAuthn without learning a proprietary protocol.
Deep where it matters
Customer authentication and MCP resource authorization today, with clearly labelled Workforce and Agent Access directions.
Built by a small team in India.
Customer Identity, MCP Authorization and Agent Access are available now. We work directly with the teams building on them, and with design partners shaping Workforce Identity.