/ Enterprise MCP Gateway

API Credentials Are Not MCP Credentials

API-backed MCP tools need two separate auth planes.

This guide shows how the MCP client authenticates to the gateway while upstream API credentials stay behind the gateway as opaque credential bindings.

12 chapters · ~4 min read

01

Keep Two Auth Planes

The MCP client authenticates to the gateway. The upstream API credential stays behind the gateway.

Keep Two Auth Planes

Why it mattersAgents should prove who they are without carrying the secrets used to call upstream APIs.

02

Authenticate The Client In Context

The gateway sees user, agent, workload, client surface, tenant, and environment.

Authenticate The Client In Context

Why it mattersPolicy needs actor and surface context before any upstream credential is considered.

03

Filter Discovery Before The Agent Sees Tools

Policy decides which generated tools appear in tools/list.

Filter Discovery Before The Agent Sees Tools

Why it mattersUnauthorized API-backed tools should be hidden, not advertised first and denied later.

04

Detect API Auth During Import

OpenAPI or Postman import detects upstream auth requirements such as API key, bearer, basic, OAuth2, none, or unknown.

Detect API Auth During Import

Why it mattersAPI auth becomes gateway runtime metadata, not an input the agent must provide.

05

Mark The Requirement Caller-Hidden

callerVisible: false means the MCP caller never supplies or sees the upstream secret.

Mark The Requirement Caller-Hidden

Why it mattersGenerated tool contracts should not ask for API keys, tokens, passwords, or auth headers.

06

Bridge With A Credential Binding

The gateway stores an opaque binding ID that points to a customer secret store or identity system.

Bridge With A Credential Binding

Why it mattersRuntime can resolve credentials without putting secret material into schemas, prompts, or logs.

07

Generate Business Inputs Only

The generated MCP tool accepts business fields like to, body, and template_id.

Generate Business Inputs Only

Why it mattersAgents can call useful tools without becoming secret carriers.

08

Check Runtime Gates First

The gateway checks source approval, operation selection, host allowlist, policy, schema, binding, and size limits.

Check Runtime Gates First

Why it mattersCredential resolution should happen only after the request is allowed and well formed.

09

Inject Upstream Auth In The Adapter

The API-to-MCP adapter injects the right upstream auth after resolving the binding.

Inject Upstream Auth In The Adapter

Why it mattersThe upstream API receives required auth while the MCP caller never sees or supplies the secret.

10

Map Auth Methods Deliberately

API key, bearer, OAuth2, basic, HMAC, mTLS, cloud IAM, and cookie/session auth require different binding strategies.

Map Auth Methods Deliberately

Why it mattersA gateway should not flatten every upstream auth method into one unsafe credential model.

11

Audit Metadata, Not Secrets

Audit records binding ID, credential status, policy outcome, adapter outcome, and request ID.

Audit Metadata, Not Secrets

Why it mattersSecurity can investigate blast radius without turning audit logs into another secret store.

12

Operate Through UI, API, And CLI

Web UI, HTTP API, and CLI all operate the same control-plane objects.

Operate Through UI, API, And CLI

Why it mattersEnterprise teams need review screens, automation hooks, and runbook-friendly commands for the same auth boundary.

API auth boundary

Prove the boundary with one API-backed tool

We are looking for teams who want to work closely with us on governed API-to-MCP adoption.

Start with one real API operation, one generated MCP tool, one credential binding, one policy path, and one audit trail. We will prove that the agent can use the API-backed tool without receiving the upstream credential.

The goal is simple: useful API-backed MCP tools, clear policy boundaries, brokered credentials, and evidence your security team can review.

Book a walkthrough
Prove the boundary with one API-backed tool