Skip to content

MCP security for business AI tools

Treat every Model Context Protocol (MCP) server, and every tool description it sends, as untrusted code and input. Allow-list approved servers at pinned versions, give each the narrowest scopes with no token passthrough, require consent for tool calls, and log them. Never give one agent private data, untrusted content and a way to send data out at once: that "lethal trifecta" is banned at every risk tier. This page sets out MCP security best practices for businesses as of October 2026, shows how to find servers nobody approved, and applies the same rules to agents built in SaaS agent builders and workflow tools.

Who this is for

Security leads, platform and identity teams, and builders adding agents or AI features with tools.

What is MCP, and why does it change the risk?

The Model Context Protocol (MCP) is an open standard that lets an AI tool connect to other tools and data, such as a mailbox, a CRM or a file share. Each connection is an MCP server, a small program that offers "tools" the AI can call. As of October 2026 the current specification is version 2026-07-281.

An agent with MCP tools decides which tool to call from text it reads, including documents, tickets, web pages and tool descriptions, so anyone who can put text in front of it can try to steer it (prompt injection). The researchers behind the GitHub case below concluded that model alignment doesn't stop this and the controls must sit outside the model6 (A-017). The specification says hosts must get explicit user consent before invoking any tool and must treat tool descriptions as untrusted unless they come from a trusted server, but the protocol can't enforce either1.

The baseline: eight controls

The floors (including the trifecta rule) and the approved-tools gate are required at every tier (gate matrix). The rest is the recommended baseline your Decision Record adopts. Download it as a spreadsheet: mcp-baseline.csv. Prompt to Prototype, MCP security for business AI tools, https://prompt-to-prototype.com/security/mcp-and-agents/, as of October 2026. Licensed CC BY-SA 4.0.

  1. Allow-list approved servers, at pinned versions. Builders may connect only servers on the approved-tools list, installed from a known source at a recorded version. A new version is a new approval, because an update can change what the server does.
  2. Narrowest scopes; no wildcards. Read-only by default, one project or mailbox rather than all of them. The MCP security guidance names wildcard or omnibus scopes (*, all, full-access) as a common mistake and recommends minimal scopes, added to only when an action needs them2. If a server only works with admin rights, it isn't approved.
  3. No token passthrough. An MCP server must not accept a token that wasn't issued to it, or forward a person's token to another service. The specification forbids it2, because it breaks audit trails and lets a stolen token be reused elsewhere (token passthrough).
  4. Consent for tool calls. The specification asks for consent before any tool call1. At a minimum, a person approves every call that writes, deletes, sends or runs a command. Reads of internal data may be pre-approved only after the agent passes the trifecta check. A tool that fetches a URL or loads an image is a way out, not a read, so it's never pre-approved. Prompts get clicked through, so the other controls limit what a click can do.
  5. Sandbox local servers. A server on a laptop runs with the user's own permissions. Run it in a container or the tool's sandbox, with file and network access limited to what's needed. The specification requires clients to show the exact command before a one-click install and recommends sandboxing2.
  6. Separate credentials per server. Each server gets its own credential, held server-side in a secrets manager or the platform secret store, never a person's own login or a shared admin key (secrets).
  7. Log every tool call. Record which agent called which tool, with what scope, when, and the result status, not the data returned (logging). Check what an agent says it did against these logs.
  8. Review on change and on a schedule. Re-review a server when its version, scopes or connected data change, and at the app's scheduled review.

Don't: install an unvetted MCP server, extension or plugin (AP7)

In September 2025, version 1.0.16 of the postmark-mcp package on npm added a hidden BCC copying users' emails to an outside address; its discoverer described it as the first malicious MCP server found in the wild4. In July 2025, a compromised token let an attacker ship a destructive prompt in an AI coding extension's official release5.

The lethal trifecta: the one rule you can't skip

An agent leaks data when it has all three of these at once3:

  1. Private data: a mailbox, a database, internal files, customer records.
  2. Untrusted content: anything an outsider could have written, such as inbound email, tickets, web pages, shared documents, public issues or a tool description.
  3. A way to send data out: email, a comment or pull request, calling a URL, writing somewhere public, or even showing a link that loads an image.

With all three, a hidden instruction in the untrusted content turns the agent's permissions against you. The trifecta rule is the first of the two floors: remove one leg before the agent runs, in Sandbox too. It can't be downgraded or excepted.

