OWASP MCP Top 10 Explained: Risks, Examples, and a Security Testing Checklist

Model Context Protocol makes it easier for AI applications to discover and use external tools and data. That convenience also creates a new concentration of trust. A connected agent may interpret server-provided metadata, choose capabilities dynamically, supply arguments shaped by natural-language context, and execute requests with credentials more powerful than the user.

The OWASP MCP Top 10 project provides a useful taxonomy for these risks. As of August 2026, OWASP identifies the current list as a beta release with a later release planned, so names and guidance may continue to change. Security teams should use it as a threat-modelling and testing baseline, not as a certification. MCP implementations vary, and a checklist cannot prove that every combination of client, model, server, tool, and permission behaves safely.

This guide explains the major risk families in practical terms and shows how to turn them into an authorised assessment.

1. Token mismanagement and secret exposure

MCP servers and clients may handle provider keys, OAuth tokens, API credentials, service-account secrets, and user delegation. Secrets can leak through environment variables, logs, tool results, error messages, model context, exported transcripts, or overly broad server access.

Testing should determine which credentials each component can access, whether they appear in model-visible context, how they are stored, and whether they are scoped by user, tenant, task, and time. Use synthetic canaries—not real secrets—to test accidental disclosure. Verify rotation and revocation and observe what happens to active sessions after access is removed.

Defence begins with secret isolation, short-lived credentials, least privilege, redaction, secure storage, and a design where the model never needs to see raw secrets.

2. Excessive permissions and scope

A tool can be correctly authenticated and still be dangerously over-authorised. Common examples include a support lookup tool backed by an organisation-wide token or a file tool that can read the entire host when the workflow needs one directory.

Compare the user's direct authority with the practical authority of every tool. Test alternate tenant IDs, record IDs, paths, recipients, environments, and operation types. Confirm server-side identity binding; do not accept a prompt-level instruction to “only access the current customer” as enforcement.

The remediation is architectural: narrow credentials, purpose-built operations, resource scoping, explicit policies, and approval for high-consequence actions.

3. Tool poisoning and untrusted metadata

MCP tool names, descriptions, schemas, examples, and annotations influence model decisions. A malicious or compromised server can embed instructions that redirect the agent, request unrelated data, invoke another tool, or conceal activity.

Capture and diff exact metadata. Test changed descriptions in an isolated environment using harmless canaries. Evaluate the complete tool set because a low-privilege poisoned server may steer a higher-privilege capability. Our detailed MCP tool-poisoning guide covers shadowing, rug pulls, and evidence collection.

Treat metadata as untrusted, display provenance, pin approved definitions, alert on changes, namespace tools by server, and enforce sensitive restrictions outside the model.

4. Supply-chain and dependency compromise

MCP deployments depend on packages, container images, remote servers, SDKs, generated configurations, registries, and update channels. Traditional dependency risks remain, but MCP adds semantic risk: a component can alter descriptions or results without exploiting code execution.

Inventory versions and owners, pin dependencies, verify sources and signatures where available, scan components, review update behaviour, and retest after change. Determine whether a remote server can silently introduce new tools or modify existing definitions.

Supply-chain review should include both what runs and what the agent is told.

5. Command, path, query, and argument injection

Tool schemas often wrap powerful backends. A string parameter may reach a shell, SQL query, URL fetcher, file path, search filter, template, or interpreter. Typed JSON does not make the value safe.

Trace parameters to their sinks and test unexpected separators, encodings, large values, alternate protocols, internal addresses, path traversal shapes, wildcard selectors, and values copied from other tools. Use non-destructive payloads and isolated targets.

Prefer structured operations over general-purpose execution. Apply allowlists, canonicalisation, parameterised queries, filesystem sandboxes, egress controls, resource limits, and backend authorisation.

6. Intent flow subversion

An MCP server can return context that includes malicious or misleading instructions. The agent may treat the result as guidance for its next step, allowing the original user intent to be replaced or redirected. This is intent flow subversion: the protocol response becomes a secondary instruction channel.

Test whether result content can change tool selection, arguments, memory, or outbound communication. Label result provenance and prevent tool output from overriding client policy. Limit what one tool's output can influence and apply independent authorisation to every subsequent action.

