Bright Security just published a detailed analysis of MCP security in 2026. The headline finding: MCP introduces a separate session lifecycle and identity context that exists independently of the application's authentication model.
This is bigger than it sounds.
The Problem
In their analysis of Broken Crystals (a benchmark vulnerable application with a dedicated MCP surface), they found that MCP sessions:
- Initialize separately from the regular application flow
- Use their own
Mcp-Session-Id - Can exist in guest, authenticated-user, or admin contexts
- Are not necessarily bound to the application's identity layer
This creates a parallel trust boundary. The agent's MCP session may have different permissions than the user whose account triggered the agent. Or the MCP session may have no identity at all — just a session ID with no cryptographic binding to anyone.
Bright Security's framing: "Security teams now have another session model to reason about. If agent sessions, tool permissions, and backend authorization do not line up exactly, gaps appear."
Why This Matters
Traditional AppSec assumes request-response patterns where the caller's identity is verified on every request. MCP changes this:
Tool discovery is built in. The agent calls
tools/listand the MCP server tells it everything available — including admin-only capabilities. The attack surface is organized, named, and ready for invocation.Chained behavior, not isolated calls. An agent can enumerate tools, establish session context, test permissions, and chain actions across multiple backend systems — all within a single MCP session.
Proxy risk. Most MCP tools simply wrap existing backend capabilities. SQL queries, file reads, template rendering, command execution — all accessible through a structured, agent-friendly interface.
Streaming breaks observability. MCP supports event-stream responses with progress notifications and partial output. Standard request-response monitoring misses this entirely.
The Identity Gap
Here's what Bright Security's analysis makes clear but doesn't solve: the MCP session identity problem is a symptom of the larger agent identity problem.
When an MCP session initializes, who is the agent? Not the user who triggered the workflow — the agent is a separate entity making its own decisions about which tools to call and in what order. The Mcp-Session-Id identifies the session, not the agent.
This is the confused deputy problem applied to tool access. The agent acts on behalf of a user but has its own session, its own tool access, and its own decision-making. Without cryptographic identity binding, there is no way to:
- Verify which specific agent initiated the MCP session
- Audit whether the agent's tool invocations were authorized by its principal
- Detect if one agent is impersonating another through session manipulation
- Trace tool chains back to a verifiable identity
What Would Fix This
Bright Security recommends treating every MCP server as a production application surface — not middleware. They're right. But the fix needs to go deeper than perimeter security.
Each MCP session should be bound to a cryptographic agent identity — not just a session token. The agent should sign its tool invocations. The MCP server should verify the agent's identity before granting tool access. And the entire tool chain should be attributable to a specific, verifiable agent DID.
We built this for exactly this reason. AIP gives every agent an Ed25519 keypair and a DID. Request signing, peer verification, and trust discovery are built into the identity layer — not bolted on after the fact.
The MCP session identity gap is solvable. But it requires treating agent identity as infrastructure, not as an afterthought.
The Bigger Picture
Bright Security's analysis, Microsoft's RSAC 2026 Agent 365 announcement, the BizTech Magazine piece on RSAC sessions focused on non-human identities — they all converge on the same conclusion: traditional IAM was not built for autonomous agents that maintain their own sessions, discover their own tools, and make their own decisions.
The AppSec playbook needs to expand. But the identity playbook needs to expand first.
Source: Bright Security — MCP Security in 2026
AIP is open source: github.com/The-Nexus-Guard/aip — pip install aip-identity
Top comments (0)