The trifecta check (two minutes per agent). Write down every tool and data source the agent can reach. Mark each one P (private data), U (untrusted content) or O (a way out). If all three letters appear anywhere in the list, the agent can't run until one is gone.

Leg to remove How to remove it by design
Private data Give the agent only public or already-shared data, or a copy with the sensitive fields removed
Untrusted content Only let it read content from your own staff or systems, such as an internal knowledge base, not inbound email or public issues
A way out No send, post or URL-fetch tools; outputs go to a draft a person reviews and sends; block outbound network access from the agent's environment

An instruction in the prompt ("never send data outside the company") doesn't remove a leg. It's a request to the model, and injection works by overriding requests.

Don't: build a lethal-trifecta agent (AP6)

May 2025: a malicious public issue made an agent using the GitHub MCP server copy private-repository data into a public pull request6. July 2025: an agent reading support tickets through a database MCP server, with a key that bypassed row-level security, could be told to dump integration tokens7. June 2025: a crafted email made an office AI assistant leak data with no click (CVE-2025-32711)8. A coding tool was steered, through content fetched over MCP, into rewriting its own MCP configuration and running commands unconfirmed (CVE-2025-54135)9. All three legs were present each time.

How do you find shadow MCP servers?

Assume some servers are running that nobody approved. Look in three places.

1. Configuration files on laptops. AI tools keep MCP settings in files such as mcp.json, .mcp.json, mcp_config.json, claude_desktop_config.json, .claude.json, .gemini/settings.json and .codex/config.toml. Names change as tools change, so the commands also search JSON and TOML files for the mcpServers or mcp_servers key. A clean result doesn't prove there are none: tools installed elsewhere, or remote servers added in a web app, won't show up. A builder can check their own machine; IT can run the same search fleet-wide through its device-management or endpoint-security tool.

Get-ChildItem -Path $HOME -Recurse -Depth 5 -Force -File -ErrorAction SilentlyContinue -Include *.json, config.toml | Where-Object { $_.Name -like '*mcp*' -or (Select-String -Path $_.FullName -Pattern 'mcpServers|mcp_servers' -Quiet) } | Select-Object FullName, LastWriteTime

find "$HOME" -maxdepth 6 \( -name "*mcp*.json" -o \( \( -name "*.json" -o -name "config.toml" \) -size -2M -exec grep -qE 'mcpServers|mcp_servers' {} \; \) \) -print 2>/dev/null

On macOS, a search across ~/Library may trigger privacy prompts; click "Don't Allow" for folders you don't need. Compare the servers each file names with the approved list, especially ones that run commands (npx, uvx, docker run). Searching staff laptops fleet-wide is electronic monitoring: cover it in your monitoring policy (Ontario, for example, requires employers with 25 or more employees to have a written one10), and as of October 2026 some US states, such as New York, require prior notice of electronic monitoring (US state laws).

2. OAuth grants in your identity provider. Remote MCP servers and SaaS agents usually connect through an OAuth grant: a person clicks "allow", and the tool gets a token to act for them. Export the grant list from your identity provider (for example Microsoft Entra or Google Workspace) and look for AI tools and MCP servers with mail, file or admin scopes.

3. Ask. Run a short amnesty: anything builders list in time gets reviewed, not removed. See find existing apps.

Do the same rules apply to agents that don't use MCP?

Yes. Many agents are built in a SaaS agent builder, or are a workflow-tool flow with an AI step. They're worker-built apps, tiered, registered, owned and retired like any other. For terminal and IDE coding tools, see safe permissions for AI coding agents.

Two parts of the tier model matter most for them:

  • M3, autonomous agent or automation. Answer the six questions for every permission the agent has been granted, not for the job it was built to do (agents and automations).
  • No token downgrade for agents. Standard downgrade 3 isn't available to agents, automations or AI features. Scope the token instead.