Read Indirect Prompt Injection in RAG and Tool-Using Agents for complete attack paths and safe canary methods.

7. Insufficient authentication and authorization

MCP ecosystems connect users, clients, agents, servers, and backend services. If any handoff fails to authenticate the caller or enforce resource-level authorization, an attacker can impersonate a component, reuse a token, or ask a legitimate tool to access an unauthorized resource.

Review server authentication, OAuth flows, token audience and scope, redirect handling, local process permissions, user delegation, tenant binding, and backend object authorization. Test whether a user can substitute another resource identifier or whether one agent can invoke a server under another agent's authority.

Transport security remains necessary, but encrypted traffic alone does not establish appropriate authority. Verify who is acting, for which user and task, against which resource, on every consequential call.

8. Insufficient logging and auditability

MCP incidents are hard to investigate when logs record only the final chat response. Teams need the server identity, tool definition version, selected tool, arguments, authenticated actor, policy decision, result classification, approval, and downstream action.

Verify that logs can reconstruct a decision-to-action chain without storing unnecessary secrets. Protect them with access controls, retention, redaction, and tamper resistance. Correlate client and server timestamps and ensure each request has a durable identifier.

A useful finding should be independently reviewable from evidence, not from the tester's interpretation alone.

9. Shadow MCP servers

Shadow MCP servers operate outside the organisation's expected inventory, ownership, or review process. They may be installed locally by developers, bundled into unofficial agent configurations, exposed remotely for convenience, or left running after a prototype ends.

Discover them through configuration review, process and endpoint inventory, identity grants, source repositories, package records, and developer outreach. For every server, identify its owner, origin, users, tools, credentials, network exposure, data reach, and retirement path. Prioritise systems with sensitive data, code execution, filesystem access, or broad service tokens.

Bring useful servers into a sanctioned lifecycle rather than treating discovery as a purely punitive exercise. Test onboarding, version changes, rollback, disablement, credential revocation, and deletion. Alert when a server adds capabilities or requests broader scope.

10. Context injection and over-sharing

MCP clients and servers may provide more context than a tool needs: full conversations, internal instructions, credentials, retrieved documents, personal data, or results from other tools. A malicious or compromised component can also inject content intended to influence the model.

Map the context sent to each server and minimise it by task. Test whether one tool receives unrelated conversation history, another tenant's data, hidden system instructions, or unnecessary secrets. Introduce harmless instruction canaries in controlled tool results and observe whether they influence subsequent calls, memory, or output.

Apply field-level minimisation, provenance labels, redaction, tenant isolation, output validation, and restrictions on how low-trust results influence high-trust actions. Treat context as sensitive data and untrusted instruction at the same time.

Additional operational risk: denial of service and uncontrolled resource use

Although it is not the current MCP10 label, availability still deserves testing. A server or malicious result can induce loops, repeated retries, oversized responses, deep recursion, expensive model calls, or high-volume tool execution.

Test timeouts, malformed streams, partial results, large payloads, duplicate events, circular dependencies, and rate-limit responses. Enforce size limits, execution budgets, bounded retries, circuit breakers, concurrency limits, cancellation, and idempotency for side effects.

A practical MCP assessment plan

Begin with architecture and inventory. Record clients, servers, transports, tools, definitions, credentials, users, data stores, side effects, and network paths. Classify tools by maximum impact: read-only public data, sensitive read, external communication, state change, privileged administration, or code execution.

Define unacceptable outcomes and safe substitutes. Use synthetic tenant records, canary files, mock transactions, and controlled recipients. Agree on scope, rate, time window, prohibited actions, and escalation before testing.

Run the assessment in layers:

1. Review transport, configuration, authentication, and dependencies.
2. Enumerate and diff tool metadata.
3. Test each tool's arguments and backend authorisation.
4. Test the connected agent's tool selection over multiple turns.
5. Introduce untrusted tool results and metadata using canaries.
6. Combine tools to evaluate cross-capability risk.
7. Test lifecycle changes, revocation, and degraded conditions.
8. Preserve evidence and retest confirmed findings.

