Skip to main content
MudraID sits between an agent and the platform it calls. The agent proves who it is, gets a short-lived token, and the platform verifies that token on its own before serving the request. We call this the trust loop. You never build any of this yourself. You add a small library on whichever side you’re on, and MudraID handles the rest.

​
The trust loop

Step by step:
  1. The agent proves who it is. The SDK exchanges the agent’s credential for a short-lived token, signed by MudraID.
  2. The token rides along. The SDK attaches it to the agent’s outgoing request. The agent’s long-lived secret never leaves for the platform.
  3. The platform verifies it independently. The middleware checks the token’s signature and that it was issued for this platform — locally, without calling MudraID on every request.
  4. The platform checks scope. If the token carries the permission the route requires, the request reaches your code. Otherwise it’s rejected with a clear error.
  5. MudraID records the verification. Every check, pass or fail, is written to a tamper-evident log.

​
What you run vs what MudraID runs

This is the part that matters for planning. MudraID is a managed service — you don’t host or operate it. You integrate one small library and define your permissions. Everything else — issuing identities, signing and rotating keys, revoking agents, keeping the audit trail — is operated by MudraID.

​
Why the design holds up

  • Secrets stay put. An agent’s secret is exchanged for a token by the SDK; it’s never sent to the platforms the agent calls.
  • Tokens are short-lived. A leaked token is only useful for minutes, and the agent behind it can be revoked.
  • Verification is local and fast. Platforms verify tokens themselves using published keys, so there’s no per-call round trip to MudraID.
  • Tokens are bound to one platform. A token issued for one platform is rejected everywhere else.

​
Next