Governing Agentic AI in Production: Loop Detection, Kill Switches, and Human-in-the-Loop Approvals

AI agents are moving from demos to production. Engineering teams are deploying autonomous systems built on LangChain, CrewAI, AutoGen, and custom agent frameworks that call external tools, query databases, send emails, and modify infrastructure — all without a human in the loop.

This is where agentic AI governance becomes a hard requirement, not a nice-to-have. An agent that can read a file, write a file, and decide what to do next can also get stuck in an infinite cycle of reading and writing the same file — burning API credits, flooding downstream services, and potentially taking destructive actions at machine speed.

The question isn't whether your agents will misbehave. It's whether you'll know when they do, and whether you can stop them before the damage compounds.

This post covers three governance patterns that belong at the infrastructure layer — loop detection, session kill switches, and human-in-the-loop approval gates — and how the DVARA MCP Proxy implements them so your agent code doesn't have to.

---

The Problem: Agents Operate in Open-Ended Loops

A traditional API call is request-response. One in, one out. An agentic workflow is fundamentally different: the agent decides which tool to call next based on the result of the previous call. This creates open-ended execution loops where the number of steps is unbounded and unpredictable.

Consider a real scenario:

A customer support agent is tasked with resolving a billing dispute. It pulls the customer record from your CRM, queries the payment history from Stripe, checks the refund policy in your knowledge base, and decides to issue a partial refund. But the refund API returns a validation error — the customer's subscription tier changed mid-cycle. So the agent re-reads the subscription record, re-queries the payment history, re-checks the policy, and tries the refund again. Same error. The agent doesn't understand the error is structural, not transient, so it retries the entire sequence — burning LLM tokens, hitting your payment APIs repeatedly, and potentially creating duplicate refund attempts. By the time someone notices on Monday morning, the agent has made 400+ API calls across three production systems over the weekend.

Now scale this to a multi-agent pipeline:

