Securing Agentic Workflows: A Deterministic 'Human-in-the-Loop' Pattern for LLMs

Badri C — Thu, 30 Apr 2026 05:19:00 +0000

Key Takeaways

As LLMs transition from retrieval to executing real-world actions via tool calling, Human-in-the-Loop (HITL) architecture becomes a critical security boundary.
The most commonly deployed HITL pattern (stateless client-supplied payloads) contains a critical zero-trust vulnerability, allowing client-side tampering to bypass human approval.
Heavyweight orchestration checkpoints (like LangGraph interrupts) solve the security issue but introduce severe state management latency and framework lock-in.
Implementing a Deterministic Replay pattern using HMAC-signed tokens allows for stateless, sub-second confirmation latency while maintaining cryptographic integrity.
Decoupling the HITL pause/resume logic from the LLM invocation saves a full round-trip, optimizing both cost and user experience.

1. The Agentic Security Bottleneck

As Large Language Models (LLMs) evolve from read-only conversational agents to systems capable of executing real-world actions—such as updating databases, accessing sensitive API endpoints, and triggering financial transactions—the necessity for human oversight is absolute.

This "tool use" capability (often implemented via function calling or the Model Context Protocol) bridges the gap between semantic understanding and production state changes. However, the industry lacks a standardized, secure pattern for Human-in-the-Loop (HITL) interventions in agentic systems.

Without robust oversight, a hallucinated tool call can modify production data or violate regulatory compliance (GDPR, SOX, HIPAA). While most orchestration frameworks offer HITL capabilities, the most prevalent architectures deployed in enterprise systems today are either highly latent, architecturally brittle, or fundamentally insecure.

2. Analyzing Current HITL Patterns

Evaluating existing architectures requires balancing state management, latency, and security. Currently, three primary patterns dominate the landscape, each with significant trade-offs.

The Heavy State Approach (Checkpoint-Based)

In this pattern, common in frameworks like LangGraph, the orchestrator serializes the full agent state to a persistent store at a checkpoint node. Once resumed, the graph replays from the saved state.

While this preserves full context and supports multi-step workflows, the serialization tax introduces high latency. It requires a persistent state store (e.g., Redis, DynamoDB) and creates tight coupling to specific orchestration runtimes.

The Protocol Approach (MCP Elicitation)

The emerging Model Context Protocol (MCP) includes an elicitation capability where a server requests user input mid-tool-execution. While this standardizes the protocol layer, it is currently limited to simple input types without rich UI capabilities and occurs during execution rather than acting as a pre-execution gate.

The False Sense of Security (Stateless Client-Supplied Payloads)

To avoid server-side state, many implementations send the raw tool call parameters to the client UI. Upon confirmation, the client sends these parameters back for execution. This introduces a critical zero-trust vulnerability.

// ❌ INSECURE: Server trusts client-supplied payload
async function handleToolCall(toolCall: ToolCall, context: AgentContext) {
  if (requiresApproval(toolCall.name)) {
    // Send tool details to client for confirmation
    return {
      type: 'confirmation_request',
      toolName: toolCall.name,
      parameters: toolCall.parameters, // Exposed to client
    };
  }
  return executeTool(toolCall);
}

// 🚨 ATTACK VECTOR
// Server sends:   { toolName: "get-employee-data", parameters: { id: "EMP-12345" } }
// Compromised Client returns: { toolName: "get-employee-data", parameters: { id: "EMP-99999" } }
// The server executes the tampered call — bypassing human intent entirely.

3. The Architecture: Deterministic Replay with HMAC

To achieve the performance benefits of a stateless client without violating zero-trust principles, this article presents a Deterministic Replay architecture utilizing HMAC-signed tokens.

In this pattern, the server intercepts the tool call, generates a cryptographically signed token, caches the pending action server-side using a unique nonce, and sends an opaque token to the UI. The client never controls the execution parameters.

Server-Side: Generating the Gate

import { createHmac, randomUUID } from 'crypto';

const HMAC_SECRET = process.env.HITL_HMAC_SECRET;
const TOKEN_TTL_MS = 5 * 60 * 1000; // 5 minutes cache TTL

function generateSignature(
  toolName: string,
  params: Record<string, unknown>,
  nonce: string,
  timestamp: number
): string {
  const payload = `${toolName}:${JSON.stringify(params)}:${nonce}:${timestamp}`;
  return createHmac('sha256', HMAC_SECRET).update(payload).digest('hex');
}

