Ekam blog · 30 June 2026
How BharatRouter runs on Ekam: agent identity for an AI gateway
An AI gateway sits in front of every model call an organisation makes. The usual way to authenticate that traffic is a long-lived API key, shared across every agent, script and service. It works until you ask three questions: which agent made this call, who is responsible for it, and how do I switch off just one agent without rotating the key for everyone? BharatRouter — an India-first AI gateway — answers all three by putting Ekam in front as its agent-identity layer.
The shape of the integration
Nothing about the request path gets slower. An agent presents an Ekam-issued, audience-bound token instead of a shared key; BharatRouter verifies it offline and maps it to the right account. Three moving parts:
- Ekam mints a short-lived ES256 JWT for the agent, bound to the audience
https://api.bharatrouter.comand carrying the delegation chain back to a human owner. - BharatRouter verifies the signature against Ekam's published JWKS — no network call to Ekam on the hot path — and checks issuer, audience and expiry.
- BharatRouter maps the token's owner (
act.sub) to a billing org, enforces that org's budget and scopes, and meters the usage.
What the gateway actually checks
import { jwtVerify, createRemoteJWKSet } from "jose";
const JWKS = createRemoteJWKSet(new URL("https://ekam.olakrutrim.com/.well-known/jwks.json"));
const { payload } = await jwtVerify(token, JWKS, {
issuer: "https://ekam.olakrutrim.com",
audience: "https://api.bharatrouter.com", // RFC 8707 — a token for another gateway won't pass
});
// payload.act.sub -> the owner -> map to a BharatRouter org -> budget + metering
// payload.scope -> "models:invoke models:chat" -> enforce per routeThe JWKS is cached, so verification is local CPU work: tens of microseconds — about 18,000 verifications/second/core, p99 under 0.1 ms (measured on Ekam's reference hardware). Even under a model-gateway's request volume, identity adds no measurable latency.
What BharatRouter gains
- No more shared keys. Every agent carries its own short-lived, audience-bound credential. A leaked token expires in minutes and only works against BharatRouter.
- Attribution to a human. Each call traces
agent → owner → humanthrough the delegation chain — so usage, cost and audit logs point at a real, responsible person. That's also what DPDP-style accountability needs. - A real kill-switch. Revoke one agent in Ekam and BharatRouter sees it — via introspection or a pushed CAEP
session-revokedevent — and stops it in seconds. No mass key rotation, no collateral outage. - Safe rollout. BharatRouter turns the bridge on in meter-not-charge mode first: Ekam-authenticated traffic is measured and attributed, but not billed, until each org is funded. Identity ships before money moves.
- Stays up when identity blinks. Inference never calls Ekam at request time. With a per-org degraded policy, already-authenticated agents keep running offline if Ekam is briefly unreachable; stricter orgs can demand live revocation. Availability is a choice, not an accident.
- No lock-in. The whole thing is standards — OAuth 2.1, RFC 8693 token-exchange, RFC 8707 audience binding, RFC 7662 introspection, CAEP. BharatRouter could verify any conformant issuer; Ekam could front any conformant gateway.
Why it matters beyond one gateway
India is wiring agents into payments, logistics, support and government-facing workflows. "An agent did it" is not an acceptable audit answer when something goes wrong. The BharatRouter integration is a concrete proof of the pattern we think every Indian AI platform will need: the gateway decides what a request may do; Ekam decides who is making it and on whose authority. Clean separation, both sides standards-based, identity rooted in a human.
Build the same on your gateway
The verifier above is ~20 lines. Start from the verify recipe, read how offline verification works, and follow the docs. Any gateway, any language with a JOSE library.
Verify Ekam tokens How verification works For agents: llms-full.txt