What Is an MCP Gateway? Architecture, Security and Deployment

The short version

A model context protocol gateway sits between agent clients and one or more MCP servers. Instead of giving every agent direct access to every server, the gateway brokers requests, applies policy, handles authentication, and records what happened.

That matters when MCP moves from a local developer loop into production. A single agent may need browser tools, CRM actions, file resources, deployment commands, and internal APIs. The gateway is where those capabilities become a governed system instead of a loose collection of endpoints.

Reference architecture

A practical MCP gateway has a few clear responsibilities. It receives tool and resource calls from agent runtimes, maps those calls to approved servers, attaches the right credentials, enforces permissions, and emits telemetry.

• Client adapters: normalize calls from different agent frameworks and hosted model runtimes.
• Server registry: stores available MCP servers, tool names, schemas, environments, owners, and health state.
• Policy engine: decides which agent, user, workspace, and environment can call each tool.
• Auth broker: manages OAuth grants, service credentials, API keys, secret redaction, and token refresh.
• Router: selects the target MCP server, retries safe reads, and blocks unsafe writes when policy requires approval.
• Audit stream: records request metadata, tool arguments, result status, latency, and approval decisions.

Routing across multiple MCP servers

The gateway should route by capability, tenant, environment, and risk level. A support agent might read from a docs server, draft email through a mail server, and update an account through a CRM server, but only the CRM write should require a higher permission level.

For larger deployments, keep routing explicit. Name servers by purpose, keep production and staging separate, and avoid relying on a model to choose from a flat list of hundreds of tools. AgentDojo profiles package approved servers into smaller operational surfaces.

Illustrative example from the original guide; verify commands against your installed version.

profile: support-prod
servers:
  docs-read: read
  browserops: read
  inboxlane.draft: approval
  salesstack.contacts: write
  opsshell.deploy: blocked

Permissions, authentication, and approvals

Permissions should be narrower than login state. A user may have admin access to a SaaS product, but the agent usually needs a smaller set of actions. The gateway can translate broad identity into scoped tool permissions.

Authentication belongs in the gateway because agents should not handle raw secrets. Use OAuth where user context matters, service credentials for backend workflows, and environment-scoped secrets for private infrastructure. For risky mutations, add approval gates before the gateway forwards the call.

• Separate read tools from write tools.
• Attach credentials at request time, not inside prompts.
• Require human approval for irreversible actions.
• Log denied calls as clearly as successful calls.

Observability and deployment

Observability is the difference between a useful MCP deployment and an unknowable one. Track tool selection, latency, error rates, credential source, policy decision, request size, and result status. Redact sensitive arguments before storing logs.

Deploy the gateway close to the agent runtime when latency matters and close to private MCP servers when data gravity matters. For production, run multiple instances, keep policy in version control, publish health checks for each upstream server, and export audit logs to the systems your team already reviews.