How to Secure Claude Code MCP Servers Before Tool Calls Run

Claude Code can use MCP servers to reach source control, databases, browsers, deployment systems and internal APIs. That makes MCP useful—and makes the connection a security boundary. A permission prompt inside the coding agent is valuable, but it is not the same as an independently enforced authorization decision at the tool endpoint.

This guide describes a production-minded setup: Claude Code remains the MCP client, an authorization gateway becomes the MCP endpoint it calls, and the gateway forwards only approved requests to the real server.

Start with the threat model

Treat model output as untrusted input. A legitimate user request, a poisoned repository file or an injected tool description can all influence the next tool call. The practical security question is therefore not “did the model understand the instruction?” It is “is this exact agent allowed to execute this exact tool with these arguments against this environment?”

The highest-impact risks usually fall into five groups:

1. An agent inherits a credential that can do more than the current task.
2. Prompt injection turns untrusted text into a shell, database or deploy call.
3. A newly added MCP tool becomes reachable before policy catches up.
4. Secrets or customer data appear in tool arguments and logs.
5. The team cannot reconstruct which agent, policy or approver caused an action.

Put an MCP authorization gateway in the path

Configure Claude Code to call the gateway URL instead of the upstream MCP server directly. The gateway authenticates the agent, discovers the upstream tools and evaluates each tools/call request before forwarding it.

{
  "mcpServers": {
    "agentgate": {
      "type": "http",
      "url": "https://gateway.agentgatelabs.com/gateway/mcp/SERVER_ID",
      "headers": {
        "Authorization": "Bearer AGENT_KEY"
      }
    }
  }
}

Keep the agent key outside source control and issue a separate identity for each agent or automation boundary. Shared tokens make revocation and audit attribution weaker.

An inline gateway only protects traffic routed through it. Remove or restrict direct network access to the upstream server where possible, and document any bypass path that must remain.

Use default deny and explicit policy

New agents and newly discovered tools should not become trusted merely because they exist. A default-deny policy makes “no matching rule” a denial rather than an accidental grant.

Build policy around observable request context:

• agent identity and environment;
• MCP server and exact tool name;
• inferred capability, such as database write or shell execution;
• target environment;
• selected arguments and risk signals.

Start with a disposable test server. Allow a harmless read, deny a destructive call and route one reversible high-risk action to approval. This proves all three decision paths before production credentials enter the workflow.

Reserve human approval for consequential actions

Approval is useful when an action is legitimate but too consequential for unattended execution: production database changes, deployments, secret rotation, payment actions or customer-data exports.

Bind the decision to the request hash, expire it quickly and prevent replay. The reviewer should see the requesting agent, server, tool, target, risk reason and redacted arguments. A generic “Claude Code wants permission” message is not enough context for an accountable decision.

Keep secrets out of audit records

Tool arguments can contain API keys, tokens, connection strings and customer records. Detect and redact secret-like patterns before writing audit data. Pattern detection is a safety layer, not a guarantee, so the upstream tool should still use scoped credentials and avoid accepting raw secrets where a reference can be used instead.

Record useful evidence without retaining unnecessary sensitive values:

• agent and tenant identity;
• server, tool and environment;
• allow, deny or approval-required decision;
• risk score and matched policy reason;
• redacted context or a stable request hash;
• approval identity and outcome;
• execution status and timestamp.

Validate fail-closed behavior

Test the failure modes, not only the happy path. Disconnect the policy store, expire an approval, replay a consumed approval and submit changed arguments. The protected call should remain blocked whenever the gateway cannot prove an allow decision.

AgentGate’s protected MCP quickstart exercises discovery, allow, deny, approval and replay prevention against a disposable fixture. The integration compatibility matrix explains which paths are implemented and which client-specific behavior still requires validation.

A practical rollout sequence

Choose one Claude Code workflow and one sensitive tool. Inventory its current credentials and direct access paths. Put AgentGate in the MCP route, create an agent-specific credential, scan the tool inventory and simulate the initial rules. Run a harmless request, review the audit record, then test a denied and approval-required call.

Only after the evidence matches the intended boundary should the team connect a production-like upstream. The goal is not to trust Claude Code less. It is to make the actions it can take explicit, enforceable and reviewable.

Continue with the MCP security checklist or start a 14-day AgentGate trial.