What is MCP security?

By Identra · Updated October 3, 2026

MCP security is the practice of protecting AI applications, MCP servers, and connected systems from unauthorized access, data exposure, and harmful tool actions. It combines software security, identity controls, and safeguards against untrusted content influencing an agent's use of legitimate permissions.

Key numbers

43% of tested MCP server implementations contained command injection flaws, and 30% were exploitable via SSRF (Equixly, 2025)
1,862 MCP servers were found exposed to the internet. All 119 manually sampled allowed unauthenticated access to tool listings (Knostic, 2025)
The June 2025 MCP spec revision made RFC 8707 resource indicators mandatory for clients, binding each access token to one specific server (Model Context Protocol specification, 2025)

How does MCP work, and where does trust change?

The Model Context Protocol lets AI applications connect to servers that expose tools, resources, and reusable prompts. An AI application hosts a client that communicates with a local or remote server. A tool might search documents, query a database, or update a support ticket.

Trust changes as information and requests move between the application, server, and downstream service. A server may use a user's delegated access, a service identity, or locally available permissions. It does not necessarily store broad credentials. Security review should establish what each component can read or change, whose authority it uses, and where access restrictions are enforced.

What are the main MCP security risks?

MCP deployments inherit ordinary application risks, including vulnerable dependencies, exposed secrets, command injection, and excessive permissions. They also connect model behavior to real operations. Text that changes an assistant's behavior can therefore affect systems beyond the conversation.

MCP tool poisoning places malicious instructions in tool metadata that an AI application consumes. Tool results and retrieved documents can also carry hostile instructions. Treat these inputs as untrusted even when the connection is authenticated. Authenticating a server establishes who supplied the content, not whether the content is safe to follow.

Excessive permissions
Example
A ticket search tool can also delete tickets
Control
Restrict operations and downstream grants
Prompt injection
Example
A retrieved document requests a private file
Control
Enforce access and action policy outside the model
Compromised server
Example
An installed package reads accessible secrets
Control
Review software and isolate its execution
Token misuse
Example
A server accepts a token intended for another service
Control
Validate the intended recipient and use separate downstream credentials

Risk	Example	Control
Excessive permissions	A ticket search tool can also delete tickets	Restrict operations and downstream grants
Prompt injection	A retrieved document requests a private file	Enforce access and action policy outside the model
Compromised server	An installed package reads accessible secrets	Review software and isolate its execution
Token misuse	A server accepts a token intended for another service	Validate the intended recipient and use separate downstream credentials

How can a normal MCP workflow leak enterprise data?

Consider a hypothetical engineering assistant that can read private repositories and post comments on public issues. A developer asks it to summarize an issue. The issue contains instructions claiming that troubleshooting requires copying an internal configuration file into a public comment.

If the assistant follows those instructions, its legitimate tools could read the file and publish it. This is indirect prompt injection: attacker-controlled content redirects the workflow. The scenario does not require stolen credentials or a compromised MCP server. Read access and external publishing authority create the opportunity together.

A safer design separates public issue triage from private repository access. External publication should require an approval that shows the destination and exact content. The tool layer should reject prohibited destinations regardless of what the model requests. A read-only workflow still needs controls over which private data can enter the conversation.

Does MCP authentication prevent unsafe tool calls?

MCP authentication and authorization protect access to restricted servers. For deployments using MCP's HTTP authorization framework, servers must validate incoming tokens and verify that they are intended for that server. They must not pass the incoming token through to a downstream API. See the official authorization specification.

These checks help prevent credentials from being accepted at the wrong service. They do not establish that a permitted action matches the user's task. An agent with valid access can still request an inappropriate export or deletion.

The confused deputy problem arises when a more privileged intermediary is induced to use its authority for an unauthorized party. Check caller permissions for the requested operation and target resource. Where a proxy obtains downstream consent, bind that consent to the appropriate client. The official security guidance explains this proxy authorization risk.

How should enterprises secure MCP deployments?

Start with the business task and work backward to the access it needs. Apply least privilege to the application, server process, and downstream account. A narrow tool interface is insufficient if the underlying process still has unrestricted credentials.

Inventory approved clients and servers. Record an owner, purpose, deployment location, exposed tools, and downstream access.
Review package origin, dependencies, installation commands, and update behavior. Pin local package versions where practical and review changes before rollout. A remote operator can change server behavior independently.
Run local servers with restricted file, environment, and network access. Avoid exposing unrelated developer secrets to the process.
Limit credentials to required resources and operations. Prefer short-lived credentials where supported, and keep secrets out of prompts and tool descriptions.
Validate tool arguments and enforce resource authorization in server or downstream code. Restrict filesystem paths, outbound destinations, and executable commands.
Require informed approval for sensitive exports, destructive actions, and production changes. Show the actual target and effect before execution.
Assign a revocation owner and test how to disable connections, revoke grants, and stop affected processes.

How do you verify that MCP controls work?

Test permitted workflows alongside explicit denial cases. Try accessing another user's records, calling an unapproved tool, submitting an unexpected path, and publishing to an unauthorized destination. Include hostile instructions in retrieved content. Confirm that enforcement holds even when the assistant attempts the prohibited action.

Keep an AI audit trail that connects the initiating user or agent, server, tool, target, approval, and result where available. Avoid logging secrets or unnecessary sensitive payloads. Investigators need to distinguish a proposed action from a completed downstream change.

Reassess after changes to tools, permissions, server software, or connected services. Practice containment with a simulated compromised server. Verify that revocation blocks subsequent access and identify any downstream sessions or copied data that require separate handling.

How Identra thinks about it

Identra discovers MCP servers on macOS and Windows endpoints, along with the AI clients, coding agents, skills and plugins that use them, and flags AI that hides what it does. AI agent tool calls are checked against policy, and every agent run is recorded with the user, device, AI client and outcome, so teams can see which MCP setups are in use and what agents did with them.

Go deeper: Identra on the endpoint

Frequently asked questions

Is MCP inherently insecure?

MCP adoption alone does not determine security. Risk depends on the implementation, permissions, deployment environment, and controls around model-directed actions.

Are local MCP servers safer than remote servers?

Local servers may have direct access to workstation files, environment variables, and credentials. Remote servers introduce service operator and network trust considerations. Evaluate actual access and isolation in either case.

Can a read-only MCP tool cause data leakage?

Yes. It can retrieve confidential information that an assistant later exposes through an answer or another tool. Read-only access prevents modification through that tool, but does not prevent disclosure.

Does pinning a server version prevent tool poisoning?

No. Pinning can limit unexpected local software changes, but the pinned version may already be malicious or consume hostile content. It also does not freeze the behavior of a separately operated remote service.

Is human approval enough to secure MCP?

Approval helps when the reviewer can see the actual action, target, and data involved. It should support enforceable access restrictions, since vague prompts and repeated approval requests can lead to unsafe decisions.

Compare

All comparisons →