Give every AI agent its own identity, with open-source parts

Most teams start with agents that borrow a person's API key. That works until someone asks which agent deleted a record, or how to stop one agent without breaking the rest. A new category of product answers those questions. Mintive, which was called MintMCP until recently, is one example (Mintive).

Mintive is a hosted commercial product. Its public GitHub organization holds MCP servers, plugins and hooks, but no gateway code (GitHub). This article takes its parts apart and rebuilds each one from open-source projects. The center of the build is agent identity. Everything else depends on it.

What the product does

Mintive's site lists five parts (Mintive):

• An MCP gateway that decides which tool servers each team can reach.
• An LLM gateway with allowed models and budgets per team.
• Agent identities, so each agent is its own principal in the gateway.
• An agent monitor that traces calls and screens them for prompt injection, secrets and personal data.
• Slack and Teams agents with long-term memory.

The first four parts form one system. The fifth is an application built on top of it, and this teardown leaves it out.

Four questions every agent call must answer

Each part of the stack answers one question about a single agent call. Use the four questions to check any design, bought or built:

1. Who is calling? The agent has its own identity, and the call names the person it acts for, if any.
2. What may it reach? A gateway allows or denies each tool, based on that identity.
3. What may it spend? A key with its own model list and budget limits each agent.
4. What did it do? Every call leaves a trace that names the agent and the person.

A design that cannot answer the first question cannot answer the other three. A shared key makes every agent look like the same caller.

Who is calling: one principal per agent

Mintive describes three ways a connection can run: as the user who triggered it, with a team credential, or as a service account (Mintive). You can build all three with Keycloak, an open-source identity server.

• Service account. Register each agent as its own Keycloak client. Every client has a built-in service account, which gets tokens through the client credentials grant (Keycloak).
• Acting for a user. OAuth token exchange, RFC 8693, takes two tokens. The subject token is the person the request is for. The actor token is the agent doing the work (RFC 8693).
• Team credential. Give the team its own client, and record which agent used it in every trace.

The exchanged token carries an act claim, which records that delegation took place. The agent keeps its own identity, so this is delegation, not impersonation (RFC 8693). Check your Keycloak version first. Standard token exchange is fully supported in current releases, but delegation with an actor token and the act claim is still a preview feature, off by default (Keycloak).

Keycloak says what an agent may do. SPIFFE proves which process is running. SPIRE, its reference server, checks the host and the workload, then issues short-lived identity documents called SVIDs. They come as X.509 certificates or as JWTs, and SPIFFE advises certificates where possible because a JWT can be replayed (SPIFFE). Use SPIFFE when agents run as many processes across many hosts.

What may it reach: a gateway that checks the token

The MCP specification already describes the rules a gateway must follow. A protected MCP server acts as an OAuth 2.1 resource server. Clients name the server they want with a resource parameter, and the server checks that the token was issued for it. The spec also bans token passthrough. An MCP server must not hand the token it received to an upstream service (MCP).

MCP servers MUST NOT accept or transit any other tokens.

Three open-source gateways can enforce tool access on top of those tokens:

• agentgateway, a Linux Foundation project under Apache 2.0, writes rules in CEL. A rule such as jwt.sub == "triage-agent" && mcp.tool.name == "create_issue" allows one agent one tool. The gateway removes a denied tool from the list the agent sees (agentgateway).
• IBM ContextForge, also Apache 2.0, groups tools into virtual servers. Teams own servers and tools, and roles run from Platform Admin to Viewer (ContextForge).
• LiteLLM puts every MCP tool behind one endpoint and sets permissions by key, team or organization (LiteLLM).

Hiding a denied tool matters as much as blocking it. An agent that never sees a tool cannot be talked into calling it.

What may it spend: one key per agent

An LLM gateway sits between agents and model providers. In LiteLLM, each virtual key takes a list of allowed models and an optional team (LiteLLM). Each key also takes a maximum budget and a reset period, and requests fail once the key passes its budget (LiteLLM). Keys can also draw on a team budget.

Bifrost, from Maxim, is an Apache 2.0 alternative. Its virtual keys deny every provider by default and carry a dollar budget with a reset period (Bifrost). Read the licenses before you choose. LiteLLM is MIT licensed, except an enterprise directory that needs a commercial agreement for production use (LiteLLM).

Issue one key per agent, never one per team. A per-agent key is what lets you stop one agent and leave the rest running. A gateway also holds the keys to every provider, so pin its version. See Set up model fallbacks that fail safely for a supply-chain incident in a widely used gateway.

What did it do: trace and screen every call

Langfuse records traces through its SDKs or OpenTelemetry, and you can host it yourself. Its core is MIT licensed, and its enterprise directories carry a separate license (Langfuse). Tag every trace with three values: the agent ID, the user ID when the agent acts for someone, and the gateway key. Without those tags, a trace shows what happened but not who did it.

Screening needs more care in choosing a project. LLM Guard has scanners for prompt injection and secrets, but its repository is archived, and the project says it is no longer maintained (LLM Guard). Presidio finds and masks personal data under an MIT license. It moved from Microsoft to a community organization, Data Privacy Stack (Presidio). For why screening matters, see Hidden instructions in shared documents.

Worked example: a support triage agent

Take a 40-person software company. Its support lead, Dana, wants an agent that reads new help-desk tickets and files bug reports in the issue tracker in her name. Here is one call, traced through the four questions:

1. The agent record lists Dana as owner, the run mode as "acts for the user", two tools, one model and a monthly budget.
2. The agent signs in to Keycloak with its own client credentials. It exchanges Dana's token and its own for one token. The new token names Dana as the subject and the agent in the act claim.
3. The agent asks for that token with the issue tracker's MCP server as the resource. A token for any other server is refused.
4. The gateway rule allows read_ticket and create_issue for this agent. It hides delete_issue, so the agent never sees it.
5. The model call goes through LiteLLM on the agent's own key, which allows one model and stops at its budget.
6. Langfuse stores the trace, tagged with the agent ID, Dana's user ID and the key. Presidio masks customer email addresses before the ticket text reaches the model.

If the agent misbehaves, the team revokes its Keycloak client and its LiteLLM key. Dana keeps her access, and every other agent keeps running.

What you still have to build

The open-source projects give you the routing and the policy engine. They leave four jobs to you. First, wiring roles from your single sign-on provider into each gateway. Second, one admin screen where someone can see every agent and revoke one. Third, audit evidence: Mintive lists a SOC 2 Type II audit and signs HIPAA business associate agreements (Mintive). Fourth, keeping up with standards that are still moving.

That last job is real. Delegation in Keycloak is still a preview feature. At the IETF, an active draft applies workload identity and OAuth to AI agents (IETF). Build on RFC 8693 and the MCP authorization spec now, and expect the details to change.

Emeri did not deploy these projects. The facts come from each project's own documentation, linked above, as read on October 30, 2026.