Every AI agent in your organization access data as if they are a person. When an agent accesses a CRM, sends an email, or queries a database through MCP, it does so as the human who configured it. That means there's no way to tell agent actions from human actions in your audit logs, no way to scope an agent's access independently, and credential bleed when multiple agents share the same user's tokens.

Today we're launching agent identities for the MintMCP gateway, so enterprises can give each agent its own identity with explicitly delegated permissions across services.

The identity problem

This gap starts when individual users are using MCP tools at their desks. It becomes a big pain point as soon as companies move to team-owned agents: bots running in Slack, scheduled jobs pulling reports, automated workflows triggered by events. There's no clean way to separate what an agent can access from what the person who set it up can access.

We hear the same thing from every enterprise we talk to. They gave hundreds of employees access to MCP tools and it worked great. Now they want to give access to autonomous agents that act like teammates, and the identity model breaks. A QA bot shouldn't have the same permissions as a deal-management agent, and both should be clearly distinguishable from human users in audit logs.

Agent identities fix this by treating each agent as its own principal: separate identity, scoped permissions, and a dedicated audit trail, while the delegating user retains clear ownership of what the agent can do.

How it works: agent bundles

Agent identities ship as agent bundles in the MintMCP gateway. A bundle packages multiple tool connections under a single agent identity, with a specific credential bound to each connection. So an agent can access Outlook under one person's delegation, a CRM under another's, and a code repository under a team service account, all governed as one auditable identity.

When creating an agent bundle, you select the agent-identity MCP type, which binds all connectors to the agent rather than to individual users:

Each connection within the bundle gets its own delegated credential. Here, a single agent has GitHub access via one team member and Linear access via another, each with their own OAuth grant:

Here's what this looks like in practice:

• Dedicated authentication: each agent authenticates to the MintMCP gateway via its own token, so agents never handle raw credentials directly
• Per-connection permissions: permissions are delegated within the bundle. One agent can read CRM records and draft emails, another can search LinkedIn and create notes, a third can only read
• Shared administration: authorized team members share administration of the bundle through a secure sharing model, so credentials and tool access can be managed jointly without exposing secrets
• Agent-level audit trail: every tool call is logged against the agent's identity, which means audit trails show which agent took which action, under whose delegation, at what time
• Single-operation revocation: revoking an agent's access or rotating its credentials is one operation with no impact on other agents or users

Why this matters for enterprises

The underlying challenge is that IAM was designed for humans and static services. Agents are neither - they're stateful, reasoning entities that act as proxy identities on behalf of users, but with their own logic layer. As organizations deploy more agents, they need a new class of identity governance to do it with confidence.

"IAM was designed for humans and static services. Agents are neither. They're stateful, reasoning entities that act as proxy identities on behalf of users, but with their own logic layer. Enterprises need a new class of identity governance to deploy them with confidence."

Tas Jalali, Cybersecurity Executive and AI Governance Leader

Without agent identities, companies face a hard choice: let agents operate under human credentials (breaking auditability and least-privilege) or don't deploy agents at all (losing the productivity gains). Agent bundles give a third path: full agent autonomy with clear boundaries.

Once every agent has its own identity, you get a clear picture of what's happening across your stack. That visibility is what lets you deploy the next ten agents with confidence, because you can see exactly what each one is doing, scope its access to what it actually needs, and revoke it in one step if something goes wrong.

"Once every agent has its own identity, you get a clear picture of what's happening across your stack. That visibility is what lets you deploy the next ten agents with confidence."

Brian Shultz, Co-founder and CTO at Tango

Get started

Agent identities are available now in the MintMCP gateway. To set up your first agent bundle, see the agent identities documentation.

If you're already using MintMCP, agent bundles work alongside your existing connectors and access policies. If you're evaluating MintMCP, get in touch and we can walk through how agent identities fit your setup.