Skip to content

MCP security for agent tool calls

Protect the connection. Restrict the tools. Check what each action will actually do.

On this page
  1. Start with the protocol’s authorization model
  2. Protect the tool execution boundary
  3. An authorized tool call can still violate business policy
  4. Choose a gateway, action policy or human approval for the job
  5. What to check before turning on enforcement
  6. Using Gatewise with MCP tools
DEFINITION / 01

What is MCP security?

MCP security protects the connections, credentials, tools and resources exposed through the Model Context Protocol. For agents that can change business data, it also means enforcing permissions and action policies inside the tool execution path.

Start with the protocol’s authorization model

For HTTP-based MCP deployments, the protocol describes delegated authorization using OAuth-based access. A protected MCP server validates access for its resource; a client discovers the authorization server and obtains the appropriate grant. Follow the specification for your protocol version rather than inventing a parallel login scheme.

Local standard-input/output deployments use a different credential model. Their security depends on the process environment and host permissions as well as the tool implementation. A remote gateway is not automatically present in that path.

Protect the tool execution boundary

  • Validate the caller and intended resource, and reject invalid or inappropriate credentials.
  • Expose the smallest useful set of tools and operations for each agent or user.
  • Validate tool arguments against a schema and check resource ownership on the server.
  • Evaluate business rules before writes such as refunds, deletions or outbound messages.
  • Keep untrusted tool output separate from trusted instructions and authorization decisions.
  • Record the request, evaluated policy, decision and subsequent execution outcome.

An authorized tool call can still violate business policy

A customer-support agent may legitimately access a refund tool. That permission alone does not establish whether this invoice was paid, whether the refund already happened or whether the amount needs manager approval. Those are concrete checks around the proposed action.

Place the check in the MCP server handler or another execution service that the agent cannot bypass. Collect evidence from the system of record, evaluate the action and call the payment provider only when permitted. Return a useful reason for a blocked or held request so the agent can explain the next step.

Choose a gateway, action policy or human approval for the job

An MCP gateway can centralize connection handling, authentication, routing and tool permissions across servers. Capabilities vary by implementation; some gateways also support contextual authorization. Evaluate the actual policy surface rather than the category name.

An action policy evaluates business conditions for a specific operation. A human approval workflow handles exceptions that need authority beyond the autonomous limit. These controls can work together: the gateway controls access, the execution service checks the action and an approver decides permitted exceptions.

What to check before turning on enforcement

Test the path with a routine allowed request, an explicit policy violation, an approval case, a duplicate and missing evidence. Also test a timeout and a request whose parameters change after approval. Confirm that an unapproved request cannot reach the downstream business API.

Use example records first. During shadow evaluation, compare policy outcomes against expected behavior and review false positives. Shadow mode observes decisions; it does not protect a live system until the relevant execution path is configured to enforce them.

Using Gatewise with MCP tools

Gatewise focuses on the business decision before execution. Its TypeScript SDK provides generic tool wrappers that can be integrated into an MCP handler, and its decision API can be called from an execution service. Your MCP server retains responsibility for protocol authentication, secrets and resource access.

Gatewise returns ALLOW, BLOCK, REQUIRE APPROVAL, NO ACTION or INSUFFICIENT EVIDENCE. The integration must honor that decision. Review the developer guide and discuss your tool handlers during early access; a configured integration is required before live actions are controlled.

Questions

Frequently asked questions

Give your agents freedom without giving them a blank cheque.

Tell us what your agents are allowed to do today. We will review whether Gatewise fits your agent workflow.

Works with your agents and existing business tools