Agent Gateway

Beta. Rows marked Preview or Planned arrive in later releases.

On the data plane, an Agent Gateway instance sits inline between agents and their targets, on the user’s Network, off the internet. It authenticates to each target with credentials it holds, and authenticates every request an agent sends to its gateway_url. On the control plane, at api.telnyx.com, the user sets each agent’s authorization and policy, controls its traffic, and audits its requests.

Targets

Target	What It Does	Availability
Models	One OpenAI-compatible endpoint for every model an agent uses.	Beta
Tools	Tools from Model Context Protocol (MCP) servers and REST APIs, served to the agent through one MCP endpoint. With tool search, the agent loads only the tools it needs.	Beta
Agents	Requests to other agents over agent-to-agent (A2A).	Planned

Component	Where It Runs	Availability
Agents	Edge Compute functions on the user’s Network. Each sends its requests to `gateway_url`.	Preview
Forwarding peer	A WireGuard peer inside the user’s network that forwards the instance’s requests to its subnets.	Preview
Tunnel hosts	Hosts inside the user’s network that run a Tunnel to Telnyx.	Preview

Outbound authentication is not a resource of its own. Each MCP server and API holds its method and credentials in its auth.

Method	How It Works	Availability
API keys	The gateway sends a static API key, bearer token, or password with every request to the server.	Beta
OAuth client credentials	The gateway trades a client ID and secret for a short-lived access token from the server’s OAuth provider, and renews it before it expires.	Beta
OAuth authorization code	Each user authorizes the gateway once, and the gateway sends the server that user’s own token.	Planned
OAuth token exchange	The gateway exchanges the agent’s token for one issued for the server, on the user’s behalf.	Planned
Token passthrough	The gateway forwards the agent’s own token to the server unchanged.	Beta
AWS Signature Version 4	The gateway signs each request to a server on AWS with stored AWS keys or an assumed role.	Beta

Method	How It Works	Availability
Keys	The gateway issues a key to each agent or team, and the agent presents it on every request.	Beta
Identity provider tokens	The agent authenticates with a token from the user’s own identity provider over OpenID Connect (OIDC), such as Okta or Microsoft Entra ID. The token’s claims identify the agent and its groups, and the gateway itself issues no keys.	Planned

Control	How It Works	Availability
Allow lists	Each key or team names the models it may use. A model outside its list is refused.	Beta
Tool permissions	Each key or team names the MCP servers and tools it may use, and the agents it may reach. The agent sees only those tools.	Beta
Guardrails	Checks that run before and after each request to a model or tool, such as masking personal data or blocking keywords. They run on every request or on the requests that name them.	Beta
Policies	Named sets of guardrails that build on a base policy. They apply to every request, to some models, or to the requests that name them.	Beta

Control	How It Works	Availability
Budgets and rate limits	A spend cap in USD, and requests and tokens per minute, per key and per team. A request past a limit is refused.	Beta
Routing and fallbacks	Retries, timeouts, and fallbacks to another model when one fails.	Beta
Caching	Repeated requests are answered from a cache.	Planned

Record	What It Holds	Availability
Spend logs	Every request, with its key, team, model, tokens, cost, status, and duration.	Beta
Traces and metrics	A trace per request in OpenTelemetry, and request, error, and latency metrics per key, team, and model.	Planned
Log export	Request logs sent to the user’s own observability tools, such as an OpenTelemetry collector, Langfuse, Datadog, or S3.	Planned
Audit logs	Who created, changed, or deleted a key, team, or model, and when.	Planned