For decision-makers
What is MudraID, in one sentence?
A trust layer for AI agents that answers, before an action reaches your API: who is acting, under whose authority, and whether this exact action should be allowed.Do we have to run any MudraID infrastructure?
No. MudraID is a managed service. You add a small library on your side — the SDK if you build agents, the middleware if you run an API — and MudraID operates everything else (issuing identities and tokens, publishing keys, deciding protected actions, processing containment, keeping the audit log).What data does MudraID store?
Agent and platform identities, OAuth clients and their public keys (never your private keys), a one-way hash of any compatibility client secret (never the secret itself), which clients hold which grants on which resources, and the audit log of what passes through MudraID — token issuance, failed authentications, and live-enforcement decisions. Offline verification runs inside your own middleware, so it is not reported back or recorded there. MudraID does not store your secrets in plaintext, and under offline verification it is not in the path of your business data. Under live enforcement, an adapter sends/decide the action, the caller’s access token and request metadata — and, only when the signed action declares request conditions, the bounded request body and its digest. See Trust & security.
How long does integration take?
The agent side is registering a linked OAuth client and swapping your HTTP client for the SDK’sMachineAgent — under an hour once the grant is approved. The platform side is adding the middleware plus mapping your routes to scopes — typically an afternoon, with scope design being the part worth thinking through. See the Integration overview.
What languages and frameworks are supported?
Today: a Python agent SDK, and middleware for FastAPI and Starlette (route-scope enforcement, plus a V2 mode for MCP servers). For live enforcement there are also a Node adapter and sidecar (alpha) and a Kong plugin (prerelease, not yet published). Any OAuth 2.0 client can obtain tokens from/oauth2/token directly.
What happens if MudraID is unavailable?
Platforms verifying offline use keys they’ve already cached, so verification doesn’t make a per-request call to MudraID — already-issued tokens keep being accepted. New token minting does go through MudraID, so a sustained outage would eventually prevent agents from getting fresh tokens. Tokens are short-lived by design, so this is a real dependency to weigh, not a hidden one. Under live enforcement, an action that can’t reach/decide is refused, never allowed.
Is there vendor lock-in?
The integration is a thin shim, and the wire format is standard (OAuth 2.0 client credentials, RFC 9068 access tokens verified against a published key set). Removing MudraID means removing a library and a config file, not unwinding a deep coupling.How is this different from API keys or an API gateway?
A shared API key is long-lived, over-privileged, anonymous, and painful to revoke. MudraID gives each agent its own identity, short-lived scoped tokens, per-agent attribution, and per-agent revocation that needs no coordinated key rotation — the things a static key can’t. See The problem.For developers
Do I have to rewrite my agent to use MudraID?
No. The SDK’sMachineAgent has requests-style methods and returns requests.Response objects — swap requests.get for agent.get, after configuring the linked client.
Do I have to add auth code to every route on my platform?
No. The middleware enforces scopes from a YAML file. Your route handlers don’t change, and there are no decorators.What happens when MudraID rotates its signing key?
Nothing on your end. The middleware sees a token signed by an unknown key, fetches the latest keys, and verifies. No restart, no config change. See Survive key rotation.My agent’s token expired mid-request. What happens?
The SDK refreshes the token and retries where that is safe. Requests with uncertain outcomes — aPOST or PATCH without an idempotency key the server deduplicates — are not blindly replayed; reconcile them first. See Handle errors.
Why isn’t items:write enough to read items?
Scopes are flat — there’s no hierarchy. If a route needs both read and write, the agent must be granted both. It’s deliberate, and it removes a class of accidental over-permissioning.
A route returns 404 but I know it exists. Why?
It either has no rule inmudraid_scopes.yaml or is marked skip: true. Both return 404, and a hidden route is indistinguishable from a missing one on purpose. Add a rule for the route.
I changed the scopes file but nothing changed. Why?
The middleware reads the YAML once, at startup. Redeploy or restart to pick up changes — there’s no hot-reload. See Manage the scopes lifecycle.Can I see my client secret again?
No. MudraID stores only a one-way hash and shows a new secret exactly once. If you’ve lost it, rotate for a new one — or move the client toprivate_key_jwt, where MudraID never holds the private key at all. See Rotate client keys and secrets.
Where did the api_key_id and agent secret go?
Native agent credentials are retired; their endpoints return 410 Gone. Agents now authenticate through a linked OAuth machine client. See the agent quickstart.