Client Credentials

The client credentials flow (RFC 6749) is how Zilla authenticates itself to an upstream MCP server or HTTP API, using a static client ID and secret, independent of whatever credential the AI agent presented to the gateway. This is the outbound side of the connection: it doesn't authenticate the agent to AI Gateway, that's JWT Bearer's job on the mcp server binding. Client credentials authenticates the mcp client or mcp-http binding's own outbound call to an upstream that expects a service account, such as an internal API with no per-user identity to pass through.

Configuring the Guard

Define an oauth guard with grant: client-credentials, the token endpoint, and the service account's client ID and secret, then reference it from the outbound binding's options.authorization:

stores:
  cache:
    type: memory

guards:
  payments_oauth:
    type: oauth
    options:
      grant: client-credentials
      endpoint: https://auth.payments.internal/oauth/token
      scope: payments:read payments:write
      credentials:
        client-id: ${{env.PAYMENTS_CLIENT_ID}}
        client-secret: ${{env.PAYMENTS_CLIENT_SECRET}}
    store: cache

bindings:
  payments_mcp_client:
    type: mcp
    kind: client
    options:
      server: https://payments-mcp.internal/mcp
      authorization:
        payments_oauth:
          credentials: "Bearer {credentials}"
    exit: sys:http_client

The guard exchanges the client ID and secret for an access token at endpoint, caches it in the referenced store, and refreshes it automatically once it expires. No caller identity or inbound guard is involved, unlike Token Exchange.

See the oauth guard reference for the full set of options fields, and the mcp client binding reference for options.authorization.

Zilla Plus

The oauth guard, all three of its grants, requires Zilla Plus. It's a separate guard type from the open-source jwt guard used by JWT Bearer.

See JWT Bearer and Token Exchange for the other two flows.