Skip to main content
Send the agent’s tool calls through a Tyk MCP proxy. Tyk checks every tools/call request against the allow and block lists in the proxy definition and in the agent’s policy. It removes forbidden tools from tools/list, and it adds upstream credentials so that the model never sees them. Tyk Gateway does not filter outbound network destinations, so use network policy for egress.

Why Agents Need Tool Limits

An AI agent selects its own tools. A prompt injection or a poisoned tool description can make it call a tool that it does not need. The OWASP Top 10 for LLM Applications calls this risk LLM06 Excessive Agency. Give each agent only the tools that its job needs. Tyk applies tool limits at three levels: Network egress is a fourth level, outside Tyk. See An Agent Built a URL and Hit Our Metadata Service.

How Do I Expose Only Some REST Endpoints to an LLM Agent, Not the Admin API?

Use REST API to MCP with an allow list. Tyk generates MCP tools from the operations in your Tyk OAS API. By default, every operation becomes a tool. When one entry has allow: true, Tyk exposes only the entries with allow: true.
With this configuration, the agent sees two tools. The admin operations in the same API do not become tools. Tyk also leaves out operations that the source API marks as internal or blocked. New operations in the source API do not become tools until you add them to the allow list. To give different agents different sets of operations from one API, create more than one MCP proxy. See How to slice one API into multiple MCP proxies. For all fields, see REST API to MCP definitions.

How Do I Block One MCP Tool for Every Agent?

Add the block middleware to the tool in the MCP proxy definition:
Tyk removes delete_user from tools/list for all consumers. If an agent calls the tool by name, Tyk does not send the call upstream. It returns this error:
A policy cannot override this block. For the Tyk Dashboard procedure, see How to block a tool. To give each agent a different list of tools, use policies. See How to implement role-based access control for an MCP proxy.

Should a Gateway Inject API Keys So the Model Never Sees Them?

Yes. If the agent holds the upstream credential, a prompt injection can make the model show it or use it for a different purpose. Give the agent a Tyk credential only. Tyk adds the upstream credential to the request after it checks the agent’s access. For configuration examples, see Upstream OAuth and Token exchange. With REST API to MCP, Tyk builds a new HTTP request from the tool arguments. It does not copy the agent’s Authorization header to the request. The upstream authentication of the source REST API then applies. The tool schema in tools/list does not show the upstream security schemes.

An Agent Built a URL and Hit Our Metadata Service: How Do I Allowlist Tool HTTP?

This attack is server-side request forgery (SSRF). See OWASP API7:2023 Server Side Request Forgery. A common target is the cloud instance metadata endpoint at 169.254.169.254, which can return cloud credentials.

What Tyk Gateway Controls and What It Does Not

Each MCP proxy sends requests to the upstream URL in its API definition, so an agent cannot change the host through a tool call. With REST API to MCP, a tool call goes only to the target URL of the source REST API. Tyk Gateway does not filter outbound requests by destination host or IP address. It does not block private ranges or 169.254.169.254, and it has no DNS rebinding protection. Administrators control the API definition, and many upstream services are on private networks, so Tyk does not apply these checks. An MCP server can have a tool that fetches a URL from its arguments. That request comes from the MCP server, not from Tyk. Tyk sees the tool call, but it does not see the URL that the MCP server opens. No single control stops SSRF. Combine these:
  1. Block URL-fetching tools, or leave them out of each agent’s allow list. Allow them only for agents that need them.
  2. Restrict egress from the MCP server and from Tyk Gateway with network policy. Use cloud security groups or a Kubernetes NetworkPolicy. Deny 169.254.169.254/32 and private ranges that the workload does not need.
  3. Require IMDSv2 on AWS, and set the metadata hop limit to 1. Containers then cannot reach the metadata service through the host.
  4. Send upstream traffic through an egress forward proxy that has a host allowlist. Set the proxy for an API with upstream.proxy. Set the proxy for requests that Tyk Gateway makes itself, such as JWKS and OAuth metadata, with external_services.
  5. Validate redirects and resolved IP addresses in the MCP server code that fetches URLs.

Verify the Setup

  1. Connect MCP Inspector to the MCP proxy with the agent’s credential.
  2. Send tools/list. Make sure that the list contains only the allowed tools.
  3. Call a blocked tool by name. Make sure that Tyk returns error -32002 and that the upstream does not receive the call.
  4. Examine the MCP access logs. Each record shows mcp_method and mcp_primitive_name, so you can see which tool each agent called.