Non-human identities and grants. Each agent acts through a non-human identity: a service account, a key, a token or a person's OAuth grant. Use one app registry for apps and agents: the app record holds the agent's identity, every grant and token with its scopes, its MCP servers and versions, the trifecta check result and the owner's role (one row each on the AI and agents sheet, with version and trifecta_check columns). The recommended baseline below (the gate matrix requires a quarterly access review only for Critical apps) draws on OWASP's Non-Human Identities Top 1011 and the IETF's OAuth security best practice12:

  1. One identity per agent, owned by a role. Never a person's login or a shared key.
  2. Admin consent and short-lived, scoped tokens. Turn off self-service consent for AI and third-party apps beyond basic profile access, and use an admin consent workflow. Prefer tokens that expire, each restricted to the minimum privileges and the one service it's meant for.
  3. Review grants quarterly. Remove inactive grants; check scopes against the app record.
  4. Revoke fast. Revoke an agent's grants and tokens the same day its owner leaves or changes, or it's retired (when the builder leaves). Keep the list of which agents use which vendor, so you can revoke every token for a breached vendor within hours.

Don't: leave third-party AI integration tokens unscoped and unreviewed

In August 2025, attackers used stolen OAuth tokens from a sales-chat integration to query customers' CRM instances for secrets such as cloud keys, then deleted their query jobs to cover their tracks. The investigators advised revoking and rotating all of the integration's tokens, restricting connected-app scopes and limiting session lifetimes13.

Mapping to the OWASP Agentic Top 10

The OWASP Top 10 for Agentic Applications (released December 2025) is the best checklist of agent-specific risks. The list below comes from secondary sources, because the release page doesn't print it14.

OWASP item Control on this page
ASI01 Agent Goal Hijack The trifecta rule; consent for tool calls
ASI02 Tool Misuse and Exploitation Narrowest scopes; consent; logging
ASI03 Agent Identity and Privilege Abuse One identity per agent; no token passthrough; admin consent
ASI04 Agentic Supply Chain Compromise Allow-list and pinned versions; review on change
ASI05 Unexpected Code Execution Sandbox local servers
ASI06 Memory and Context Poisoning Treat tool descriptions and retrieved content as untrusted
ASI07 Insecure Inter-Agent Communication Separate credentials; no token passthrough
ASI08 Cascading Agent Failures Narrow scopes; change caps from the tier model
ASI09 Human-Agent Trust Exploitation Check actions against logs, not the agent's summary
ASI10 Rogue Agents Shadow-server discovery; registry; revocation

Fast-moving

As of October 2026. Check the review date.

  • NSA AI Security Center, MCP security design considerations (20 May 2026; NSA alone): human approval, least privilege, trust separation, input validation, logging, credential expiry (themes per a law-firm summary)15.
  • Six agencies including CISA and the Canadian Centre for Cyber Security, "Careful Adoption of Agentic AI Services" (1 May 2026): least privilege, low-risk uses first, vet third-party agents and tools16.
  • CoSAI, "Model Context Protocol (MCP) Security" (draft, 8 Jan 2026): an industry threat model for MCP17.
  • Singapore IMDA, Model AI Governance Framework for Agentic AI (v1.5, 20 May 2026): bounding agent permissions upfront18.

Record the decision

Record your MCP and agent policy once, as a program-level Decision Record, using the decision record template.

Illustrative composite

Title: Allow-list MCP servers and agent integrations · Status: accepted · Date: YYYY-MM-DD · Owner: IT/platform owner (a role) · Sponsor: the executive sponsor

Context. Builders are connecting AI tools to company systems through MCP servers and SaaS agent builders.

Decision. Only servers and integrations on the approved-tools list, at pinned versions, may connect to company data. Each gets the narrowest scope, its own credential and logged tool calls. No token passthrough, no wildcard scopes, and consent for any write, delete, send, command or URL fetch. The trifecta check is recorded for every agent. Self-service OAuth consent for AI apps above basic scopes is off. Agents are registered in the app registry, and grants are reviewed quarterly.

Alternatives considered. Ban MCP and agents (rejected: bans drive unsanctioned use). Allow any server but monitor (rejected: monitoring finds leaks after the fact). Rely on model safeguards (rejected: injection still works against strong models).

Consequences. Server requests are answered within 5 working days; IT runs the laptop and identity-provider searches quarterly.

Review by: three months from the date above, or sooner if the MCP specification or a major server changes its security model.

Assumptions and evidence

  • A-017 (High): we expect agents connected to private data and untrusted content to be prompt-injectable, so allow-listing, scoping and removing a trifecta leg are necessary; test this by red-teaming one agent per quarter with a planted instruction and recording whether a control, not the model, stopped it.
  • A-044 (Low): we expect agent identities, OAuth grants and tokens to be inventoried and tied to an owner role cheaply enough to support registration and leaver handling; test this by comparing the identity provider's grant list with the registry each quarter and counting grants with no owner.

