Skip to main content
MudraID is a trust layer for AI agents. Before an agent’s action reaches your API, MudraID answers three questions: Who is acting? Under whose authority? Should this exact action be allowed right now? If you build AI agents, MudraID lets your agent prove who it is to the services it calls. If you run an API or platform, MudraID lets you accept calls from third-party agents safely — with per-agent permissions, a live decision for sensitive actions, and the ability to contain any agent without disturbing the others.

Why this matters

AI agents now take real actions. They book travel, move money, pull records, and call production APIs on a user’s behalf. But an API call from an agent looks like any other HTTP request. The service on the other end has no reliable way to tell a trusted agent from an impostor, or to know whose authority the agent is acting under. Most teams paper over this with shared API keys. Those keys are long-lived, hard to revoke, and grant the same broad access to everyone holding them. One leak exposes everything, and you can’t tell which agent did what.

The action-control loop

MudraID replaces that with four steps that run around every protected action:
  1. Authority. Each agent has its own identity and a linked OAuth client that holds a key you control. An approved grant names exactly which resource and scopes it may use, and an accountable human or organization stands behind it. Access tokens are short-lived and bound to one resource.
  2. Decision. For sensitive actions, an enforcement adapter asks MudraID’s /decide whether this exact request may proceed. The answer is allow, deny or not_safely_decided — and anything that cannot be decided safely is refused, never allowed.
  3. Containment. When something goes wrong, you quarantine first (reversible), then suspend or revoke. Containment reaches enforcement adapters as a signed feed.
  4. Proof. Every token issued and every decision made lands in a tamper-evident evidence chain, and you can export a signed proof bundle that a reviewer verifies offline.

What you get

  • Identity. Each agent has its own identity and client credential. No shared keys.
  • Short-lived tokens. Agents authenticate with tokens that expire in minutes — five by default — not standing secrets.
  • Scoped access. You decide exactly what each agent may do, per route or per action.
  • Fast revocation. Revoking a grant or suspending the client 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 and containment on each protected action. Either way there is no coordinated rotation to run, and no other caller is disturbed.
  • Audit and proof. Every token issuance, every failed authentication and every live-enforcement decision is logged in a tamper-evident chain.

The two sides of MudraID

MudraID sits between the agent and the platform it calls. You only touch one side, depending on what you’re building.
  • Building an agent? Add the Python SDK and a linked OAuth client. Your agent’s calls become authenticated automatically.
  • Running a platform or API? Add the middleware. Only trusted, in-scope agents reach your code — and, with live enforcement, each protected action gets its own decision.
MudraID runs everything in between — issuing identities and tokens, publishing verification keys, deciding protected actions, handling containment, and keeping the evidence. You don’t operate any of it.

Where to go next

The problem

Why agents need verifiable identity and action control.

How it works

The action-control loop, and what you own vs what MudraID runs.

Use cases

Where teams put MudraID to work.

Integration overview

What adopting MudraID actually takes.
If you’re ready to build, jump to the Agent quickstart or the Platform quickstart.