Ekam blog · 30 June 2026
Why India needs its own agent-identity control plane
Every wave of computing got the identity layer it deserved, eventually. The web got OAuth and SAML. The cloud got IAM. Mobile got device identity and passkeys. The agent era — software that acts on its own, calls tools, spends money, and reads data on your behalf — is arriving without one. We built Ekam to close that gap, and to close it from India.
The problem: agents are first-class actors with third-class identity
An AI agent today is, almost universally, a long-lived API key in an environment variable. That key is unscoped (it can do everything its owner can), unattributable (logs show "the key", not which agent acting for which human), un-revocable in practice (rotating a shared key breaks every workload, so nobody does it fast), and over-trusted (it sits in plaintext, gets copied into prompts and CI logs, and never expires).
This was manageable when a handful of services held keys. It is not when thousands of autonomous agents — many spun up by other agents — each need credentials. Industry measurements now put non-human identities (NHIs) far ahead of human ones: Rubrik Zero Labs reports machine identities outnumber humans roughly 45-to-1 in the typical enterprise (and far higher in some), CyberArk puts it above 80-to-1, and NHIs grew ~44% in a single year. You cannot run that world on shared secrets.
What "reliable AI" actually requires
Reliability isn't just a better model. A system you can trust to act for you needs four properties that have nothing to do with weights and everything to do with identity:
- Least privilege — exactly the scope needed, bound to exactly the one resource it may call, for exactly as long as the task takes (minutes, not months).
- Attribution — an unforgeable chain: this agent, owned by this account, acting for this human.
- Instant containment — a kill-switch that stops a misbehaving or compromised agent everywhere in seconds.
- Accountability under the law — answer "what did this automated system do with my data?" and honour erasure across everything acting on a person's behalf.
Ekam delivers these as primitives. Agents are first-class, owned, blueprinted identities — not keys. Every token is a short-lived, audience-bound (RFC 8707), scope-attenuated ES256 JWT carrying a delegation chain (RFC 8693), verified offline against a JWKS so your gateway never calls us on the hot path. Revocation is a real kill-switch backed by a CAEP push so subscribed gateways evict a token the instant you pull it. Above every account and agent sits one canonical Person, so a data-subject request reaches a human's whole footprint.
How it fits together
The architecture is deliberately small and standards-shaped:
Human (SSO: Google / OIDC / SAML / GitHub) External agent issuers
| type:human token (Entra Agent ID / OpenAI /
v Anthropic WIF) ---+ RFC 8693
+--------------+ owns +---------+ mints +----------+ |
| Owner / W.S. |---------->| Agent |--------->| Ekam |<--------+
+--------------+ blueprint +---------+ broker | AS |
^ canonical Person (DPDP) +----+-----+
| short-lived ES256 JWT (act chain)
| v
+----+-------+ verify offline (JWKS) +---------------+
| Kill-switch|<---- CAEP/SSF push ----------->| your gateway |--> model / API / MCP
| + revoke | introspection (live) | (no hot-path call to Ekam)
+------------+ +---------------+It runs on Krutrim Cloud across Hyderabad (primary) + Bengaluru (DR) with streaming Postgres replication, and it's built on the same lean stack as a modern gateway (TypeScript, Fastify, jose for ES256/JWKS). A deeper walk-through — and the measured numbers — is in How offline token verification works.
Performance: security that doesn't cost latency
The whole design keeps Ekam off the request hot path. The expensive thing — verifying a token — happens in your gateway, against a cached JWKS. Measured on a single Node 23 process on a dev laptop: ~18,000 verifications/sec per core, p50 ~0.05 ms, p99 < 0.1 ms, with compact ~640-byte tokens. Brokering a fresh token is a ~20 ms HTTP round-trip — a one-time setup cost per task, not per inference call. (Methodology in the verification post.)
Why this has to be India's to own
The incumbents are real and good — Microsoft Entra Agent ID, Okta's Cross-App Access, and AWS Bedrock AgentCore Identity (GA October 2025). They are also entirely outside Indian jurisdiction, priced in dollars, and built around US/EU regimes. For Indian companies, governments, and the public-sector AI on Indian compute, that's three problems at once:
- Sovereignty. The plane that decides who may act and who may spend is the most sensitive system in an AI stack. Hosting it offshore for India's critical AI is a dependency we don't need to accept.
- The DPDP Act. India's Digital Personal Data Protection Act, 2023 gives people access, correction, and erasure rights that are impossible to honour if you can't link a person to every account and agent that touched their data. Ekam is built around that linkage — the Person-above-Account model is the foundation, and the delegation chain makes purpose and attribution provable end to end.
- Economics. Identity priced per-user in USD taxes every Indian deployment. Internally, this model proved roughly 85–90% cheaper than a per-seat IdP. INR pricing removes a real barrier.
This is the UPI/ONDC logic: when the rails matter, India builds its own — open, standards-based, under our own law — rather than renting them.
Standards-based, not proprietary
Owning the rail doesn't mean reinventing it. Ekam is assembled on the standards the ecosystem is converging on — OAuth 2.1, OIDC, RFC 8693 token-exchange, 8707 audience binding, 9728 protected-resource metadata, 7662 introspection, SCIM 2.0, CAEP / Shared Signals, and the MCP authorization profile — and it builds on workload-identity primitives like SPIFFE/SPIRE, aligned with NIST SP 800-207 zero-trust. Bring your own IdP for humans and your own policy engine (groot, OPA, OpenFGA, Cerbos) for authorization. Ekam is the control plane above the standards, not a walled garden.
The loop that makes it real
Identity is only useful when it closes a loop. An agent is provisioned in Ekam → it brokers a short-lived, scoped token → your gateway verifies it offline and maps it to a budget → it meters usage and attributes it to the owner → and at any moment you can revoke the agent and stop it cold. Identity, inference, and accountability become one governed loop, with attribution intact from the human at the root to the byte that was read.
It's open beta — and it's human-rooted
Ekam is now in open beta: sign in with any Google account, create a workspace (we set up a Personal and a Team one for you), and mint agents in minutes. Every agent is owned by a human — there is no anonymous agent signup, because an agent that bootstraps its own identity from nothing is exactly the unaccountable, shared-credential pattern we're ending. Usage is metered; billing is off during beta; requests are rate-limited with a standard 429 + Retry-After above generous per-principal limits.
India is building world-class models and the compute to run them. The missing piece is the trust layer. That's what Ekam is for.
Start free in the open beta 10 things to build this week Read the docs