MCP Server Security for Write-Enabled Tools

MCP server security for write-enabled tools requires two separate authorization decisions.

First: may this client connect to this MCP server? Second: may this exact tool call change this exact downstream resource? The Model Context Protocol defines authorization for the first question at the transport layer. It does not, by itself, decide whether PATCH /accounts/42 is an acceptable business action.

A valid MCP token therefore must not become a blanket permit for every tool, endpoint, and payload behind the server. For consequential writes, use a narrow tool surface, deterministic downstream policy, an exact approval preview, a separate target credential, and explicit execution state.

MCP authentication is not downstream action authorization

The current MCP authorization specification says its purpose is transport-level authorization for HTTP-based MCP connections. It defines how a client obtains and presents a token to an MCP server, including scope selection, resource indicators, and token validation.

That is necessary, but it is not the whole write path. An MCP server can expose a tool that calls another API. The downstream system has its own credential, resources, methods, and business rules. The MCP bearer token answers who may call the server; application code still must answer what the caller may do through it.

OWASP’s guidance on excessive agency recommends complete mediation: authorize actions in downstream systems or deterministic code rather than asking an LLM to decide whether its own requested operation is permitted.

Start with a trusted, minimal tool surface

An MCP server can expose tools that read data, send data, or perform actions using supplied credentials. OpenAI’s MCP guidance for the Agents SDK recommends connecting only to trusted servers, using least-privilege credentials, keeping tokens in authorization headers rather than URLs, and requiring approval for sensitive operations.

Before connecting a server, inventory what each tool can read or change, which credential it uses, whether the client can hide it, whether writes pause, and what evidence remains after a timeout.

Expose only what the workflow needs. A research agent does not need a delete tool merely because the server offers one. Tool filtering still is not sufficient authorization: a single update_record tool may accept many destinations and fields, so validate its arguments against an owner-defined boundary.

Keep MCP and target credentials separate

The MCP authorization security considerations require servers to validate that tokens are intended for them and prohibit passing the client’s MCP token through to an upstream API. If the MCP server calls a third-party service, it should act as a separate client with a separate upstream token.

• The MCP token grants access to the server’s published interface.
• The target credential grants access to a specific business API.
• Server-side policy narrows which target methods and resources the MCP caller can reach.

The target credential should not appear in the model context, tool schema, tool result, URL, or logs. Where the provider supports scoped or temporary credentials, prefer the smallest privilege and lifetime that fit the operation. The companion guide explains how to give an AI agent API access without exposing keys.

ActionDock follows this separation for its current API-write path. The agent uses a workspace API key to call ActionDock over MCP or HTTP. A workspace owner configures a different bearer token or API-key credential for the public HTTPS target. That target credential remains encrypted server-side and is not returned through agent discovery or job results.

Authorize the exact downstream request

Tool names and OAuth scopes are often too broad to express a business transaction. A production write boundary should resolve and check the connection identifier, HTTP method, normalized path, query, body, connection version, and destination.

In ActionDock, integration.execute submits one such request. Deterministic policy checks the requested method and path against the owner-configured connection. The operation then waits for a signed-in workspace owner to review the exact preview. Editing the connection invalidates the old proposal instead of silently changing what an earlier decision will execute.

This pattern keeps reasoning in the calling agent while placing authorization outside it. Read the MCP integration instructions, connection controls, and approval contract for the current interface.

The broader architecture is covered in AI Agent API Security: Make the First Safe Write. For review design specifically, see human-in-the-loop approval for AI agent actions.

Treat prompts, tool metadata, and results as untrusted input

MCP connects the model to more data and more capabilities. That increases the impact of indirect prompt injection: hostile instructions can arrive through a document, web result, tool description, or tool output instead of the user’s visible prompt.

OpenAI’s MCP and Connectors guidance recommends approvals for sensitive actions, trusted servers, careful review of data shared with remote servers, and logging. It also warns that remote MCP servers can change tool behavior and may include hidden instructions. OWASP’s prompt-injection guidance recommends constraining model behavior, validating expected formats in deterministic code, using least privilege, and requiring human approval for high-risk operations.

Prompt defenses help, but they should not be the final authorization gate. A model-based “reasonableness” check may flag unusual intent for review; it must never grant a method, path, or destination that deterministic policy denies.

The NSA’s 2026 report on MCP security design considerations likewise emphasizes implementation discipline, isolation, filtered network access, logging, and maintained components.

Use current protocol features without overreading them

The 2026-07-28 MCP release added authorization hardening and request headers such as Mcp-Method and Mcp-Name. The official release notes explain that gateways and rate limiters can use those headers for routing and metering.

For implementations that adopt that version, these headers can support coarse infrastructure policy. They do not validate a tool body, prove that a path is allowed, or authorize a downstream operation. The server must still verify request consistency, validate arguments, and enforce application policy.

Plan for retries and ambiguous outcomes

MCP delivery, server execution, and the downstream API call are separate failure domains. A timeout can leave the caller unable to tell whether a write took effect. Use a stable idempotency key for the same ActionDock submission and, when supported, a provider key downstream. These controls operate at different boundaries; neither promises exactly-once behavior for every API.

When delivery becomes ambiguous, ActionDock records execution_unknown and suppresses automatic retry. The operator should reconcile the target state before submitting another write. The detailed AI agent API retry guide explains the decision process.

Likewise, an execution record is evidence of what ActionDock observed, not independent proof of the provider’s current state. Keep that distinction in security reviews and customer-facing claims.

Production checklist for a write-enabled MCP server

Before enabling a consequential tool, verify all of the following:

1. Trust and tools: The server source and update process are understood, and the agent sees only required tools.
2. Transport: HTTPS and current MCP authorization requirements protect the client-to-server connection.
3. Audience: The MCP server accepts only tokens intended for its resource.
4. Arguments: Schemas and deterministic policy constrain the destination and operation.
5. Credentials: The MCP token is not reused downstream; target secrets stay server-side.
6. Approval and identity: Writes pause with an exact preview, and the submitting credential cannot approve them.
7. Outcome: Success, failure, rejection, and ambiguous delivery have explicit states and secret-free records.
8. Retries: Stable keys deduplicate submissions, and unknown writes are reconciled before retry.
9. Bypass: Direct keys, browser sessions, and native write connectors are removed or accepted as alternate paths.

The last check is essential. ActionDock controls only writes routed through its MCP or HTTP boundary. If an agent retains an authenticated browser or direct target credential, it can bypass the policy and approval path.

Frequently asked questions

Does a valid MCP token authorize every downstream action?

No. It authenticates or authorizes access to the MCP server according to that server’s scopes. The server still needs deterministic application policy for each tool and downstream resource.

Should every MCP tool call require human approval?

Not necessarily. A team may allow bounded read-only tools without per-call review. Consequential writes need a risk-appropriate gate; ActionDock currently requires owner approval for every integration.execute write.

Can an MCP gateway stop an agent from using a browser or direct connector?

No. It controls only calls routed through that gateway. Remove or restrict alternate credentials and write paths if the gateway is intended to be the enforced boundary.

Put one MCP write behind a real boundary

Start with one operation, one target API, and one accountable reviewer. Review the First Safe Write workflow, follow the agent integration guide, or describe the blocked write to map the smallest useful production boundary.