Inspiration
What it does
How we built it
Challenges we ran into
Inspiration
MCP is quickly becoming one of the standard ways for AI agents to connect with tools, APIs, files, databases, and other external systems.
That also means MCP servers are starting to sit in a very important position between AI agents and real infrastructure. And once that happens, security becomes a serious concern.
An MCP server might expose the right tools and appear to work correctly, while still having weaknesses in areas like authentication, authorization, OAuth flows, session isolation, or identity handling.
That led us to a simple question:
How can we verify that an MCP server actually enforces the security boundaries it claims to have?
That question became MCPRift.
What it does
MCPRift is a security testing framework built specifically for MCP servers.
It performs authorized, non-destructive security checks against MCP implementations and collects reproducible evidence for every finding.
Instead of only asking whether a server responds correctly, MCPRift looks at whether its security boundaries are actually being enforced.
It can inspect and test areas such as:
- MCP server capabilities
- authentication and authorization controls
- OAuth 2.0 flows
- PKCE enforcement
- invalid and expired tokens
- redirect URI validation
- state validation
- token passthrough
- identity crossover
- session isolation
- JSON-RPC behavior
- execution and error handling
One of the things we cared about most was making the results useful beyond a simple pass or fail.
For every finding, MCPRift captures structured evidence that developers and security teams can review and reproduce.
Results can also be exported in formats such as JSON and SARIF, which makes the framework easier to integrate into development workflows, CI pipelines, and security reviews.
How we built it
MCPRift is built in Python around the MCP protocol using a modular, probe-based testing architecture.
Each probe focuses on a specific security boundary.
For example, an OAuth test might follow the full flow:
Discovery → Authorization → PKCE → Token Exchange → Protected MCP Request
We intentionally separated the security testing logic from the evidence and reporting layer.
A probe performs an authorized test, observes what happens, classifies the result, and records enough information for someone else to understand and reproduce the finding.
This made the framework easier to extend and helped us keep testing behavior consistent across different security checks.
We also built vulnerable test modes and a local OAuth lab so we could safely validate MCPRift itself without needing to target real production systems.
OAuth and PKCE testing
OAuth became one of the biggest areas of focus during development.
Supporting OAuth does not automatically mean an MCP server is enforcing it correctly, so MCPRift checks several parts of the flow individually.
It can test cases such as:
- OAuth discovery correctness
- audience and scope enforcement
- invalid token handling
- expired token handling
- S256 PKCE enforcement
- state validation
- one-time authorization code usage
- redirect URI validation
- token passthrough
- identity crossover
These checks help uncover situations where OAuth is technically present, but the actual security boundary around it is weak or incorrectly implemented.
Evidence-first security testing
A security finding is much more valuable when someone can reproduce it.
That is why MCPRift is designed around an evidence-first approach.
Instead of only printing a warning like “authorization failed,” the framework captures the context around the test.
Reports can include:
- the security condition that was tested
- the expected behavior
- the observed behavior
- the final pass or fail result
- relevant protocol responses
- execution classification
- remediation context
This makes the findings easier for developers to investigate and much more useful during a security review.
It also helps reduce ambiguity. Rather than simply saying something looks wrong, MCPRift shows what happened and why the result matters.
Challenges we faced
One of the hardest problems we ran into was testing authentication boundaries without accidentally carrying trusted state from one probe into another.
During development, we discovered that reusing an authenticated connection across multiple tests could affect later results.
A probe that was supposed to test an unauthenticated request might accidentally inherit authentication from an earlier session.
To solve this, we changed the architecture so security-sensitive probes can create clean, unauthenticated sessions whenever needed.
Another challenge was separating a normal protocol failure from an actual security failure.
Those are not always the same thing.
For example, a server returning an error does not automatically mean its authentication or authorization controls are working correctly.
The important question is whether the server rejected the request for the right security reason.
Because of that, MCPRift carefully classifies execution behavior and checks whether the expected authentication and authorization boundaries are genuinely being enforced.
Accomplishments
We are especially proud of how much MCPRift now covers.
The framework currently supports:
- authorized MCP security inspection
- authentication and authorization testing
- OAuth 2.0 security testing
- PKCE verification
- session-boundary testing
- token-passthrough detection
- identity-crossover testing
- JSON-RPC validation
- structured evidence capture
- JSON reporting
- SARIF reporting
- strict HTTP 401/403 handling
- reproducible vulnerable test environments
From the beginning, we did not want MCPRift to become just another generic security scanner.
We wanted to build something specifically around the security assumptions and failure modes of MCP and AI-agent infrastructure.
What we learned
Building MCPRift made one thing very clear: securing an AI tool ecosystem is not only about securing the API behind it.
There is an entire chain involved:
Agent → MCP Client → MCP Server → Authentication → Tool
Each layer introduces its own trust boundary, and each boundary can behave differently.
A secure backend does not automatically guarantee a secure MCP integration.
We also learned how important reproducibility is in security tooling.
A finding becomes much more useful when it is deterministic, backed by clear evidence, and easy for a developer to recreate without guessing what went wrong.
That principle ended up shaping a large part of MCPRift's architecture.
What's next
There is still a lot we want to explore.
Some of the next areas for MCPRift include:
- broader MCP authorization testing
- additional session-boundary probes
- deeper CI integration
- automated finding correlation
- stronger and more actionable remediation guidance
- testing against more real-world MCP server implementations
- expanding the vulnerable lab for reproducible security research
As MCP adoption continues to grow, we want MCPRift to become a practical way for developers and security teams to answer one important question:
Can I trust this MCP server with an AI agent?
Accomplishments that we're proud of
What we learned
What's next for MCPRift
Built With
- api
- authentication
- authorization
- cli
- cybersecurity
- fastapi
- github-actions
- json-rpc
- mcp
- model-context-protocol
- oauth-2.0
- oauth-security
- pkce
- pytest
- python
- sarif
- security
- security-testing
- uv
Log in or sign up for Devpost to join the conversation.