The MCP Security Playbook: Connecting AI Agents to Business Tools Safely

By the end of this playbook you will have:

• An inventory of every MCP server and client in use, with an owner for each
• A least-privilege configuration: minimal tools, minimal scopes, read-only where possible
• Authorization that follows the MCP spec: OAuth with audience-bound tokens, no passthrough
• A local server policy for installs, updates, and sandboxing
• Approval gates on write and destructive tools
• Logging and alerts that show who asked for what and which tool ran
• A quarterly review routine

Octacer note: We connect AI assistants to business systems for clients through MCP, n8n, and Zapier. The risky setups we see are rarely sophisticated attacks. They are a personal admin token pasted into a config file, every tool enabled by default, and nobody able to say which server sent a customer email. This playbook fixes those first.

The MCP specification is clear that the protocol enables "arbitrary data access and code execution paths", and sets out principles of user consent and control, data privacy, and tool safety (MCP specification, Security and trust and safety).

Three things make MCP different from a normal API integration:

1. The caller is a model. The model decides which tool to call and with what arguments, based on text it reads, including text an attacker may control. OWASP ranks prompt injection as the top risk for LLM applications (OWASP LLM01).
2. Agents act. Giving an agent more tools, permissions, or autonomy than it needs is its own risk category, which OWASP calls excessive agency (OWASP LLM06).
3. Servers are easy to add. One line of config can connect a new server with broad access.

1. A list of the AI clients your team uses (Claude Desktop, ChatGPT, Cursor, internal agents, n8n or Zapier agents).
2. Admin access to the systems those clients reach (CRM, file storage, databases, email).
3. Someone who owns AI tool access, even part-time.
4. A place to keep the inventory (a sheet is fine).

You cannot secure what you have not listed. For each MCP server record:

Look in client config files, team settings, and automation platforms. Remove anything nobody can explain.

Most servers expose more tools than you need. Turn off the rest in the client or server configuration.

For authorization scopes, the MCP security guidance recommends a progressive, least-privilege model: start with a minimal set of low-risk read scopes, and request more only when a privileged operation is actually attempted (MCP, Security best practices: Scope minimization). It warns that broad scopes granted up front widen the blast radius of a stolen token and make revocation and auditing harder.

Practical rules:

• Read before write. Start every new server read-only. Add write tools one at a time when a real task needs them.
• User-level credentials, not admin. The agent should only see what the person using it can see.
• Separate servers for separate risk. Keep a read-only reporting server apart from one that can update records.
• No production for experiments. Use a sandbox account or test data for trials.

For remote servers that use HTTP, the MCP authorization specification is based on OAuth. Key requirements include:

• Servers publish OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover the right authorization server.
• Clients use PKCE and Resource Indicators (RFC 8707), naming the MCP server as the intended audience of the token.

No token passthrough

The MCP security guidance describes token passthrough as an anti-pattern where a server accepts a token that was not issued for it and forwards it to a downstream API. It is explicitly forbidden by the authorization specification (MCP, Security best practices: Token passthrough). The risks it lists include bypassing rate limits and validation, losing the audit trail, and enabling the "confused deputy" problem.

If you build or host a server:

• Validate that every token was issued for your server (audience check).
• Get separate tokens for downstream APIs instead of reusing the client's token.
• Keep downstream credentials on the server, never in the client or the model's context.

Confused deputy and consent

If your MCP server acts as a proxy to a third-party API using a single static client ID, the guidance describes how an attacker could skip user consent. The mitigation is per-client consent: show the user which client is requesting access and get their approval before forwarding to the third-party authorization server.

SSRF and authorization URLs

The guidance also covers server-side request forgery during OAuth discovery and malicious authorization URLs. If you build a client, validate URLs from metadata before fetching or opening them, and block requests to internal network addresses.

Local servers run as programs on the user's machine with that user's permissions. The MCP guidance lists the risks plainly: arbitrary code execution, malicious startup commands, malicious payloads in the server, and access to insecure localhost servers through DNS rebinding (MCP, Security best practices: Local MCP server compromise).

The spec requires clients that offer one-click local server setup to show the exact command, flag it as potentially dangerous, and require explicit approval. Your own policy should go further:

1. Approved sources only. Official vendor servers or reviewed open-source repositories.
2. Pin versions. Do not run the latest version of a package automatically on every start.
3. Read the command. Check the full command and arguments before adding a server.
4. Sandbox where possible. Run servers in a container or with restricted file and network access.
5. Prefer stdio for local servers, or bind HTTP servers to localhost with authentication.
6. Keep secrets out of config files checked into repositories.

The model reads tool names, descriptions, and results as text. A malicious or compromised server can hide instructions there, and a legitimate tool can return attacker-written content, such as an email body or a web page.

The MCP tools specification says clients must treat tool annotations as untrusted unless they come from trusted servers, that servers must validate inputs, apply access controls, rate limit, and sanitize outputs, and that clients should show tool inputs to the user and ask for confirmation on sensitive operations (MCP specification, Tools).

