Skip to main content
MudraID sits between an agent and the platform it calls. The agent proves who it is and gets a short-lived token for one resource. The platform verifies that token — and, for sensitive actions, asks MudraID whether this exact action may proceed — before serving the request. You never build any of this yourself. You add a small library on whichever side you’re on, and MudraID handles the rest.

​
The request path

​
The action-control loop

​
1. Authority — who is acting, under whose authority?

An agent is registered once as an identity, and an OAuth machine client is linked to it. The client authenticates with a key you hold (private_key_jwt); MudraID never sees the private key. A resource grant approves exactly which resource and scopes the client may use, and the agent has an accountable owner. Linking a client grants nothing on its own. The SDK exchanges a signed client assertion for an access token that expires in five minutes by default and is bound to one resource. The token rides along on the agent’s request; the private key never leaves your environment.

​
2. Decision — should this exact action be allowed right now?

There are two ways a platform checks a request:
  • Offline verification. The middleware checks the token’s signature, issuer, audience, timing and the route’s scope locally, against MudraID’s published keys — no per-request call to MudraID.
  • Live enforcement. An enforcement adapter calls MudraID’s /decide for each protected action. MudraID evaluates a fixed gate order — request contract, identity and tenant, authority and delegation, containment, risk, commercial entitlement, governance policy — and answers allow, deny or not_safely_decided. It is deny-closed: a missing, stale or unavailable fact, or a timeout, is never an allow. An allow authorizes one forward of the request, and can be bound to the exact request bytes the adapter will send.

​
3. Containment — stop it without breaking everyone else

Containment escalates in steps: quarantine (reversible) first, then suspension (can still be lifted), then revocation (terminal). A permanent step is accepted only once a reversible quarantine is in place. Operator actions go through request-and-approve, and a requester cannot approve their own request. MudraID’s own services may suspend at once; a revocation they initiate waits for a human to approve it. Live-enforcement adapters receive containment as a signed feed and acknowledge what they applied.

​
4. Proof — show what happened

Every token issuance, every failed authentication and every /decide outcome is recorded in tamper-evident, hash-chained logs. Decision evidence is chained per organization and environment over payload digests, so redacting a payload does not break the chain. Offline verification happens inside your middleware, so MudraID does not see or record it. You can generate a signed Production Proof bundle and give a reviewer a revocable share link; the reviewer verifies the bundle offline against MudraID’s published proof-signing keys.

​
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.

​
Why the design holds up

  • Keys stay put. The client’s private key signs a one-time assertion; it is never sent to MudraID or to the platforms the agent calls.
  • Tokens are short-lived. A leaked token is only useful for minutes, only at one resource, and the client behind it can be contained.
  • Verification can be local. Platforms that verify offline make no per-call round trip to MudraID.
  • Decisions fail closed. Under live enforcement, anything MudraID cannot decide safely is refused.

​
Next