What breaks when MCP tools do not have session context for the requesting user?

Why This Matters for Security Teams

When MCP tools lose session context, the tool no longer knows which user, tenant, or approval boundary the request belongs to. That breaks the basic assumptions behind scoping, attribution, and safe delegation. A request may still look valid at the protocol level, but it becomes impossible to distinguish whether it is acting for a finance analyst, a contractor, or a privileged operator. That is why session context is not a convenience feature; it is a control plane requirement.

This gap shows up quickly in agentic workflows, where tool calls are chained and decisions are made at runtime. Current guidance from the OWASP Agentic AI Top 10 and NIST-aligned access control practices both point to the same issue: authorisation must reflect the actual request context, not just a static service identity. NHIMG research on the State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions.

In practice, many security teams discover this only after a tool has already crossed a tenant or permission boundary, rather than through intentional testing of session propagation.

How It Works in Practice

Session context should travel with the MCP request as a first-class control input, not as an afterthought in application logic. That means the tool broker or orchestration layer needs to pass identity, tenant, role, approval state, and any relevant risk signals into the authorisation decision at request time. The goal is not just to know who called the tool, but what that caller is allowed to do in this exact session.

In secure designs, the tool backend uses that context to enforce policy before any action executes. This is where identity-aware controls, zero trust principles, and policy evaluation converge. A practical implementation may combine NIST SP 800-53 Rev 5 Security and Privacy Controls with runtime policy logic so the tool can reject a request that is valid for one tenant but not another. For agentic systems, the OWASP Agentic Applications Top 10 is a useful reminder that tool misuse often comes from missing context, not just malicious intent.

• Propagate user and tenant context from the session into every MCP tool invocation.
• Bind access decisions to the requesting principal, not only to the service or agent identity.
• Use short-lived, task-scoped authorisation where possible instead of broad standing permissions.
• Log the user context, tool action, and decision outcome together for audit and investigation.

Without this, the tool behaves like a shared backend with no meaningful separation between requesters, so even well-meaning automation can overreach. These controls tend to break down in federated or multi-tenant environments because session identity is often lost at the proxy, gateway, or agent-to-tool handoff.

Common Variations and Edge Cases

Tighter session binding often increases implementation overhead, requiring organisations to balance stronger isolation against integration complexity. That tradeoff becomes sharper in multi-agent systems, where one agent may call another agent’s tools, or where a UI session, background job, and API token all represent the same business workflow but different security contexts.

There is no universal standard for this yet. Best practice is evolving toward context-aware authorisation, but teams still need to choose how much context to propagate and how to handle partial failures when a session expires mid-workflow. Some environments can tolerate fallback to a service account for low-risk read-only tasks, but that exception should be narrow and explicitly approved. In higher-risk workflows, losing session context should be a hard failure, not a silent downgrade.

The risk is highest when MCP tools have write access, tenant-scoped data, or downstream actions that trigger email, billing, or administrative changes. NHIMG’s analysis of the Analysis of Claude Code Security shows how quickly tool autonomy can expand the blast radius when context is weak. In other words, the control problem is not just permissions, but whether the system can still explain who the action was for.

Related resources from NHI Mgmt Group

• What breaks when security tools cannot correlate alerts to application ownership and business context?
• What breaks when an application cannot receive request context about the connecting user or workload?
• What breaks when MCP servers expose all tools to every agent session?
• What breaks when an agent can call tools without user context?