Two touchpoints
You integrate on one or both sides, depending on what you build.| Side | What you add | Rough effort |
|---|---|---|
| Agent | The Python SDK, in place of requests | Minutes — a one-line swap |
| Platform / API | The middleware + a scopes file | An afternoon — two lines of setup, plus mapping routes to scopes |
What the agent side looks like
Your agent already makes HTTP calls. You swap the HTTP client for MudraID’s, which is a drop-in replacement. Every call your agent makes is then authenticated automatically — tokens are fetched, attached, and refreshed for you. There’s no per-API integration. Once your agent has an identity and the scopes it needs, it can call any platform that trusts MudraID.What the platform side looks like
You add the middleware to your web app and point it at a scopes file that maps each route to the permission it requires. From then on, the middleware checks every request before it reaches your code. Your existing route handlers don’t change — no auth code sprinkled through them. Defining scopes is the main design step: decide what permissions your API exposes (for exampleorders:read, orders:write) and which routes need each.
A typical rollout
- Register your agent or platform with MudraID.
- Grant scopes — decide what each agent may do, or what your platform’s routes require.
- Integrate — add the SDK or the middleware.
- Verify — run a test call end to end and confirm allowed calls pass and denied calls fail.
- Go live — roll it out to production traffic.
What your team owns
- The agent’s credentials (stored as secrets in your environment), or your platform’s scope definitions.
- The decision of which agents get which permissions.
What MudraID owns
- Issuing identities and tokens, publishing and rotating the keys your middleware verifies against, processing revocations, and keeping the audit trail.