Give every AI agent
an identity of its own
An agent on MintMCP gets its own token, with access delegated by the people and teams it works for and scoped to the individual tool. Rotate or revoke one agent without touching the rest.
Trusted by
IAM built for agents
MintMCP is the identity platform for the agent side: every managed agent acts through the gateway with a first-class agent ID, permissions delegated from the people it works for, and credentials it never holds, so it gets exactly the access it needs and nothing it doesn't.
How an agent gets access
Each agent is its own principal in the gateway: its own tools, credentials, status, and its own name on every log line. None of it is tied to whoever built it, so the agent keeps running when they move on.
Each connection runs as the user who triggered the agent, as a team credential, or as a service account you provision for the job. Nothing is inherited from whoever clicked create.
Raw credentials never reach the agent: it authenticates with short-lived tokens, so rotating a key touches one agent and nothing else.
Tools toggle on or off per agent, so an agent that reads the CRM gets read access and nothing else, tightened without touching it.
Fast to ship, safe to run
Live in four steps
Create a bundle, delegate the connections, issue the token, and the agent is live. Every step is also a call on the registry API, so you can script it.
Delegated per connection
An agent is a role. Each connection in its bundle runs as the user who triggered it, as a team credential, or as a service account set up for the job. The agent holds one token and never sees the secrets behind it.
Outlook - Delegated from the user who triggers it
Salesforce - Delegated from svc-sales-agent (service account)
GitHub - Delegated from sales-eng (team)
No orphaned agents
Bundles are co-administered and ownership transfers without rotating credentials, so an agent keeps working when the person who set it up changes teams or leaves. When one does need to go, revoking its token stops that agent and nothing else.
Every action under the agent's name
Tool calls, auth events, and credential changes land in the audit log attributed to the agent that made them, not to whoever configured it, so the trace answers who did what without guesswork.
Stop sharing credentials with your agents
Create your first agent bundle: delegate a connection, issue the token, and see the first call in the log.
Frequently asked questions
The agent's own account in the gateway: its own token, its own set of tools, and its own name in the audit log. Its access comes from the user who triggers it, a team credential, or a service account, and none of it belongs to whoever built the agent, so you can scope or revoke one agent without touching anyone else.
Any agent that speaks MCP. That includes managed agent frameworks such as Claude Tag, Anthropic Managed Agents, ChatGPT workspace agents, and OpenClaw, as well as agents you build yourself. Each one gets its own bundle and its own token.
An agent is a role, and each connection in its bundle names where that role's access comes from. A connection can run as the user who triggered the agent, so Outlook sees the person asking and applies their permissions; as a team credential; or as a service account an admin set up for the job. Nothing is inherited from the person who created the agent.
No. The credentials stay in the gateway. The agent gets a client secret, shown once at creation, and uses it to mint short-lived tokens. Rotating a key changes that one agent and nothing else.
The agent keeps running. Bundles have more than one admin, and ownership transfers without rotating any credentials, so disabling someone's account doesn't take their agents down with it.
Revoke its token. That agent stops and nothing else does. If the problem is one tool, toggle that tool off for the agent instead; scoping is enforced in the gateway, so there's nothing to redeploy.