Autonomous Runtime Guardrails

Summary

AtlasBurn's guardrail engine is a server-side, multi-layer defense system that detects and kills runaway agents autonomously — without manual review. It replaces the legacy SDK-level Auto Kill, which only enforced simple financial caps.

Detection runs in the ingestion server. Enforcement runs at the edge via Cloudflare KV with <5ms latency impact.

Cloudflare KV Architecture

Detection runs server-side in the ingestion pipeline. When a layer trips, the engine writes a SUSPENDED or THROTTLED flag to the GUARDRAIL_FLAGS Cloudflare KV namespace, either for the whole organization or for just the feature that caused it (see What gets blocked). Every edge worker reads the flags on every request, so subsequent calls are blocked at the edge in under 5ms, before the upstream provider is ever contacted.

The 5-Layer Defense Engine

Layer 1 — Financial Limits

Hard and soft caps on daily and hourly spend per organization. Soft caps emit a warning to the dashboard and notification channels; hard caps write a SUSPENDED flag to KV and reject subsequent calls at the edge with 429 Budget Exceeded.

Layer 2 — Dumb Loop Detector (Identical Token Fingerprinting)

Fingerprints every call by model and input-token count. Prompt content is never read. If the last 4 requests from the same feature share an identical fingerprint and land within 30 seconds, that feature is throttled or blocked, depending on your tier (see How each tier responds). This catches the classic "agent stuck in a while-true loop sending the exact same context" failure mode. The same calls spread over minutes are treated as normal traffic.

Layer 3 — Smart Loop Detector (Context Inflation)

Tracks input-token counts per feature. If the last 4 calls of a feature grow steadily (linearly or geometrically), at least double and land within 30 seconds, the engine slows or stops that feature before the context window (and the bill) explodes. That pattern is the classic signature of an agent re-appending a repeating JSON-parse error to its context before each retry.

Layer 4 — RPS Burst Protection (Frequency Limits)

Org-wide request rate limiter. If traffic sustains 10 requests per second across at least 20 requests (the rate is configurable per org), the kill flag is set. The window is sliding-minute-based, not bucketed, which eliminates the concurrent database race conditions that plague fixed-window limiters. This is the ultimate safety net when fingerprinting can't help — for example, with OpenRouter where load-balancing defeats exact-match detection.

Layer 5 — Premium Model Concentration

Detects sudden spikes where >90% of spend concentrates on the most expensive models (e.g. Claude Opus 4, o1). This pattern is highly indicative of prompt injection, hijacked routing, or a misconfigured model selector falling back to the most expensive option.

What gets blocked: one feature or the whole project

A loop is a property of one feature's traffic, so AtlasBurn stops only the feature that looped. If your support chat starts re-sending its own context, the support chat is paused and checkout, search and every other feature keep running. A budget is a limit on the whole project, so budget breaches still stop everything.

A paused feature resumes on its own when its timer ends, or instantly from its own Resume button on the Safety Guardrails page.

How each tier responds

Your tier is the most AtlasBurn is allowed to do. Alert never slows or blocks anything. Throttle slows traffic but never blocks it. Kill Switch may block, but it only blocks at once when money is certain (a budget is actually breached). Traffic patterns like loops and bursts are throttled first, then blocked if the evidence piles up.

Throttle first, block on evidence

On Kill Switch, a loop or burst goes through two steps:

1. Throttle. The affected feature (or, for a burst, the project) is slowed to one call every 2 seconds, and you get an alert. If the pattern stops, the throttle lifts on its own after 10 minutes.
2. Block, if either is true while the pattern is still being detected:
   • it is still happening 60 seconds after the throttle began, or
   • it has cost more than your loop-block limit: 2% of your daily budget, at least $0.25 ($0.50 if no budget is set). You can set your own amount on the Safety Guardrails page.
   You get a second alert saying which rule triggered the block.

A real runaway loop is therefore blocked within about a minute, usually having cost less than your limit. A false alarm, like a fast but normal chat, costs a few slowed calls instead of a two-hour outage.

Strict mode (a switch under Kill Switch) skips the throttle step and blocks every enforceable trigger the moment it is detected, including projected breaches and spending anomalies. Use it when any runaway is unacceptable, even at the cost of occasional false alarms.

Tag your features to get this protection

Scoping works on the feature tags you send. Calls without a tag share one bucket called untagged, so in an app that never tags a feature, a loop still stops all of that untagged traffic. Tag each call with the SDK:

import { atlasburnFeature } from "@atlasburn/sdk";

await anthropic.messages.create(params, { headers: atlasburnFeature("support-chat") });
await openai.chat.completions.create(params, { headers: atlasburnFeature("search") });

Using the Edge Proxy instead? Send the same x-atlasburn-feature header with each request. Untagged proxy calls are grouped per provider (for example proxy-openai). Both the SDK and the proxy remove the header before the request reaches the provider. See SDK Integration → Feature attribution for a per-process default.

Cloudflare KV Kill Switch Architecture

1. Detection — the ingestion server (/api/ingest) processes every telemetry event in real time. When a layer triggers, it calls /api/guardrails/enforce.
2. Flag Push — a SUSPENDED or THROTTLED flag is written to the global GUARDRAIL_FLAGS KV namespace, under the organization's key for budget triggers or under that feature's own key for loops.
3. Edge Enforcement — every proxy worker reads the organization flag and the calling feature's flag in parallel on every request and applies the stricter one. Because KV is replicated at the edge, the latency impact is <5ms.
4. Auto-Recovery (TTL) — flags carry a TTL (default 2 hours). After expiry the system heals itself and traffic resumes automatically.
5. Manual Override — users can clear the flag instantly from the AtlasBurn dashboard: resume a single paused feature, or resume all traffic.

Provider Coverage

Ingestion API Endpoints

• POST /api/ingest — telemetry collection (SDK and Edge Proxy both post here)
• POST /api/guardrails/enforce — internal webhook that writes kill flags to Cloudflare KV

Next Steps

• AtlasBurn Edge Proxy — the enforcement layer
• Advanced Concepts — Monte Carlo forecasting and retry cascades