What should teams do when MCP workflows still need continuity across calls?

Why This Matters for Security Teams

When MCP workflows need continuity across calls, the temptation is to preserve that context in the transport layer or in opaque session state. That creates hidden workflow memory that security teams cannot reliably inspect, govern, or revoke. Explicit application state keeps the request lifecycle visible, which matters for auditability, incident response, and policy enforcement.

This is especially important for agentic workloads, where tool use can expand quickly and decisions are made at runtime. Guidance from the OWASP Agentic AI Top 10 and OWASP Agentic Applications Top 10 both point toward the same operational problem: when identity, state, and authorisation are not explicit, control breaks down at the exact moment an agent needs to continue work across multiple calls. NHIMG research on AI agents shows how quickly visibility gaps turn into compliance blind spots and unexplained actions in production.

In practice, many security teams discover the problem only after a workflow has already crossed systems, because the state that mattered for governance was never made visible in the first place.

How It Works in Practice

The practical pattern is simple: move continuity into ordinary application state, give it a durable identifier such as a queryId or job ID, and store the workflow context server-side. Each MCP call then references that identifier, while the server resolves the current step, permitted tools, and policy state. That makes the workflow easier to log, easier to expire, and easier to investigate after the fact.

For agentic systems, this also avoids pretending that transport continuity is the same thing as authorisation continuity. The call may resume the same task, but the decision to allow the next tool invocation should still be evaluated at request time. That is consistent with current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasizes controlled access, auditability, and accountability rather than implicit trust in session mechanics. It also aligns with the operational direction of The State of MCP Server Security 2025, where weak access scoping and exposed secrets show how quickly hidden state becomes a security liability.

• Keep workflow context in server-side records, not in client-held or transport-hidden state.
• Bind each continuation to a stable job identifier and log every transition.
• Re-evaluate policy at each step, especially before tool access or data retrieval.
• Expire state automatically when the task completes, is abandoned, or times out.

That approach works best when the server can enforce the full workflow lifecycle; these controls tend to break down in distributed agent chains where each hop invents its own session model and policy context is lost.

Common Variations and Edge Cases

Tighter workflow state management often increases implementation overhead, requiring organisations to balance observability against development speed. That tradeoff is usually worth it, but there is no universal standard for every MCP deployment yet, so teams should treat continuity patterns as design choices rather than protocol guarantees.

One common edge case is long-running work that spans user pauses, retries, or asynchronous callbacks. In those environments, the right answer is usually still explicit application state, but the state must include expiry rules, ownership, and replay protection. Another variation is multi-agent orchestration, where several agents contribute to one job; in that case, the continuity object should record which actor did what, rather than letting a shared session blur accountability. NHIMG research on Analysis of Claude Code Security is a useful reminder that tool-rich agent workflows need traceability more than convenience.

The main exception is when a workflow is truly stateless and no task context must persist beyond a single call. In that case, adding session logic only increases attack surface. For everything else, explicit state is the safer default because it preserves policy visibility without pretending the protocol layer should carry business meaning.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?