Practical defences:

• Review tool descriptions when you add or update a server. Look for instructions aimed at the model.
• Watch for description changes on updates. A tool that changes its description after approval deserves a second look.
• Do not mix highly trusted and untrusted servers in the same agent session where you can avoid it. A tool that reads public content plus a tool that can send email is a classic exfiltration path.
• Keep sensitive data out of the context unless the task needs it.

Our AI Security Playbook covers prompt injection defences in more depth.

The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations (MCP specification, Tools).

Sort tools into three groups:

For agents running in automations, put the approval in the workflow itself. Our n8n human-in-the-loop tool gates playbook shows how to require approval before a tool runs.

When something goes wrong, you need to answer: who asked, which client, which server, which tool, which arguments, and what changed.

• Log every tool call with user, client, server, tool, arguments (with secrets removed), result status, and time.
• Log scope elevations with correlation IDs, as the MCP guidance suggests.
• Alert on unusual activity: bulk reads, writes outside working hours, repeated denied calls.
• Know how to revoke each server's access in minutes: OAuth app revocation, token rotation, or disabling the server in the client.

Set a recurring review:

1. Compare the inventory with what is actually configured.
2. Remove unused servers and tools.
3. Check versions and changelogs for local servers.
4. Review scopes against what tasks actually needed.
5. Sample logs for unexpected calls.
6. Rerun a few prompt injection tests against agents with write access.

• [ ] Inventory of every server and client, each with an owner
• [ ] Unused tools disabled
• [ ] New servers start read-only
• [ ] User-level credentials, not admin tokens
• [ ] OAuth with audience-bound tokens for remote servers
• [ ] No token passthrough to downstream APIs
• [ ] Per-client consent on proxy servers
• [ ] Local servers from approved sources, versions pinned, commands reviewed
• [ ] Secrets kept out of config files in repositories
• [ ] Tool descriptions reviewed on install and update
• [ ] Approval required for irreversible and external actions
• [ ] Every tool call logged with user, tool, and arguments
• [ ] Revocation steps documented and tested
• [ ] Quarterly review on the calendar

• Pasting a personal admin API key into a server config. Every user of that agent now has admin access.
• Enabling every tool "just in case". Excessive agency is a listed risk for a reason.
• Trusting a server because it is popular. Review it like any software you install.
• Letting the agent send email unattended. Combine that with any untrusted input and you have a data leak path.
• No logs. You cannot investigate what you did not record.

Is MCP secure?

MCP is a protocol. Its specification includes security requirements and a detailed best practices guide, but the security of your setup depends on which servers you connect, what access you grant, and how you control and log their use.

What is token passthrough in MCP?

It is when an MCP server accepts an access token that was not issued for it and forwards it to another API. The MCP authorization specification forbids it because it bypasses security controls and breaks the audit trail.

Are local MCP servers safe?

They are as safe as any software you run on your machine. They execute with your user's permissions, so install them only from trusted sources, review the command, pin versions, and sandbox them where you can.

What is tool poisoning?

It is a general term for hiding malicious instructions in tool descriptions or metadata so the model follows them. The MCP specification tells clients to treat tool annotations as untrusted unless they come from trusted servers.

Should AI agents be allowed to write to our CRM through MCP?

Yes, if writes are limited to the tools needed, use the user's own permissions, are logged, and require confirmation for anything significant. Start read-only and add writes one at a time.

How does this relate to the OWASP LLM Top 10?

MCP setups are directly exposed to prompt injection (LLM01) and excessive agency (LLM06). Least privilege, approvals, and treating tool content as untrusted are the main controls for both.

We set up and secure MCP connections between AI assistants and business systems such as HubSpot, GoHighLevel, NetSuite, Google Workspace, and internal databases. Typical work:

• An MCP and AI tool access audit using this playbook
• Building internal MCP servers with proper OAuth, scopes, and logging
• Adding approval gates to agents that write to your systems

See AI Apps and Integrations, our integration architecture, or book a call.

• Start small with MCP: MCP Business Ops Starter Pack
• Secure your wider AI stack: The AI Security Playbook
• Leaked keys in front-end code: Containing Client-Side AI Provider Keys

• Model Context Protocol, Specification (2025-11-25), Security and trust and safety: https://modelcontextprotocol.io/specification/2025-11-25
• Model Context Protocol, Specification, Authorization: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
• Model Context Protocol, Specification, Tools: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
• Model Context Protocol, Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• OWASP GenAI Security Project, LLM01 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
• IETF, RFC 9728 OAuth 2.0 Protected Resource Metadata: https://datatracker.ietf.org/doc/html/rfc9728
• IETF, RFC 8707 Resource Indicators for OAuth 2.0: https://www.rfc-editor.org/rfc/rfc8707.html