The Model Context Protocol, MCP, gives an AI client a standard way to find and call tools that servers expose. For an operations team that is a big change. The AI no longer suggests a command for you to paste. It calls a tool, and the tool talks to your cluster, your cloud account or your load balancer.
The specification is candid about what that means. Its security section opens by saying MCP “enables powerful capabilities through arbitrary data access and code execution paths”, and later admits that “MCP itself cannot enforce these security principles at the protocol level”. The enforcement is up to the people who build and run the servers and clients. In other words, it is up to you, and it is the ground zero-trust AI operations, an open specification, covers.
What changes when an AI reaches production through MCP?
Three things change at once.
- The AI calls tools itself. It picks which tool to run and with what input, based on everything in its context.
- Tool results flow back into the model. Whatever a system returns, including text an attacker planted in a log line or a ticket, becomes input for the next decision.
- Every server is a new path into a system. Each one needs credentials for the system behind it, and each one is a place where those credentials can leak.
So the questions an operations team asks about MCP are the old access-control questions in a new spot. Where do the keys live? How much can each tool do? Who decides when something changes?
What does the MCP specification ask for?
The specification sets out principles and leaves enforcement to implementers. The parts that matter most for production:
- “Hosts must obtain explicit user consent before invoking any tool.”
- “For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.”
- Tool descriptions and annotations “should be considered untrusted, unless obtained from a trusted server.”
- Servers “MUST” validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitize tool outputs.
- Clients “SHOULD” prompt for confirmation on sensitive operations, show tool inputs before calling the server, and log tool usage for audit.
Good principles. They leave three risks for operations teams to close.
Where do the credentials live?
An MCP server for infrastructure needs a way into the system behind it: an API token, a kubeconfig, a service account. If that server runs on a workstation next to the AI client, its credential sits on that workstation too, in a config file or an environment variable that other tools on the same machine may be able to read. An agent that hits an access error and goes looking for a token can find it there.
The MCP security best practices close one door firmly. They call “token passthrough” an anti-pattern and say servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server”. They also describe local server compromise as its own attack class. The control that follows is simple to state: the credential for a production system lives server-side, behind an authorization check, and never where the model’s process can read it. We make the longer case in should AI agents hold production credentials?
Are the tools wider than the job?
The OWASP Top 10 for LLM applications calls this “Excessive Agency” and traces it to three root causes: “excessive functionality; excessive permissions; excessive autonomy”. Its example is an extension meant to read documents that can also modify and delete them. In operations the classic case is a generic “run a shell command” tool, where one tool means every command.
The MCP best practices make the same point about OAuth scopes. Broad scopes granted up front expand the damage a stolen token can do, make revocation painful and hide intent in the audit trail. They recommend a “minimal initial scope set” of low-risk read operations, with elevation requested only when a privileged operation is first attempted.
For production that translates into three controls. Keep read operations and change operations apart. Run reads with the permissions of the person who asked. Hide the tools a person is not allowed to use, so the model never sees them.
Who actually approves a change?
An MCP client can show a confirmation prompt before a tool runs, and the specification encourages it. The prompt lives in the client, though. From the server’s side, a call that a person read carefully looks the same as one that was clicked through without reading. A confirmation in the client is a useful speed bump. It is weak evidence that a person decided.
For changes to production, the approval has to be enforced where the change happens. The server should refuse a write unless an authenticated person has approved that exact content. For high-risk changes, a second factor outside the client, such as a push to the approver’s phone, closes the gap the prompt leaves. More on this in how to enforce human approval for AI changes.
What should an operations team insist on?
Before you connect an MCP server to production, check these:
- Credentials for the target system never reach the client or the model’s process.
- Read tools and change tools are separate, and change tools create a request instead of acting.
- Every call is authorized server-side with the requesting person’s permissions.
- Approval for changes is enforced on the server, with an optional second factor outside the client.
- The approved content is fingerprinted and checked again when it runs.
- Inputs are validated, calls are rate-limited and outputs are sanitized, as the specification requires.
- Tool descriptions from servers you do not control are treated as untrusted input.
- Every call and every decision is logged where your team can see it.
How GAEZLA does it
GAEZLA exposes one MCP endpoint with two tools, search and execute. search finds operations and never runs code. execute runs the code the AI writes in a sandbox with no network and a time limit. Calls to your systems run inside GAEZLA with the permissions of the operator who asked, checked again on every call, and areas an operator’s roles do not admit are not shown. The AI never holds a credential.
When the AI asks for a change, it is drafted as a proposal. An operator approves it in the console, or answers an approval prompt in their own MCP client. The approve and execute calls accept only an operator, so agents, routines and machine tokens are refused, and nothing in GAEZLA can approve. Mail and jobs that use a secret are approved only in the console.
Two caveats we state plainly. An accept in your MCP client proves the client accepted, not that a person pressed the key. With multi-factor authentication on approvals, a Complete-plan feature that is off by default, every approval also needs a push on the operator’s phone. And GAEZLA masks secret-named fields in tool results before its own console’s model sees them, but results returned to your own MCP client are size-capped, not masked.