An engineering team routes every LLM request through an AI gateway. The gateway logs prompts, centralizes provider keys, and enforces rate limits. A coding agent then connects to an MCP server that can read repositories and trigger CI jobs. The gateway may see model traffic, but that does not automatically indicate whether the agent should use a specific MCP tool for a particular repository.
What Does an AI Gateway Actually Control?
An AI gateway typically sits between an application and model providers. Depending on the product, it can centralize authentication, logging, rate limiting, routing, guardrails, and data-loss-prevention checks.
Those controls can show which model received a request or whether sensitive data appeared in a prompt. But MCP creates another path. An agent may call an MCP server to access repositories, databases, cloud APIs, or internal services. Securing that path requires more than inspecting model requests.
Why Is MCP Access Control Different?
MCP uses a client-server architecture in which AI applications connect to servers that expose tools and resources. Once those tools are available, an agent may dynamically select and chain them according to the task.
Consider an agent connected to an MCP server for a Git repository. That connection alone does not determine whether the agent can read every repository, push changes, modify branch settings, or trigger a deployment. Those are separate authorization decisions.
Effective MCP access control needs to evaluate several layers:
- Who is the requesting user or workload?
- Which AI agent identity is acting?
- Which MCP server and tool are being called?
- Which resource is being targeted?
- Is the action read-only, modifying, destructive, or externally visible?
A gateway that sees only model-provider traffic may not have enough context to answer those questions.
Why Does AI Agent Identity Matter?
An agent often acts under delegated authority. A developer may ask it to investigate a failed build, after which the agent can make several calls without the developer approving each step.
If every action appears under a single shared service account, teams lose important context. They cannot easily distinguish who started the task, who selected the action, and the downstream credential.
This is why AI agent identity matters for agentic AI security. Pluto’s AI agent access control guidance recommends treating the agent as an active principal, tracking delegated user context, and keeping permissions narrow. Current MCP authorization guidance also requires protected servers to accept only tokens intended for that server and prohibits token passthrough.
Runtime Context Changes the Decision
Static access is only part of the problem. An agent can use individually valid permissions in an unsafe sequence.
A support agent might be allowed to read a ticket and update a CRM record. If malicious instructions in the ticket prompt the agent to modify unrelated customer records, both actions may appear legitimate in isolation. The risk lies in the task, data, and sequence.
This is where an AI gateway and MCP security controls should complement each other. The gateway can govern model-facing traffic and the movement of sensitive data, while MCP-specific controls restrict servers, tools, resources, identities, and high-impact actions. Sensitive writes, deletions, deployments, or external messages may also require approval.
What Should a Complete Control Model Include?
A practical design uses multiple enforcement points rather than treating a single gateway as the entire security boundary. Teams should maintain an inventory of approved MCP servers, use scoped credentials, enforce least privilege at the tool and resource levels, validate tool inputs, and record meaningful agent actions.
Pluto’s guide to secure MCP integration explains the trust relationships established by external tools and package ecosystems. Its guidance on AI agent access control addresses both the identity and runtime aspects of access control. Together, these controls help security teams follow the agent’s execution path rather than only the model request.
The goal is not to replace an AI gateway, but to avoid treating it as the entire authorization layer.
Final Thoughts
An AI gateway can be an important control point for model traffic, but MCP extends the execution path beyond the model. Once agents can choose tools and act across enterprise systems, security must follow those actions. Strong MCP access control combines gateway protections with agent identity, scoped authorization, tool-level permissions, runtime checks, and auditability. That layered approach suits software that can decide not only what to say but also what to do.