What breaks when teams assume MCP session context will preserve accountability?

Accountability breaks when the protocol no longer remembers the session, because attribution, purpose, and scope can no longer be inferred from connection history. Teams then need identity-native evidence such as token exchange records, ownership mapping, and request-level authorization logs.

Why This Matters for Security Teams

Teams often assume MCP session context will preserve enough history to reconstruct who did what, but that assumption collapses when the session ends, rotates, or is proxied through another component. Once attribution depends on memory rather than evidence, accountability becomes fragile. That is especially dangerous for autonomous tool use, where a single agent may chain multiple calls across systems, each with different scope and owners.

Current guidance suggests treating session state as operational convenience, not as a source of trust. The risk is not limited to logs going missing. It also includes unclear purpose, stale ownership, and permission drift when an agent continues acting after the original context has changed. This is why identity-native records matter more than connection continuity. NHIMG’s AI Agents: The New Attack Surface report shows how quickly visibility gaps become governance failures when teams cannot track agent actions consistently. The same pattern is reflected in the OWASP Agentic AI Top 10, which emphasises runtime abuse paths rather than static trust assumptions.

In practice, many security teams discover accountability gaps only after an agent has already acted outside its intended scope, rather than through intentional control design.

How It Works in Practice

The safer model is to anchor accountability in identity, not in a conversational or transport session. That means every significant MCP action should be attributable to a workload identity, a delegated token, and a policy decision made at request time. Session context can still help with traceability, but it should never be the only evidence that a request was authorised or approved.

In practice, teams should combine token exchange records, request-level authorisation logs, and ownership mapping so they can answer four questions after the fact: which agent acted, on whose behalf, under what purpose, and against which resource. The OWASP Agentic Applications Top 10 highlights that autonomous systems create new trust boundaries, while NIST SP 800-53 Rev 5 Security and Privacy Controls supports the control evidence needed for auditable decisions.

• Issue short-lived credentials per task, not per session, so a lost or replayed context cannot widen access.
• Bind the agent’s workload identity to the tool call and resource target, ideally through cryptographic proof rather than implied trust.
• Log policy evaluation results at request time, including denied requests, approvals, and any delegated scope.
• Map the human or service owner to each agent action so accountability survives retries, replays, and proxy hops.

NHIMG research on Analysis of Claude Code Security reinforces a practical point: the control plane must preserve evidence independently of the model interaction. These controls tend to break down when MCP is deployed through multiple brokers or gateway layers because session continuity no longer maps cleanly to one accountable actor.

Common Variations and Edge Cases

Tighter attribution controls often increase integration overhead, requiring organisations to balance forensic clarity against deployment speed. That tradeoff becomes more visible in multi-agent workflows, where one agent delegates work to another or where a platform brokers MCP calls across tenants. There is no universal standard for this yet, so current guidance suggests documenting the minimum evidence required for each hop rather than assuming one session record will be sufficient.

One common edge case is resumable or long-running sessions. If the agent pauses overnight, reconnects, or rehydrates state from cache, the original session context may still exist while the authorisation basis no longer does. Another is shared service accounts, which make attribution look easier operationally but erase the very ownership mapping needed for post-incident review. A third is human-in-the-loop approval, where the approval itself is recorded but the later tool calls are not explicitly tied back to the approver’s scope.

Best practice is evolving toward request-scoped evidence and time-bounded delegation, especially where MCP is used for code execution, data access, or administrative tooling. If a team cannot reconstruct purpose and scope without the live session, then the accountability model is too brittle for autonomous workloads.

Related resources from NHI Mgmt Group

• What is MCP in the context of AI security?
• How should teams govern AI agents that use MCP?
• When is it appropriate to implement MCP in the context of AI systems?
• What do teams get wrong when they assume MCP logs are enough for accountability?