MCP security risks and considerations: What IT teams need to check

MCP (Model Context Protocol) is the open standard that connects AI assistants like Claude and ChatGPT to external apps and data. In the business world, MCP adoption has accelerated dramatically, placing security and IT teams in a somewhat precarious position. In May 2026, the NSA published its security guidance for MCP, which notes that the protocol "requires careful and cautious implementation" and that its "rapid proliferation has outpaced the development of its security model."

At the same time, there are ways to utilize MCP that are entirely safe and IT-friendly. This guide covers the principal MCP security risks and shows you how to mitigate each one.

Top MCP security risks

The risks below aren't all specific to MCP, and several apply to AI models generally. But because MCP connects agents to business apps that may contain sensitive data, it raises the stakes for each one.

Prompt injection

Prompt injection hides instructions inside content the AI reads (like in a document, email, web page, or support ticket). An AI can't always tell your request apart from the malicious text, so it may follow hidden instructions without you realizing it.

In 2025, researchers at General Analysis showed an agent leaking a private SQL table. An AI agent read a support ticket containing hidden instructions, then copied private integration tokens into a reply the attacker could see. The attack worked on a standard setup, where the agent connected through an admin-level account that skipped the database’s row-level security.

How to protect against it: Give an AI only the access it needs for the task at hand, and require approval before any write or delete action. There's no one filter that can catch every injected instruction, so limiting what a tricked AI can do is your best bet.

Tool poisoning, rug pulls, and other malicious connectors

A connector tells the AI what it can do through tool descriptions. The AI reads those descriptions, but the user usually never sees them (unless they specifically ask). Because of that, these three potential risks emerge:

• Tool poisoning: A connector could hide malicious instructions in its tool descriptions. In an April 2025 test by Invariant Labs, a connector offered a simple tool for adding two numbers, but its hidden description told Cursor to read the user’s SSH private key and send it to the attacker’s server.
• Rug pulls: A connector could work normally when you approve it, but then change its tools in a later update.
• Tool shadowing: A malicious connector can imitate a trusted one, or its descriptions could prompt the AI to change how it uses a trusted connector's tools.

How to protect against them: Only allow connectors from a trusted software vendor or from a list IT has reviewed. Recheck tool descriptions after updates. For local servers, the official MCP security guidance says that AI apps must show the full command and get explicit approval before they run it.

Excessive permissions and the confused deputy

A connector with excessive permissions can do far more than the task dictates. You might have one that only needs to read a CRM but is also allowed to edit and delete records. A single mistake or injected instruction could then lead to real data changes.

The confused deputy problem poses a similar risk. It's when an AI acts with its own broad access instead of the access of a given user (so an intern's request runs with admin rights). The official MCP guidance uses the term for a narrower attack on OAuth proxy servers, but the principle is the same.

How to protect against them: Start with read-only access, and add write access per team or user when there's a clear need. The MCP guidance recommends a small starting set of permissions that grows only when a privileged action is required. You should also stick to connectors that act as the signed-in user (more on this below).

Exposed credentials and token passthrough

Credentials often leak through plain-text storage, with many local connectors reading API keys or personal access tokens from a config file on the laptop.

Token passthrough is a design flaw on the server side. The MCP server accepts a login token that was issued for another service and forwards it downstream. That skips the checks the downstream service relies on, and its logs no longer show who made the request. The MCP authorization spec forbids it. Servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server."

How to protect against them: Prefer connectors that use OAuth, where each person signs in with their own account and tokens expire automatically. Keep keys in a secrets manager instead of easily accessible config files, and rotate any key that's been shared.

No audit trail

Without a record of which tools ran and which users and data were involved, you won't be able to investigate incidents. Shared API keys make it even worse, because every action appears as if it was taken by one account. Token passthrough has the same effect, since the server can't tell which client sent a request.

In June 2025, Asana found a bug in its MCP server that had shown data from roughly 1,000 customers to users at other organizations. Admins were told to check their MCP access logs to see what had been exposed. Without those logs, there’d be no way to know what data left your organization.

How to protect against it: Use per-user sign-in so that every action traces back to a real person. Then log the fields listed in the checklist below.

Which safeguard stops each MCP risk

The official MCP guidance covers three core safeguards: the AI app (which it calls the client), the connector (the MCP server), and the company login system (the authorization server). The fourth, a gateway, is an optional layer IT can add.

