Your agents should not be carrying API keys
An API key is a long-lived shared password. That's fine for one human with one key. It falls apart the moment your callers are agents — spun up and torn down constantly, dozens at a time, each acting on someone's behalf. BharatRouter now lets an agent authenticate to inference with a verifiable, short-lived identity instead — and bills the right organisation for every call.
The problem with keys, specifically
Hand an agent an API key and you've handed it a durable secret. Here's what that costs you, line by line — and what an identity gives back:
| With a static API key | With an agent identity |
|---|---|
| A long-lived secret — one leak is a persistent breach | Minutes-long token, auto-expires; nothing durable to steal |
| Says "some org" and nothing else | Carries who (the agent), acts-for (its owner), scope, and expiry |
| Can't express "acting on behalf of" | Delegated / autonomous / hybrid semantics are first-class |
| Revocation is one key at a time, by hand | Kill the identity once → every live token dies cluster-wide |
| Per-agent attribution needs a key per agent | Every call is attributed to the agent automatically |
That last row is the quiet one that matters at the end of the month: spend, rate limits and budgets resolve to this agent acting for this org — not to one shared key you can no longer tell apart.
What it looks like
The identity is issued by Ekam, Krutrim's agent-identity control plane, as a signed ES256 token. BharatRouter verifies it offline against Ekam's public keys, maps the owner to your organisation, enforces your scope and budget, meters it, and bills it. Identity → inference → billing, one trust chain. You create an agent:
# Once: create an agent identity for your org.
# BharatRouter provisions the underlying Ekam identity for you —
# you don't stand up an identity server.
curl -X POST https://api.bharatrouter.com/me/agents \
-H 'content-type: application/json' --cookie "$SESSION" \
-d '{ "name": "nightly-reconciler" }'
# → { "id": "agt_7f3…", "name": "nightly-reconciler", "status": "active" }…and it authenticates with a fresh token each run — no key sitting in an env var:
# Per run: the agent mints a fresh, minutes-long identity token…
TOKEN=$(curl -s -X POST \
https://api.bharatrouter.com/me/agents/agt_7f3.../token \
--cookie "$SESSION" | jq -r .access_token)
# …then calls inference with it — no static key anywhere.
curl https://api.bharatrouter.com/v1/messages \
-H "Authorization: Bearer $TOKEN" \
-d '{ "model": "krutrim-2", "messages": [ ... ] }'Two ways to adopt it — and the default is zero-setup
Embedded (the default). You don't run an identity server. When you create an agent in BharatRouter, we provision the underlying Ekam identity behind the scenes and broker its tokens. You get short-lived credentials, central revocation and per-agent attribution out of the box — there's nothing else to stand up. Start at the Agents page.
Bring your own Ekam (for teams that already run one). If your fleet already has Ekam identities, register your Ekam as a trusted issuer and map your owners to your org. Your existing agents are then accepted at BharatRouter with zero new secrets — you reuse the identities you already have, and revocation stays in one place.
Either way it's the same surface for humans and for agents: every action on the console is also a JSON API and an MCP tool, so an orchestrator provisions and revokes agents programmatically with the identical config. Money actions stay human-only.
Why this is the India-native answer
Agent identity, inference and billing are usually three vendors and three integrations. Here they're one chain you can actually reason about: a Krutrim-issued identity, an India-resident gateway, and an INR ledger that attributes every token to the agent that spent it. When an auditor asks "which agent made this call, acting for whom, and who paid" — that's a query, not an archaeology project.
Keys aren't going anywhere for humans and quick scripts. But for an autonomous fleet, an identity is simply the right primitive — short-lived, attributable, revocable. Give your agents one.
Try it: Create an agent → · Already run Ekam? Bring your own issuer · API reference