How do I give each AI agent its own API key and quota?

Give each AI agent its own credential: a Tyk API key, or an OAuth client in your identity provider. Bind the credential to a Tyk security policy. The policy sets the agent’s quota, its rate limits, and the MCP tools it can call. Each agent then has its own counters, so one busy agent cannot use up the limits of another agent.

Item	Detail
Applies to	MCP proxies on Tyk Gateway
Edition	Per-agent keys, policies, quotas, per-tool rate limits, and tool access control: all editions. Token exchange: Enterprise Edition only.
Version	Tyk Gateway 5.13 or later. Token exchange: 5.14.0 or later.
API definition	Tyk OAS APIs only. Tyk Classic APIs do not support MCP.

Why Each Agent Needs Its Own Identity

An AI agent is a non-human identity, also called a workload identity. It calls tools on its own, and no person approves each call. When several agents share one key, Tyk Gateway sees them as one consumer. Their calls mix together in analytics, and they share one quota. If the key leaks, you must rotate it for all of them. With one credential for each agent, each agent gets its own limits and its own tool list. The access logs show which agent made each call. You can also revoke one agent and leave the others alone. Workload identity frameworks such as SPIFFE issue identities to services at the infrastructure level. Tyk works at the API level. It identifies an agent by the credential that the agent presents to the MCP proxy.

Should Each AI Agent Have Its Own API Key, or Inherit the End User’s OAuth Token?

The answer depends on whose authority the agent uses.

The agent…	Use	Identity that Tyk limits and records
Works for itself, for example a scheduled job or a background pipeline	A Tyk API key, or an OAuth client that uses the client credentials grant	The agent
Works for a signed-in user, for example a coding assistant	The user’s OAuth access token, issued to the agent’s OAuth client	The agent or the user. You select the claim (see Step 3).

Do not give an agent a static, shared API key when it acts for different users. The upstream service then cannot tell which user made the call, and every user gets the same permissions. Do not let the agent send the user’s token directly to the upstream service. The MCP security best practices call this “token passthrough”. It can cause a confused deputy problem: the upstream service accepts a token that was not issued for it. Tyk prevents this in one of two ways. With upstream OAuth, Tyk authenticates to the upstream with its own client credentials, and the upstream does not see the caller’s token. With token exchange (RFC 8693), Tyk sends the validated inbound token to your authorization server and gets back a new token for the upstream audience. With the token exchange grant, Tyk also sends the audience value in the resource parameter (RFC 8707). You can set a different audience and scopes for each MCP tool. See Token exchange.

Tyk token exchange supports impersonation only. It does not send an actor_token, so the exchanged token does not contain an act claim that names the agent. To record the agent, use the identity claim in Step 3 and the access logs.

Give Each Agent Its Own Key and Quota

This procedure uses one policy for each agent role, and one key for each agent. It assumes that you have an MCP proxy with authentication turned on. See How to secure an MCP proxy.

Step 1: Create a Policy for Each Agent Role

A policy is a template for keys. Create one policy for each group of agents that need the same limits and tools. For example, create a Support Agent policy and a Reporting Agent policy. Create the policy in the Tyk Dashboard (Policies > Add Policy), or send it to the Dashboard API with POST /api/portal/policies:

{
  "name": "Support Agent",
  "state": "active",
  "rate": 120,
  "per": 60,
  "quota_max": 20000,
  "quota_renewal_rate": 86400,
  "access_rights": {
    "{mcp-proxy-api-id}": {
      "api_id": "{mcp-proxy-api-id}",
      "api_name": "Customer MCP Proxy",
      "versions": ["Default"],
      "mcp_access_rights": {
        "tools": {
          "allowed": ["get_customer", "list_orders", "create_ticket"],
          "blocked": ["delete_.*"]
        }
      },
      "mcp_primitives": [
        {
          "type": "tool",
          "name": "create_ticket",
          "limit": { "rate": 10, "per": 60 }
        }
      ]
    }
  }
}

This policy gives each key:

120 requests a minute (rate, per).
20,000 requests a day (quota_max, quota_renewal_rate in seconds).
Access to three tools only. Tyk blocks all tool names that start with delete_.
A limit of 10 calls a minute on create_ticket.

For all policy fields, see MCP Gateway policies.

Step 2: Issue One Key for Each Agent

In the Tyk Dashboard, select Keys > Add Key.
Under Access rights, select Apply Policy, then select the policy for the agent’s role.
On the Configurations tab, set Alias to the agent’s name, for example support-agent-eu. Tyk shows the alias in analytics and access logs.
Select Create Key.
Give the key to that agent only.

Do this again for each agent. Two agents with the same policy get the same limits, but each key has its own counters.

Step 3: Identify Agents That Use OAuth Tokens

If agents send OAuth or JWT access tokens, Tyk creates the session from a claim in the token. By default, it uses sub. When an agent acts for a user, sub is usually the user, and the agent is in azp or client_id. To limit and record each agent, list the agent claim first in subjectClaims:

x-tyk-api-gateway:
  server:
    authentication:
      securitySchemes:
        jwtAuth:
          subjectClaims: ["azp", "client_id", "sub"]

Tyk uses the first claim that has a value. With this setting, all calls from one agent share the agent’s quota, whichever user the agent acts for. To limit each user instead, keep sub first. To apply the correct policy to each agent’s token, use scope-to-policy mapping (scopes.scopeToPolicyMapping) or a base policy claim (basePolicyClaims). See JWT authorization. If using Tyk Classic, the identity field is jwt_identity_base_field.