A lead qualification agent receives an inbound demo request. It enriches the lead by querying your CRM for company data, calls a firmographic API to pull revenue and headcount, and checks your pricing engine for the right tier. The lead qualifies, so it hands off to a pricing agent — which generates a custom quote and passes it to a contract generation agent. But the contract agent hits a template error for this particular product bundle. It asks the pricing agent to re-quote with a different structure. The pricing agent re-queries the firmographic API (the data hasn't changed), recalculates, and hands back. The contract agent fails again on the same template issue. This cycle repeats — pricing → contract → pricing → contract — each iteration burning LLM calls, API credits on your firmographic provider, and compute on your pricing engine. Meanwhile, 50 other leads are queued behind the stuck pipeline. By the time the on-call engineer investigates, the pipeline has consumed $800 in API costs on a single unresolvable lead and blocked an entire morning's worth of sales pipeline processing.

Three failure modes emerge:

1. Repetition loops — The agent calls the same tool with the same arguments repeatedly. A claims processing agent re-querying the same policy document five times in a row because it can't parse the response.
2. Cycle loops — The agent bounces between tools in a predictable pattern without making progress. A research agent stuck in a lookup → summarize → lookup → summarize cycle because each summary reveals a new question, which triggers a new lookup, which triggers a new summary.
3. Rate explosions — The agent fires tool calls at an unsustainable rate. An inventory agent checking stock levels across 500 SKUs in parallel, overwhelming your warehouse API with 120 calls in under a minute.

None of these are visible at the HTTP layer. A traditional API gateway sees valid POST requests and proxies them faithfully. The OWASP Top 10 for LLM Applications identifies unbounded agent operations as a key risk area. You need a governance layer that understands what the agent is doing over time, not just what a single request looks like.

---

Pattern 1: Loop Detection — Catching Agents Before They Spiral

Loop detection works by maintaining a per-session history of tool calls and scanning for pathological patterns in real time. DVARA's MCP Proxy runs this check on every tool call, before the request reaches the upstream tool server.

Three Detection Strategies

Repetition detection catches the simplest failure mode: the same tool called N times in a row. If an agent calls read_file on the same path five consecutive times, something is wrong. The threshold is configurable — some workflows legitimately poll a resource, so you might set it higher for those tenants.

Cycle detection looks for repeating multi-step patterns. If the call history shows read_file → write_file → read_file → write_file → read_file → write_file, that's a cycle of length 2 repeated 3 times. DVARA checks cycle lengths from 2 up to 4 steps, requiring 3 repetitions before triggering. This catches agents stuck in plan-execute-evaluate loops that never converge.

Rate detection is a time-based safety net. Even if every call is different, 120 tool calls in 60 seconds from a single session is almost certainly a runaway agent. The default threshold is 60 calls per minute — high enough to avoid false positives on busy but healthy sessions.

Configuration

Loop detection is enabled globally by default. You can tune thresholds per tenant via metadata overrides:

# Global defaults in application.yml
gateway:
  agentic:
    loop-detection:
      enabled: true
      repetition-threshold: 5      # same tool N times in a row
      cycle-max-length: 4           # check patterns up to length 4
      cycle-repetitions: 3          # require 3 repeats to trigger
      max-calls-per-minute: 60      # rate-based safety net
      auto-kill: false              # kill session on detection (opt-in)
      history-size: 100             # per-session call buffer

For tenants with specific needs, override via tenant metadata:

{
  "agentic.loop-detection.enabled": "true",
  "agentic.loop-detection.repetition-threshold": "10",
  "agentic.loop-detection.max-calls-per-minute": "120",
  "agentic.loop-detection.auto-kill": "true"
}

What Happens When a Loop Is Detected

When any pattern triggers, the MCP Proxy:

1. Returns HTTP 429 with error code AGENT_LOOP_DETECTED and a message describing the loop type (repetition, cycle, or rate).
2. Writes an audit event with the session ID, tool name, loop type, and tenant ID.
3. Dispatches a webhook so your alerting system (PagerDuty, Slack, OpsGenie) can notify the team.
4. Optionally auto-kills the session (if auto-kill is enabled), blocking all future tool calls from that session ID.

The agent framework receives a clear 429 error and can decide how to handle it — back off, escalate to a human, or terminate the task. The critical point is that the damage stops at the proxy layer, before another tool call reaches your infrastructure.

---

Pattern 2: Session Kill Switch — The Emergency Stop Button

Loop detection is automated, but sometimes you need manual intervention. A human operator sees something wrong — an agent is accessing resources it shouldn't, generating unexpected costs, or behaving erratically in ways that don't match a simple loop pattern — and needs to stop it immediately.

The session kill switch provides exactly this. Every agent session flowing through DVARA's MCP Proxy is tracked by session ID, with real-time metrics: tool call count, error count, total latency, distinct servers and tools accessed, and timestamps.

How It Works

DVARA's session tracker maintains a per-session state with atomic counters. When an operator kills a session, the session ID is added to a killed-sessions set. Every subsequent tool call from that session is rejected with HTTP 403 (SESSION_KILLED) at the earliest point in the filter chain — before policy evaluation, before PII scanning, before the request goes anywhere near a tool server.

Kill a session via the admin API:

# Kill a runaway session
curl -X POST https://admin.example.com/v1/admin/sessions/sess_abc123/kill

Query active sessions to find the one causing trouble:

# List active sessions for a tenant
curl "https://admin.example.com/v1/admin/sessions?tenant_id=tenant-1&active=true"

The response includes enough context to make a decision:

{
  "sessionId": "sess_abc123",
  "tenantId": "acme-corp",
  "toolCallCount": 247,
  "errorCount": 38,
  "totalLatencyMs": 89420,
  "distinctServers": ["crm-service", "stripe-payments", "refund-engine"],
  "distinctTools": ["get_customer", "query_payments", "check_policy", "issue_refund"],
  "firstSeen": "2026-03-28T22:14:01Z",
  "lastSeen": "2026-03-30T07:48:33Z",
  "active": true
}

247 tool calls across three production services. 38 errors. Running since Friday night. That's the billing dispute agent from our earlier scenario — stuck in a retry loop over the weekend. A 15% error rate on a session that's been active for 33 hours tells you everything you need to know. One click to kill it.

The DVARA Flightdeck provides the same view with one-click kill buttons, and the timeline view shows the exact sequence of tool calls with color-coded status badges.

Auto-Kill From Loop Detection

The kill switch and loop detection work together. When auto-kill is enabled, a detected loop automatically kills the session — no human intervention required. This is the strongest enforcement mode: the agent's current call gets a 429, and every future call from that session gets a 403. The session is effectively terminated at the infrastructure layer, regardless of what the agent framework does.

---

Pattern 3: Human-in-the-Loop Approval Gates — Controlled Autonomy

Some tool calls are too consequential to let an agent execute autonomously, but too valuable to block entirely. Deleting a database record, sending an email to a customer, deploying a code change — these are operations where you want the agent to propose the action and a human to approve it.

DVARA's approval gate pattern implements this as a blocking filter in the MCP Proxy. When a tool call matches a configured approval rule, the request is paused mid-flight while a human reviews and decides.

Configuring Approval Rules

Approval rules are configured per tenant using glob patterns for tool names and exact matches for server IDs:

{
  "approval.required-tools": "*delete*,*send_email*,deploy_*",
  "approval.required-servers": "production-db,email-service",
  "approval.timeout-seconds": "300",
  "approval.default-action": "deny"
}

Any tool call matching these patterns triggers the approval flow. The glob syntax supports * and ? wildcards — *delete* matches delete_record, bulk_delete, delete_user, and any other tool with "delete" in the name.

The Approval Flow

Here's what happens when an agent calls a tool that requires approval:

Agent calls "delete_record" on production-db
    ↓
MCP Proxy: Approval required (matches *delete* + production-db)
    ↓
Proxy writes audit event: MCP_APPROVAL_REQUESTED
    ↓
Proxy dispatches webhook with approve/deny action URLs
    ↓
Proxy holds the request until a decision arrives
    ↓
  ┌─── Human clicks "Approve" in Slack/DVARA Flightdeck/webhook URL ───┐
  │                                                              │
  ↓                                                              ↓
Request proceeds to tool server              ... or 5 min timeout
                                                      ↓
                                              Default action: deny
                                                      ↓
                                              HTTP 408 returned to agent

Approval Channels

Approvals can be resolved through three channels — pick whichever fits your team's workflow:

Channel	How it works	Best for
Webhook action URLs	Payload includes HMAC-signed approve/deny URLs. Wire them into Slack buttons, Teams cards, or PagerDuty. No auth needed — the signed token is the credential.	Teams already living in Slack or Teams
Admin API	POST /v1/admin/approvals/{eventId}/resolve?action=approve	CI/CD pipelines, custom tooling
DVARA Flightdeck	Approval queue with full context and one-click approve/deny buttons. Badge counter in the nav shows pending count.	Ops teams monitoring a dashboard

What If Nobody Responds?

If no human acts within the timeout window (default: 5 minutes), the proxy makes the call for you. The default is deny — fail closed, block the tool call. This is the safe default for destructive operations like deletes and payments.

For lower-risk tools where blocking hurts more than allowing, you can flip the default to approve — fail open after timeout, let the request through.

Either way, every outcome is recorded: who approved, who denied, how long the decision took, or that it timed out. Full audit trail, full metrics.

---

Architecture: Where Governance Lives in the Request Path

These three patterns are implemented as filters in DVARA's MCP Proxy filter chain. The filter chain processes every tool call in a fixed order, and each governance filter can short-circuit the request before it reaches the tool server.

The ordering is intentional:

• Loop detection (525) runs before approval (550) — there's no point asking a human to approve a tool call from a looping agent. Catch the loop first.
• Approval (550) runs before PII scanning (600) — if the request is denied, you don't need to spend compute scanning it.
• Session recording (750) runs last — it checks the kill switch as a final safety net and records metrics for every request that makes it this far.

Each filter operates independently. You can enable loop detection without approval gates, or approval gates without loop detection. The filter chain assembles automatically from Spring beans — only filters from licensed enterprise modules are registered.

---

The Case for Infrastructure-Layer Governance

You could build loop detection into your agent code. You could add approval gates to your LangChain tool wrappers. But there are three reasons to push this to the infrastructure layer instead:

Consistency across frameworks. Your organization probably uses more than one agent framework. A governance rule in LangChain doesn't protect your CrewAI agents, your custom Python scripts, or the vendor agent platform you're evaluating. DVARA's MCP Proxy sits between all agents and all tools — one policy, universal enforcement.

Separation of concerns. Agent developers should focus on task logic, not governance plumbing. A security team should be able to change approval rules without redeploying agent code. Infrastructure-layer governance makes this possible — configuration changes propagate live without restarts.

Auditability. Every governance decision — every loop detection, every approval, every kill — is recorded as a signed audit event with tenant ID, session ID, tool name, and timestamp. This audit trail is immutable (HMAC-SHA256 hash chaining) and exportable to your SIEM. Try getting that from scattered try-catch blocks in agent code.

---

Getting Started

Request a Trial License

Ready to try agentic governance? Email us from your official work email at support@dvarahq.com to request a trial license. We'll get you set up within a business day.

DVARA's agentic governance runs as a standalone MCP Proxy (port 8070) that sits between your agents and your tool servers. No changes to agent code required — just repoint the tool endpoint.

1. Follow the Quickstart guide to get DVARA running locally in under 5 minutes.
2. Register your MCP tool servers via the DVARA Flightdeck or admin API.
3. Point your agents at the proxy URL instead of directly at tool servers.
4. Governance is on by default — loop detection starts working immediately. Configure approval gates per tenant as needed.

For the full configuration reference — per-tenant overrides, webhook integration, session tracking, and more — see the Agentic AI Governance documentation.

New to DVARA? Start with Why an AI Gateway? to understand the broader picture of why LLM and agent traffic needs a purpose-built gateway.

---

DVARA is the AI governance platform for LLM and MCP traffic. Policy-as-Code, immutable audit, PII redaction, agentic governance, and cost attribution in one control plane. Learn more at dvarahq.com.