If you test the Model Context Protocol (MCP) like a standard API, you’ll miss the vulnerabilities attackers are most likely to exploit.
MCP introduces dynamic interactions between agents, servers and tools across multiple trust boundaries. This architecture creates attack surfaces that traditional testing approaches weren’t designed to handle. The MCP security specification defines six critical threat vectors and five mandatory authorization patterns. Your testing methodology needs to validate each one.
When your testing framework expects simple request-response patterns, how do you validate security for systems where agents orchestrate tools, authorization decisions depend on per-client consent and token handling must follow strict prohibitions? The answer lies in methodologies that understand MCP-specific threats and systematically verify the controls the specification requires.
Why Traditional Security Tools Miss MCP Vulnerabilities
Standard API security scanners were built for stateless endpoints with predictable request-response cycles. MCP interactions break these assumptions in ways that create blind spots.
The Confused Deputy Problem Requires Relationship Testing
The most common MCP-specific vulnerability is the confused deputy problem, where an attacker tricks a legitimate client into performing unauthorized actions. Traditional scanners test individual endpoints in isolation. They can’t detect scenarios where Application B exploits authorization granted to Application A because the MCP server fails to validate per-client consent.
Testing for confused deputy vulnerabilities requires simulating multiple client applications with different authorization levels, then attempting cross-client access. A scanner that only tests one client at a time will never catch this.
Token Handling Has Absolute Prohibitions
The MCP specification explicitly forbids token passthrough, where servers forward authentication tokens through intermediaries rather than validating them directly. Standard security tools don’t test for this pattern because most protocols don’t prohibit it. Your testing must verify that tokens are validated directly against the authorization server at each hop, not relayed through the chain.
The specification also requires that session-based authentication must not substitute for per-request token validation. MCP servers must validate tokens on each request, meaning implementations that rely on HTTP-based session state as their sole authentication mechanism are noncompliant. However, cookies used alongside token-based auth for purposes like CSRF protection don’t violate this requirement. Testing tools built around session-only management patterns will produce false negatives because they’re testing controls that shouldn’t exist as standalone mechanisms in a compliant implementation.
Authorization Patterns Are Highly Specific
The five mandatory authorization patterns each create testable requirements that generic scanners miss:
Per-client consent requires testing that user authorization is recorded and enforced per client application, not as blanket grants. Token audience validation requires testing that tokens with incorrect aud claims are rejected even when properly signed. Exact redirect URI matching requires testing that URIs with additional query parameters or path segments are rejected. OAuth state parameter validation requires testing that missing or mismatched state values cause authorization failures.
Generic OAuth testing might verify that authentication works. MCP-specific testing must verify that these precise patterns are enforced without exception.
Testing the Six Critical Threat Vectors
Your testing methodology should systematically address each threat the MCP specification identifies.
1. Confused Deputy Testing
Create test scenarios with multiple simulated client applications. Register Client A with specific consent grants, then attempt to access those resources using Client B’s credentials with the same user authentication. Verify that the MCP server maintains a per-client consent registry and rejects requests from clients without explicit authorization.
Test the consent interface itself. Verify it clearly identifies which client is requesting access, what resources will be accessible and the authorization duration. Attempt social-engineering scenarios where vague consent prompts might trick users into over-granting permissions.
2. Token Passthrough Testing
Instrument your test environment to trace token flows through the system. Verify that each MCP server validates tokens directly against the authorization server rather than accepting tokens forwarded from upstream components. Inject marked tokens and confirm they’re validated at each trust boundary, not simply passed through.
Test token audience validation by presenting valid tokens issued for different services. A properly implemented MCP server must reject these tokens even though they’re correctly signed and unexpired.
3. Session Hijacking Prevention Testing
Verify that session-based authentication does not substitute for per-request token validation. Attempt to authenticate using only cookies or server-side session state without accompanying token validation. A compliant MCP implementation should reject authentication that relies solely on session state. Note that implementations may use cookies for CSRF protection or UI state alongside token-based auth without violating this requirement.
Test token expiration and rotation. Access tokens should have short lifespans, typically minutes rather than hours, with the exact duration calibrated to your security requirements. Refresh tokens should rotate on each use, with old tokens invalidated immediately.
4. SSRF Testing
Test that the MCP client validates all URLs sourced from OAuth metadata discovery before following them. Attempt to supply internal IP addresses, link-local addresses such as 169.254.169.254 and loopback addresses in discovery fields like resource_metadata, authorization_servers, jwks_uri and token_endpoint. A compliant implementation should reject these rather than fetch them.
Test redirect chains using the same logic: each hop should be validated against the same rules as the original URL rather than followed automatically. Verify that HTTPS is enforced for all OAuth-related URLs in production, with plain HTTP rejected. For DNS rebinding, simulate a domain that resolves safely during metadata validation but to an internal address at request time and confirm the client does not proceed. Where an egress proxy is deployed, verify it blocks requests to internal destinations rather than relying on application-layer checks alone.
5. Local Server Security Testing
For MCP servers running locally, test explicit consent requirements for file system operations and command execution. Attempt directory traversal attacks using ../ sequences, URL-encoded variants, double encoding and Unicode variations. Verify that paths are resolved to absolute form and validated against allowed directories.
Test command injection by including shell metacharacters in inputs: semicolons, pipes, ampersands, backticks and $() substitution. A secure implementation should use parameterized command execution or strict allowlists, never string concatenation.
Verify that local servers prefer stdio transport over network-based transport where applicable. Stdio avoids exposing a network port entirely, which removes the local attack surface that HTTP- or SSE-based transports create. Test that any network listeners are disabled or restricted to loopback addresses when stdio is available.
6. Scope Minimization Testing
Review OAuth scope requests to verify implementations request the minimum necessary permissions. Test that agents with read-only authorization cannot perform write operations even when tools support both. Attempt privilege escalation by requesting broader scopes than the workflow requires.
Validate Mandatory Security Requirements
The MCP specification establishes requirements that aren’t optional hardening but mandatory controls. Your testing must verify each one.
Transport Security Validation
HTTPS is mandatory for all MCP communication with no exceptions. Test that HTTP connections are rejected at the network level, not redirected. Verify Transport Layer Security (TLS) 1.2 minimum with TLS 1.3 preferred. Test cipher suite configuration to confirm weak ciphers (RC4, DES, 3DES) are disabled. Verify HSTS headers are present.
Test certificate validation by presenting expired certificates, self-signed certificates and certificates with incorrect hostnames. All should fail in production configurations.
Input Validation Testing
The specification requires schema-based validation for all input parameters. Test with missing required parameters, incorrect types, values outside acceptable ranges and oversized inputs. All should be rejected with Tool Execution Errors per the protocol specification.
File path inputs require sanitization testing. Test traversal sequences, absolute paths outside allowed directories and encoded variations. Command inputs require injection testing with the full range of shell metacharacters and command-substitution patterns.
OAuth Flow Testing
Test redirect URI validation with exact matching requirements. Registered URI https://app.example.com/callback should accept only that exact string. Test variations with additional query parameters, path segments, different subdomains and protocol changes. All variations must be rejected.
Test state parameter handling throughout the OAuth flow. Generate a state value, initiate authorization, then attempt to complete the flow with a missing state, incorrect state or reused state from a previous flow. Each scenario must fail.
Build Observability for Continuous Validation
Testing validates controls at a point in time. Observability validates them continuously in production.
Log the Right Events
Capture authentication events, including OAuth authorization attempts, token issuance and validation, failed authentication with source details and token revocation. Capture authorization events, including consent grants and revocations, client ID validations, redirect URI checks and state parameter validations. Capture operation events, including tool invocations with sanitized parameters, access decisions with policy details and input validation failures.
Structure logs with consistent formats and indexed fields for fast searching. Integrate with SIEM platforms that can correlate MCP events with broader security telemetry.
Establish Behavioral Baselines
Track which agents typically invoke which tools, in what combinations and with what parameters. Deviation from baselines indicates potential compromise. An agent that suddenly invokes administrative tools or accesses resources outside its normal pattern warrants investigation.
Monitor for the specific attack patterns the MCP specification identifies. Watch for attempts to use authorization granted to other clients (confused deputy). Alert on tokens being forwarded rather than validated (token passthrough). Flag any session-based authentication attempts that bypass per-request token validation.
Prepare Incident Response
Define response procedures for each threat vector. For token compromise: immediately revoke the token, invalidate associated refresh tokens and block suspicious source addresses. For confused deputy attacks: suspend the affected client’s access and audit the consent registry. For injection attacks: isolate the affected server, block malicious patterns at the gateway and preserve logs for forensics.
Retain logs for at least 90 days for compliance, with 1 year recommended for security investigations. Store logs in tamper-evident systems with encryption at rest.
Integrate Identity-First Security Testing
MCP environments are dominated by non-human identities, with agents and workloads that authenticate via tokens and cryptographic attestation rather than passwords and MFA. These identities now outnumber humans by as much as 144:1. That ratio grew 56% in just one year, and it continues to expand the attack surface that security teams must govern.
Your testing methodology must account for this. Test workload identity federation scenarios in which agents prove identity through environmental attestation rather than static credentials. Verify that short-lived tokens are issued just-in-time and scoped to specific operations. Test that secretless access patterns eliminate long-lived credentials that create persistent attack vectors.
Test conditional access policies that evaluate real-time security posture. An agent on a compromised host should receive different authorization than one in a verified secure environment. Verify that policies adapt to changing conditions rather than relying solely on static identity verification.
Aembit provides workload IAM purpose-built for these testing scenarios, with cryptographic identity attestation, policy-based access control and audit trails that give security teams visibility into every non-human identity interaction across MCP deployments.