Evidence: security research and incident reports, a protocol specification, government guidance and OWASP community lists; no controlled study of MCP governance in businesses. Facts on this page are as of October 2026.

  1. Model Context Protocol, specification version 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28 [primary], accessed 2026-10-21. ↩↩↩

  2. Model Context Protocol, "Security Best Practices", specification version 2026-07-28 (token passthrough, local server compromise, scope minimization). https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices [primary], accessed 2026-10-21. ↩↩↩

  3. Simon Willison, blog post defining the "lethal trifecta" for AI agents, 16 Jun 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ [research], accessed 2026-10-21. ↩

  4. Snyk, report on the malicious postmark-mcp server on npm, Sep 2025 (the "first in the wild" description is the discoverer's, Koi Security). https://snyk.io/blog/malicious-mcp-server-on-npm-postmark-mcp-harvests-emails/ [vendor], accessed 2026-10-21. ↩

  5. AWS, security bulletin AWS-2025-015 on the Amazon Q Developer extension, Jul 2025. https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ [primary], accessed 2026-10-21. ↩

  6. Invariant Labs, "GitHub MCP exploited: accessing private repositories via MCP", 26 May 2025. https://invariantlabs.ai/blog/mcp-github-vulnerability [vendor], accessed 2026-10-21. ↩↩

  7. Simon Willison, post on the Supabase MCP lethal-trifecta demonstration, 6 Jul 2025. https://simonwillison.net/2025/Jul/06/supabase-mcp-lethal-trifecta/ [research], accessed 2026-10-21. ↩

  8. The Hacker News, report on EchoLeak (CVE-2025-32711), Jun 2025. https://thehackernews.com/2025/06/zero-click-ai-vulnerability-exposes.html [news], accessed 2026-10-21. ↩

  9. The Hacker News, report on CurXecute (CVE-2025-54135), Aug 2025. https://thehackernews.com/2025/08/cursor-ai-code-editor-fixed-flaw.html [news], accessed 2026-10-21. ↩

  10. Government of Ontario, "Your guide to the Employment Standards Act: Written policy on electronic monitoring of employees". https://www.ontario.ca/document/your-guide-employment-standards-act-0/written-policy-electronic-monitoring-employees [regulator], accessed 2026-10-21. ↩

  11. OWASP, "Non-Human Identities Top 10", 2025. https://owasp.org/www-project-non-human-identities-top-10/ [primary], accessed 2026-10-21. ↩

  12. IETF, RFC 9700, "Best Current Practice for OAuth 2.0 Security", 2025. https://www.rfc-editor.org/rfc/rfc9700 [primary], accessed 2026-10-21. ↩

  13. Google Threat Intelligence, "Widespread data theft targets Salesforce instances via Salesloft Drift", updated 28 Aug 2025. https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift [primary], accessed 2026-10-21. ↩

  14. OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications for 2026", 9 Dec 2025 (item list from secondary sources). https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ [primary], accessed 2026-10-21. ↩

  15. NSA Artificial Intelligence Security Center, cybersecurity information sheet "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation", 20 May 2026. https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf [primary, unread: the PDF returned 403 to our tools; themes via the Reed Smith summary, https://www.reedsmith.com/our-insights/blogs/viewpoints/102mvg9/nsa-publishes-security-guidance-on-designing-ai-systems-with-model-context-protoc/, secondary], accessed 2026-10-21. ↩

  16. CISA, ASD's ACSC, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, "Careful Adoption of Agentic AI Services", 1 May 2026. https://cyber.gc.ca/en/news-events/joint-guidance-careful-adoption-agentic-artificial-intelligence-services [regulator], accessed 2026-10-21. ↩

  17. Coalition for Secure AI, "Model Context Protocol (MCP) Security", Workstream 4 draft, 8 Jan 2026. https://www.coalitionforsecureai.org/wp-content/uploads/2026/03/model-context-protocol-security-1.pdf [research], accessed 2026-10-21. ↩

  18. Singapore IMDA, "Model AI Governance Framework for Agentic AI", v1.5, 20 May 2026 (updated 5 Jun 2026). https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf [regulator], accessed 2026-10-21. ↩