> ## Documentation Index > Fetch the complete documentation index at: https://tyk.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # How do I give each AI agent its own API key and quota? > Give each AI agent its own identity, quota, rate limits, and tool permissions on a Tyk MCP proxy. Covers API keys, OAuth clients, token exchange, and scopes. Give each AI agent its own credential: a [Tyk API key](/docs/api-management/authentication/bearer-token), or an [OAuth client in your identity provider](/docs/ai-management/mcp-gateway/oauth-2-1). Bind the credential to a [Tyk security policy](/docs/ai-management/mcp-gateway/policies). The policy sets the agent's [quota](/docs/api-management/request-quotas), its [rate limits](/docs/api-management/rate-limit), and the [MCP tools it can call](/docs/ai-management/mcp-gateway/how-to-mcp-rbac). 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](https://spiffe.io/) 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](#step-3-identify-agents-that-use-oauth-tokens)). | 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](https://modelcontextprotocol.io/specification/2025-11-25/basic/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](https://www.rfc-editor.org/rfc/rfc8693)), 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](https://www.rfc-editor.org/rfc/rfc8707)). You can set a different audience and scopes for each MCP tool. See [Token exchange](/docs/api-management/authentication/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](#step-3-identify-agents-that-use-oauth-tokens) 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](/docs/ai-management/mcp-gateway/how-to-proxy-remote-mcp). ### 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`: ```json expandable theme={null} { "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](/docs/ai-management/mcp-gateway/policies). ### Step 2: Issue One Key for Each Agent 1. In the Tyk Dashboard, select **Keys** > **Add Key**. 2. Under **Access rights**, select **Apply Policy**, then select the policy for the agent's role. 3. 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. 4. Select **Create Key**. 5. 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`: ```yaml theme={null} 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](/docs/api-management/authentication/jwt-authorization). If using Tyk Classic, the identity field is `jwt_identity_base_field`. ### Step 4: Verify the Setup 1. Connect [MCP Inspector](https://github.com/modelcontextprotocol/inspector) to the proxy with one agent's credential. 2. Send `tools/list`. The response contains only the tools that the agent's policy allows. 3. Call a blocked tool, for example `delete_customer`. Tyk returns a JSON-RPC error and does not send the call upstream. 4. Call `create_ticket` 11 times in one minute. The eleventh call fails with a `429` rate limit error. 5. 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](/docs/ai-management/mcp-gateway/how-to-rate-limit-tools-per-consumer). *** ## Three Agents Share One Backend and Starve Each Other: How Do I Set Separate Quotas? 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: ```json theme={null} { "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](/docs/ai-management/mcp-gateway/core-concepts#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](/docs/ai-management/ai-studio/budgeting). For more about quotas, see [Request quotas](/docs/api-management/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: ```json theme={null} { "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](/docs/ai-management/mcp-gateway/oauth-2-1#protected-resource-metadata) ([RFC 9728](https://www.rfc-editor.org/rfc/rfc9728)) 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](/docs/ai-management/mcp-gateway/oauth-2-1#scope-enforcement) and [Composing features](/docs/ai-management/mcp-gateway/oauth-2-1#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: 1. Create one policy for each team. 2. In each policy, set `mcp_access_rights.tools.allowed` to the team's tools only. 3. 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](/docs/ai-management/mcp-gateway/how-to-mcp-rbac). 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](/docs/ai-management/mcp-gateway/how-to-block-tool).