Step 4: Verify the Setup

Connect MCP Inspector to the proxy with one agent’s credential.
Send tools/list. The response contains only the tools that the agent’s policy allows.
Call a blocked tool, for example delete_customer. Tyk returns a JSON-RPC error and does not send the call upstream.
Call create_ticket 11 times in one minute. The eleventh call fails with a 429 rate limit error.
Connect with a second agent’s credential and call create_ticket. The call succeeds, because the second agent has its own counter.

For a step-by-step version with screenshots, see How to rate limit individual MCP tools per consumer.

Give each agent its own key or identity claim, as in the procedure above. Each key has its own quota and rate limit counters in Redis. When one agent uses all of its quota, Tyk blocks that agent only. To protect the backend as well, add a rate limit in the MCP proxy definition. All consumers share one counter for this limit:

{
  "x-tyk-api-gateway": {
    "middleware": {
      "mcpTools": {
        "run_report": {
          "rateLimit": { "enabled": true, "rate": 30, "per": 60 }
        }
      }
    }
  }
}

Use both. The policy limit caps each agent, and the proxy limit caps all agents together. See Policies versus middleware.

What Is the Difference Between a Rate Limit and a Quota for an Agent?

	Rate limit	Quota
Purpose	Controls bursts. Stops an agent that calls in a tight loop.	Controls total use over a long period.
Window	Seconds or minutes (`rate` and `per`)	Hours, days, or months (`quota_renewal_rate`)
What Tyk counts	Requests. You can also set a limit for one JSON-RPC method (`json_rpc_methods`) or one tool (`mcp_primitives`).	Every request that the agent sends to the MCP proxy, including discovery calls such as `tools/list`
Response when exceeded	`429 Too Many Requests`	`429 Too Many Requests` until the quota resets

Quotas apply to the proxy as a whole. You cannot set a quota for one tool. To limit one tool, use a per-tool rate limit. Tyk Gateway counts requests, not LLM tokens. To set a spend limit on LLM tokens for each agent, use Tyk AI Studio budgets. For more about quotas, see Request quotas.

How Do I Map MCP Tools to OAuth Scopes So an Agent Cannot Call delete_customer?

You can let your identity provider control tool access with scopes. Tyk supports two methods.

Method 1: Require Scopes on Each Tool

Declare the scopes that a tool needs in the MCP proxy definition, and turn on scopeCheck in the oauth2 security scheme. Tyk rejects a call when the token does not have the scope:

{
  "x-tyk-api-gateway": {
    "middleware": {
      "mcpTools": {
        "delete_customer": {
          "security": [{ "idpAuth": ["customers:delete"] }],
          "scopeCheck": { "enabled": true }
        }
      }
    }
  }
}

Do not give the customers:delete scope to the agent’s OAuth client. The agent then cannot call delete_customer. If you turn on Protected Resource Metadata (RFC 9728) with autoDeriveScopes, Tyk also tells MCP clients which scopes to request.

Method 2: Map Scopes to Policies

Map each scope to a Tyk policy, and set the tool list in the policy (mcp_access_rights). Use this method when you want Tyk policies to own tool access. Use one method for each tool, not both. See Scope enforcement and Composing features.

How Do I Publish a Small Tool Allowlist for Each Team?

Some MCP servers expose hundreds of tools. An MCP client such as Cursor loads all of them. The agent then spends context on tools it never uses, and it picks the wrong tool more often. Give each team a short list:

Create one policy for each team.
In each policy, set mcp_access_rights.tools.allowed to the team’s tools only.
Issue the team’s keys from that policy, or map the team’s scope to the policy.

Tyk filters tools/list, resources/list, and prompts/list for each consumer automatically. Each team’s agents see only their own tools. You do not need a separate proxy for each team. For a full example, see How to implement role-based access control for an MCP proxy. To remove a tool for every consumer, block it in the proxy definition. A policy cannot override this block. See How to block a tool.

​Why Each Agent Needs Its Own Identity

​Should Each AI Agent Have Its Own API Key, or Inherit the End User’s OAuth Token?

​Give Each Agent Its Own Key and Quota

​Step 1: Create a Policy for Each Agent Role

​Step 2: Issue One Key for Each Agent

​Step 3: Identify Agents That Use OAuth Tokens

​Step 4: Verify the Setup

​Three Agents Share One Backend and Starve Each Other: How Do I Set Separate Quotas?

​What Is the Difference Between a Rate Limit and a Quota for an Agent?

​How Do I Map MCP Tools to OAuth Scopes So an Agent Cannot Call delete_customer?

​Method 1: Require Scopes on Each Tool

​Method 2: Map Scopes to Policies

​How Do I Publish a Small Tool Allowlist for Each Team?

Why Each Agent Needs Its Own Identity

Should Each AI Agent Have Its Own API Key, or Inherit the End User’s OAuth Token?

Give Each Agent Its Own Key and Quota

Step 1: Create a Policy for Each Agent Role

Step 2: Issue One Key for Each Agent

Step 3: Identify Agents That Use OAuth Tokens

Step 4: Verify the Setup

Three Agents Share One Backend and Starve Each Other: How Do I Set Separate Quotas?

What Is the Difference Between a Rate Limit and a Quota for an Agent?

How Do I Map MCP Tools to OAuth Scopes So an Agent Cannot Call delete_customer?

Method 1: Require Scopes on Each Tool

Method 2: Map Scopes to Policies

How Do I Publish a Small Tool Allowlist for Each Team?