MCP gateway security
Require authentication on every gateway with API keys, Basic Auth or bearer tokens.
Every MCP gateway requires authentication - a gateway cannot be left open. An AI agent presents a credential with each request, the credential resolves to a security definition, and that definition is the agent's identity everywhere else: in sessions, in the audit log and in rate limiting.
Credential types
| Type | How the agent sends it |
|---|---|
| API key | The X-API-Key header - the header name can be redefined through an environment variable |
| Basic Auth | The standard Authorization header, e.g. curl -u user:password |
| Bearer token | Authorization: Bearer <token> - a static token or a JWT verified against a JWKS endpoint, with audience and claim filters |
Assign definitions to a gateway
The Security picker on the wizard's step 01, How do agents connect?, lists the available API key and Basic Auth definitions. Each gateway has a security group named mcp.<gateway-name> and the picker manages that group's members - the same group is visible under Security > Groups, which is also where bearer token definitions are added to a gateway.
A request is accepted when any member of the group matches the presented credentials. Membership changes are live - adding or removing a member is reflected in enforcement immediately, without restarts.
When a JWT matches a claim-filtered bearer definition, the resolved identity is that specific definition - two definitions with different claim filters on one gateway resolve to different identities, so a session initialized with one token cannot be reused by a caller whose token resolves to the other. The details are on the bearer tokens page.
Rejections
A request without valid credentials is refused with HTTP 403 and never reaches any tool. Each rejection is logged in the server log with the gateway, the security definition and the username involved, e.g.:
With the audit log on, rejections are recorded too, as auth-failed events.
Origin validation
For gateways reachable from browsers, the Zato_MCP_Check_Origin environment variable, set to true, additionally validates the Origin header of incoming requests against the gateway's list of allowed origins - a request whose origin is not on the list is refused with HTTP 403 and logged:
MCP gateway `billing` rejected origin `https://evil.example` (sec name=`partner.key` username=`partner1`)
With validation off, which is the default, the header is ignored. Requests without the header, e.g. from command-line clients, are never affected either way.
See also
| Feature | What it does |
|---|---|
| Rate limits | Traffic caps configured on the same security definitions |
| Audit log | How accepted and rejected requests are recorded |
| Bearer tokens | Static tokens and JWTs with JWKS, audience and claim filters |
| REST authentication | The same definitions and groups protecting REST channels |