AI assistants are most valuable when they can do more than chat: look up a record, query a data set, open a ticket, read a document. The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to tools and data sources. That standardization is helpful, and it also concentrates risk. A single connection can now expose many systems to software that acts on natural-language instructions.

Key takeaways

  • Treat every tool an AI assistant can call as an API exposed to an untrusted caller, because the assistant can be steered by text it reads.
  • Put one policy-enforcing gateway in front of your MCP services instead of letting each service invent its own security.
  • Authorize per tool, deny by default, start read-only and log every call.
  • Plan for protocol details to evolve, and keep authentication standards-based so clients and servers can change independently.

Why this needs a security design

Ordinary API clients do what their code says. An AI assistant decides at run time which tool to call and with what arguments, based on prompts, documents and tool output it has read. If any of that content is attacker-influenced, the assistant can be manipulated into misusing the access it holds. This is usually called prompt injection, and it means the permissions you grant matter more than any promise about how the model will behave.

Common failure modes include over-privileged tools (an assistant that only needs to read tickets can also delete them), tokens that are broader or longer-lived than the task requires, one service forwarding a user's token to another without checking whether it was meant for that service, and silent data exfiltration through tools that can send content out.

The gateway pattern

A gateway is a single, well-defended entry point between assistants and your internal MCP services. It gives security teams one place to apply policy and gives platform teams a repeatable way to onboard new tools.

  1. Authenticate every request. Validate the bearer token on each call: signature, issuer, expiry and, importantly, audience, so a token minted for another service is rejected.
  2. Map identity to permissions. Translate groups or roles from your identity provider into allowed tools. Deny by default, and keep the mapping in reviewed configuration, not in individual services.
  3. Authorize per tool, and per argument where it matters. Being allowed to reach a service is not the same as being allowed to run every tool on it. Constrain write and delete operations separately from reads.
  4. Route. Forward permitted calls to downstream services, ideally exchanging the incoming token for a narrowly scoped one instead of passing the original along.
  5. Log and rate-limit. Record who called which tool, when and with what outcome, and limit call volume to contain runaway loops and abuse.

Edge and platform protections

Because the gateway is reachable by IDE-based assistants and other clients, treat it like any public API. Terminate TLS at a hardened edge, apply web application firewall rules to the OAuth and MCP endpoints, restrict methods and payload sizes, expose health probes for the platform, and keep secrets in a managed vault so they are never baked into images or repositories. Deploy through version-controlled infrastructure and configuration so every change is reviewed, and so you can reproduce the environment.

Discovery and standards

MCP defines an OAuth-based authorization approach for its HTTP transports, and clients rely on standard discovery metadata to find the authorization server they should use. Publishing correct metadata, and speaking the transport that clients actually use, matters in practice: a gateway that exposes a custom REST layout instead of the protocol's own request shape will not work with off-the-shelf clients, even if its security is excellent. Check the current specification when you build, because details continue to evolve.

Operating it safely

  • Start read-only. Add write capabilities one tool at a time, with explicit review.
  • Keep a human in the loop for consequential actions. Require confirmation for anything that changes data, spends money or sends information outside the organization.
  • Make revocation fast. Short-lived tokens, a central place to disable a tool or a group, and alerting on unusual call patterns.
  • Test the failure paths. Expired tokens, wrong audience, missing group, oversized payloads and malformed requests should all fail clearly and safely.

A practical starting point

Pick one low-risk, read-only tool, put it behind the gateway with real authentication and logging, and let a small group use it. You will learn quickly where the policy model is too coarse, where clients struggle and what your audit trail needs to show. Then onboard the next service using the same pattern.

This article offers general engineering perspective. It does not describe a specific client engagement.