async function createConfirmationGate(
  toolCall: ToolCall,
  userId: string,
  store: PendingApprovalStore
) {
  const nonce = randomUUID();
  const timestamp = Date.now();
  const signature = generateSignature(
    toolCall.name, toolCall.parameters, nonce, timestamp
  );

  // Store the ORIGINAL tool call server-side in a TTL datastore (e.g., Redis)
  await store.put({
    nonce,
    toolName: toolCall.name,
    parameters: toolCall.parameters,
    timestamp,
    userId,
    signature
  }, { ttl: TOKEN_TTL_MS });

  // Send an opaque token to the client.
  // The UI renders the card, but cannot modify the payload.
  const token = { nonce, sig: signature };
  return {
    type: 'confirmation_request',
    card: buildConfirmationCard(toolCall),
    token: Buffer.from(JSON.stringify(token)).toString('base64'),
  };
}

Server-Side: Verification & Deterministic Replay

async function handleConfirmation(
  tokenString: string,
  userId: string,
  store: PendingApprovalStore
): Promise<ToolResult> {
  const { nonce, sig } = JSON.parse(
    Buffer.from(tokenString, 'base64').toString()
  );

  // Lookup the ORIGINAL tool call; verify existence and expiry
  const pending = await store.get(nonce);
  if (!pending || Date.now() - pending.timestamp > TOKEN_TTL_MS) {
    throw new SecurityError('Approval expired or not found');
  }

  // Verify HMAC signature to detect parameter injection or token tampering
  const expectedSig = generateSignature(
    pending.toolName, pending.parameters, nonce, pending.timestamp
  );
  if (sig !== expectedSig || pending.userId !== userId) {
    throw new SecurityError('Security Violation: Signature or User mismatch');
  }

  // ✅ SECURE EXECUTION: Execute the original parameters from the secure server store
  const result = await executeTool({
    name: pending.toolName,
    parameters: pending.parameters
  });
  await store.delete(nonce);
  return result;
}

4. The Latency Optimization

Traditional HITL flows require pausing the agent, waiting for input, and then re-invoking the LLM with the new user context to regenerate the tool call. This second LLM invocation typically adds 2–5 seconds of latency to the confirmation step.

Because the HMAC-signed pattern securely caches the exact parameters server-side, it enables Deterministic Replay. Upon confirmation, the system bypasses the LLM entirely and executes the cached action directly against the tool registry.

This reduces the resumption latency from multiple seconds down to standard network overhead (<50ms), optimizing enterprise compute costs and dramatically improving the user experience.

5. Implementation Considerations: Mixed-Batch Handling

In production environments, LLMs frequently output multiple parallel tool calls in a single generation step. A naive approach blocks the entire batch until all HITL tools are confirmed. A better approach executes non-HITL tools immediately while pausing only flagged endpoints.

async function handleBatchToolCalls(
  toolCalls: ToolCall[],
  registry: ToolRegistry,
  store: PendingApprovalStore,
  userId: string
): Promise<BatchResult> {
  const results: ToolResult[] = [];
  const pendingConfirmations: ConfirmationResponse[] = [];

  for (const toolCall of toolCalls) {
    if (registry.requiresApproval(toolCall.name)) {
      // HITL tool: generate cryptographic gate, do NOT execute
      const confirmation = await createConfirmationGate(toolCall, userId, store);
      pendingConfirmations.push(confirmation);
    } else {
      // Non-HITL tool: execute immediately, no delay
      results.push(await executeTool(toolCall));
    }
  }

  return { completedResults: results, pendingConfirmations };
  // The LLM receives completed results immediately and re-plans
  // naturally after each subsequent HITL confirmation arrives.
}

By maintaining a centralized declarative Tool Registry, the system preserves responsiveness for safe operations while enforcing cryptographic approval gates only where required. Stage-based configuration (e.g., skip HITL in development, enforce in production) provides operational flexibility without code changes.

6. Evaluation Summary

Criterion	Checkpoint (Stateful)	Stateless Client (Insecure)	Replay + HMAC (Proposed)
Security	Server-side state	Client tampering risk	Cryptographic verification
Latency	High (State Serialization)	Low	Very Low (Direct Replay)
Production Ready	Yes (with overhead)	No (Zero-trust violation)	Yes

7. Conclusion

Human-in-the-Loop for LLM agents is a hard security boundary. The most commonly deployed pattern—stateless client-supplied payloads—contains a structural vulnerability that undermines the purpose of human oversight.

The Deterministic Replay pattern utilizing HMAC-signed tokens provides a secure, low-latency alternative that works framework-agnostically. As agentic systems scale to handle high-stakes enterprise operations, closing this transport layer vulnerability is a critical requirement for production readiness.

DEV Community: Badri C