What a report should distinguish

Do not collapse every concern into “MCP is vulnerable.” Separate server implementation bugs, client trust failures, agent behaviour, excessive permissions, and deployment configuration. State whether an action was attempted, blocked, executed, or confirmed to create impact.

For every finding, include expected boundary, exact metadata or input, tool calls, arguments, identity, result, transcript, validation level, and remediation ownership. If two weaknesses were not replayed as an end-to-end chain, label their relationship as a hypothesis.

How MCP testing fits broader agent security

MCP is one layer of the implementation. The same agent may also expose web and API routes, use RAG, retain memory, and operate across user sessions. A secure server can still participate in an unsafe system if the agent selects it under manipulated context or passes another user's identifier.

Oxyne tests supported MCP servers and tool-using agents through exposed interfaces, including tool inventory, arguments, authorisation boundaries, multi-turn selection, and transcript evidence. This is not a claim of runtime enforcement, source access to every server, or complete enterprise permission discovery.

The OWASP MCP Top 10 is most useful when it changes engineering practice: treat metadata as input, bind authority outside the model, narrow every tool, monitor lifecycle changes, and validate the behaviour of the connected system rather than approving a schema once.

A pre-production evidence pack

Before approving an MCP integration, retain the server owner and source, deployed version, transport and authentication method, complete runtime tool definitions, requested permissions, credential scope, data destinations, threat model, static review results, behavioural test results, and disablement procedure.

For high-risk tools, include direct evidence that backend authorisation holds. A transcript where the model refuses an alternate customer identifier is weaker than a server log showing that the API rejected it independently. Keep both when available: one describes agent behaviour; the other confirms enforcement.

Document remote dependencies and update behaviour. If a server can change its definitions or code outside the client's release process, state how the organisation detects and approves that change.

Testing multiple MCP servers together

Single-server review misses composition. Build a test matrix showing which tools can pass data to which others. Pay special attention to combinations of sensitive read plus external send, file access plus code execution, browser access plus credentials, and low-trust metadata plus privileged action.

Introduce a benign instruction through one server and observe whether it changes use of another. Verify tool namespaces and provenance in logs and approvals. Test ambiguous names and conflicting descriptions. Ensure that disabling one server does not cause the agent to fall back to a more powerful alternative silently.

Retesting after remediation

If a command-injection sink was fixed, test alternate encodings and confirm structured invocation at the backend. If a credential was narrowed, test real denial outside scope. If metadata was cleaned, verify that server change monitoring and client policy prevent a recurrence.

Retest with the current model and client because selection behaviour can change independently of server code. Preserve known cases as a regression suite and rerun them after material updates.

Common programme mistakes

Teams often approve a server because its repository is popular, scan only the server while ignoring the connected client, or review schemas without following parameters into backend authority. Another common mistake is treating TLS as server trust or assuming a read-only tool cannot participate in exfiltration.

The corrective principle is consistent: evaluate source, metadata, implementation, permission, composition, and observed agent behaviour as separate but connected layers.

Questions for MCP server owners

• Which users and agents are expected to connect?
• Which identities and secrets does the server hold?
• Can definitions change without client approval?
• Which parameters control tenant, path, destination, or authority?
• Are sensitive scopes bound server-side?
• What data enters model-visible results and logs?
• Can tools call external networks or execute code?
• How are versions, incidents, revocation, and retirement handled?

Clear answers make security review faster and identify where behavioural testing adds the most value.

Questions for MCP client owners

Clients determine how metadata enters context, how tools are selected, what users see, and which combinations are possible. Document server authentication, namespace handling, definition pinning, approval UI, policy enforcement, context minimisation, and audit logs.

Test whether the client preserves provenance after a tool result is summarised or passed to another agent. Confirm that users cannot enable a high-risk server without the organisation's intended approval path.

Risk-based testing depth

A local read-only tool over public data may need inventory, source review, and baseline testing. A server with customer data, filesystem access, external communication, financial action, or code execution needs deeper argument testing, composition analysis, change monitoring, and incident exercises.

Apply controls to reachable consequence rather than treating every MCP integration as equally dangerous—or equally safe.