How credentials are protected
Your private key never leaves your environment
Your agent authenticates through a linked OAuth client usingprivate_key_jwt: you register only the public key and prove you hold the private one. MudraID never receives or stores the private key. Each client assertion it signs is short-lived, names the exact token endpoint, and is single-use — a replayed assertion is refused.
Where a client uses a compatibility client secret instead, you receive it exactly once and MudraID stores only a one-way hash — never the secret itself. In production that method needs an explicit organization approval. A stolen copy of the MudraID database does not hand anyone a usable credential.
Credentials never travel to the platforms you call
The SDK exchanges the client’s credential for a short-lived access token, and only the token is sent onward. The services your agent calls never see the private key or secret. The architecture keeps the two strictly separate, so a credential can’t leak onto an outbound request.Tokens are short-lived and verified independently
Agents authenticate with tokens that expire in minutes, not with standing secrets. Tokens are cryptographically signed by MudraID, and each platform can verify them locally using published keys — no per-request callback to a central server. A token is bound to one resource and rejected at any other.Comparisons are constant-time
Every credential and token check uses constant-time comparison, so an attacker can’t learn a secret by measuring how long a check takes.How you stay in control
Least-privilege scopes
Each client gets an approved grant for one resource and only the scopes it needs, and platforms map each route to a scope. There’s no implicit escalation — holding one permission never silently grants another. An agent can do exactly what it was granted, and nothing more.Fast revocation
Revoking a grant, suspending a client or retiring its key prevents new access tokens from being issued. A token already issued may remain usable by a surface validating it offline until it expires—five minutes by default and never longer than the configured fifteen-minute ceiling. Integrations using live enforcement consult current authority on each protected action. When you are planning containment, that difference is the number to plan against: under offline verification the residual window is the remaining life of tokens already issued, and it is bounded by the token lifetime. See Rotate client keys and secrets.Live decisions and staged containment
Platforms that need a decision per action put an enforcement adapter in front of it. MudraID’s/decide checks the token, current authority and delegation, containment, risk, entitlement and policy in a fixed order, and fails closed: anything it cannot decide safely is refused. Containment escalates from a reversible quarantine to suspension to terminal revocation; a requester cannot approve their own containment request, and a revocation MudraID’s own services initiate waits for a human to approve it.
Tamper-evident audit
Every token issuance and every failed authentication against your credentials is recorded in an append-only, tamper-evident log, as is every live-enforcement decision. Offline verification runs inside your own middleware and is not reported back, so that record lives in your logs rather than MudraID’s. If you need to prove which agent was issued what, and when, the record is there — and you can export a signed Production Proof bundle that a reviewer verifies offline, shared through a link you can revoke.What MudraID stores — and what it doesn’t
Knowing where your data lives matters for due diligence. In plain terms: MudraID stores:- Agent and platform identities, and their metadata.
- 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.
- The audit log of token issuance, failed authentications and live-enforcement decisions.
- Your private keys, or client secrets in plaintext.
- The response payloads your agent receives from platforms. Under offline verification MudraID is not in the path of your business data at all. Under live enforcement an adapter sends
/decidethe 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.