• The AI app: The tool the employee uses, such as Claude or ChatGPT. It can ask before each action or block specific tools.
• The connector: The MCP server itself. It dictates what the AI can access, how sign-in works, and how long logins last.
• The company login system: Your identity provider, such as Okta or Microsoft Entra ID. It decides who can sign in and removes access when someone leaves.
• A gateway: A central checkpoint IT places between AI apps and connectors. It enforces an approved list and logs traffic in one place.

The risk of employees installing connectors on their own

Adding an MCP connection can be done in just a click or two in most AI apps. This means people who have never handled an API key can give an AI access to shared drives, CRMs, databases, and other systems.

So, treat connectors like you would any other software purchase or install. This brief policy covers the bulk of the risk:

1. Approved list: Enable only IT-approved connectors and block custom servers by default. Most AI apps now offer this control at the organization level.
2. Admin-only setup: Let admins add connectors for the whole organization, so employees choose from the approved list.
3. Review step: Give employees a short form to request a new connector. Check what data it can reach and whether it comes from the software vendor or a third party.
4. Regular cleanup: Periodically recheck tool descriptions after updates and remove connectors nobody uses.

If your approved list grows unwieldy, consider setting up a gateway. It enforces the list, holds credentials in one place, and logs every call, regardless of which AI an employee uses.

Does the AI see what the user sees?

Safe connectors have the same exact access rules as the signed-in user. Each user connects with their own account through OAuth, so the AI sees only what that person can see in the app. Actions show up under that same user's name, and removing their account also removes the AI's access.

The alternative is a shared service account, usually one with wide access. Everyone's AI acts through that shared account, meaning a junior teammate's assistant using MCP has the same reach as an admin. That was the problem in the Supabase case above, where the service role bypassed row-level security.

But if an app limits which records each person sees, the MCP connection should respect those same limits. Before you approve a connector, ask the vendor whether it runs as the user or as a service account.

Checklist: Connecting AI to business data safely

Refer to this list when you review a connector to ensure it's safe for your team to use:

Access

• Read, write, and delete permissions are separate and controllable.
• Access can be limited per workspace, team, or user.
• The AI acts as the signed-in user, not through a shared service account.
• Write and delete actions require approval in the AI app.

Sign-in

• The connector uses OAuth, not a personal access token pasted into a config file.
• Tokens expire and users must sign in again on a regular schedule.
• Removing someone from your login system removes their AI access. SCIM provisioning does this automatically on platforms that support it.

Logging

For every AI action, record:

• The person who made the request
• The AI they used
• The connector and tools that ran
• The data sent and returned
• The result, including errors and denied requests

Data

• You know where the connector stores and processes data (and in which region).
• The vendor can share a security report, such as a SOC 2 Type II report.

What does good MCP implementation look like?

Here's how we handle MCP risks at Softr, as one example of a business-app connector. Softr has two MCP servers: the Softr MCP is for builders who create and manage apps, databases, and workflows; the App MCP Server is for the end users of published apps.

• Scoped sign-in: When a builder connects the Softr MCP, the sign-in screen sets which workspaces the AI can reach. It also sets access for Applications and Forms, Databases, and Workflows, from no access to full edit.
• The AI inherits each user's permissions: Every App MCP Server request runs as the signed-in user. Their user groups and permissions, page visibility, and data restrictions apply exactly as they do in the app. Global data restrictions are available on the Business plan and up.
• No block, no access: What the AI can do mirrors the app's screens. A list block allows reading, a form allows creating, and data not shown by any block can’t be touched at all.
• Approval in the AI app: Most AI apps add a second permissions layer. In Claude, each tool can be set to always allow, needs approval, or blocked.
• Credentials stay server-side: Integration credentials and API keys for connected data sources are encrypted and kept on Softr's servers, outside browser code.
• Enterprise controls: On the Enterprise plan, SSO works with any standard SAML or OIDC provider (e.g., Okta). SCIM provisions and removes users automatically, and application and database audit logs show who changed what and when across every project in your workspace.

Softr has a SOC 2 Type II report and is GDPR compliant. See our security page for more details.

Start with an approved list and per-user sign-in

Most MCP security work comes down to which connectors employees can use and whose permissions the AI runs with. Set an approved list first, then prefer connectors that act as the signed-in user rather than under shared credentials.

For your own business data, an app with per-user permissions gives the AI the same rules as everyone else. Sign up free to try Softr MCP on your own app.