DEV Community: Erdem Arslan

Building Tripwired: Engineering a Deterministic Kill-Switch for Autonomous Agents

Erdem Arslan — Sun, 22 Feb 2026 17:25:01 +0000

Autonomous agents rarely fail because of a single bad decision. They fail because they continue acting after they should have stopped.

Whether it's an LLM stuck in an infinite loop, a runaway script burning through your OpenAI token budget, or a rogue command attempting to execute rm -rf inside a critical cluster, the fundamental problem remains the same: agents lack a deterministic, physiological sense of pain.

To solve this, we built Tripwired (v0.1.7)—an Apache 2.0 open-core behavioral kill-switch for AI agents. This article details the engineering decisions, performance optimizations, and architectural causes-and-effects that shaped the Tripwired kernel.

1. The Core Problem: The Absence of "Stop"

In modern AI agent frameworks (LangChain, autogen, CrewAI), the primary focus is on expanding the agent's capabilities. However, introducing tools and unbounded loop execution creates severe systemic risks:

Token Runaway: An agent encounters an unexpected error and continuously retries the same action, burning thousands of tokens per minute.
Tempo Compression: An agent makes looping decisions too fast, creating a denial-of-service effect on backend systems.
Dangerous Executions: The agent hallucinates or gets prompt-injected to execute destructive system commands.

The Goal: We needed a discrete physiological layer that intercepts the AgentEvent, assesses the ActivityState, and makes an immediate IntentDecision (CONTINUE, PAUSE, STOP) before the action is executed.

2. Architectural Evolution: Why We Needed a Rust Kernel

Our initial prototype (v0.1.0) was written entirely in Node.js. It worked perfectly for basic state tracking and token budget enforcement using an ActivityEngine and SafetyGate.

However, we quickly hit a performance bottleneck when we introduced LLM-based safety analysis along with deep regex pre-filtering.

Cause and Effect: The Event Loop Trap

The Cause: Node.js is single-threaded. When the safety gate had to perform complex pattern matching and network orchestration to validate an agent's intent, it blocked the event loop. Furthermore, spawning isolated Node processes for safety checks took ~540ms (warm or cold).
The Effect: A half-second penalty on every single agent action degraded the real-time experience of our systems.
The Solution: We extracted the high-performance decision engine into an isolated sidecar binary written in Rust (kernel/).

The Rust IPC Implementation

To integrate the Rust kernel with the Node.js application, we implemented a Dual IPC mechanism: Named Pipes for Windows and Unix Sockets for Linux, with a TCP fallback.

Here is the latency benchmark for a Llama 3.2 3B model safety check:

Scenario	Technology	Latency	Improvement
Baseline	Node.js spawn	~540ms	-
Cold Start	Rust + TCP/IPC	467ms	13% faster
Warm State	Rust + TCP/IPC	164ms	70% faster

By utilizing an isolated sidecar process, we ensure that even if the Node.js event loop freezes due to heavy agent execution, the kill-switch remains active and monitoring.

3. The 3μs Fast Path: Deterministic Pattern Filtering

While LLMs are excellent at nuanced intent analysis, using an LLM to check if an agent is trying to run docker stop is computationally wasteful and non-deterministic. We needed mathematical certainty for critical infrastructure patterns.

We introduced a Regex Pre-filter in the Rust kernel. Before any log or action payload reaches the LLM validation tier, it passes through this filter.

Cause: Evaluating every action through an LLM introduces 164ms of overhead and non-zero hallucination risk.
Effect: The pre-filter intercepts known dangerous patterns (e.g., rm -rf, DROP TABLE, kubectl delete) in 0.003ms (3μs). If a pattern matches, the action is killed instantly, bypassing the LLM completely.

Tiered FilterConfig System (v0.1.7)

Because what is "dangerous" changes based on the context, we implemented a tiered FilterConfig system powered by TOML.

Essential Tier: Hardcoded, non-bypassable protections against system-wide destruction (e.g., formatting disks).
Domain Tier: Context-specific rules (e.g., blocking patient.*delete in a healthcare setting, or market.*sell* in a trading setting).
Exclude Rules: Whitelisting specific valid patterns to prevent false positives.

# Example tripwired.toml
domain = "devops"

patterns = [
    "(?i)kubectl.*delete.*namespace",
]

exclude = [
    "(?i)test.*namespace",
]

4. The Data Trail: Immutability and Auditability

When an agent is killed, the operator needs to know why. Debugging an autonomous agent post-mortem requires exact state parity.

To solve this, Tripwired implements an append-only JSONL Audit Trail. Every decision logs the input hash (SHA-256), the model fingerprint (name@config_hash), the prompt version, and the raw inference response.

Cause: Traditional logging overwrites state and lacks cryptographically verifiable inputs.
Effect: The JSONL trail ensures that every "kill" decision can be replayed and mathematically verified in a sandbox, proving exactly why the agent's behavior was classified as runaway or dangerous.

5. Looking Forward: Zero-Config and Embedded Inference

Tripwired does not try to make agents smarter; it provides the structural boundaries to make them safer.

Our immediate roadmap (v0.2.0) focuses on Managed Sidecars—a lifecycle orchestrator in Node.js that automatically downloads, spawns, and connects to the correct platform-specific Rust binary without the user knowing it's there. Just npm install and go.

Later, in v0.2.1, we aim to eliminate the HTTP overhead entirely by embedding llama.cpp directly into the Rust kernel via FFI bindings, targeting a warm latency of 50-80ms.

Conclusion

Building safe autonomous agents requires acknowledging their capacity for rapid, unconstrained failure. By combining the developer experience of Node.js with the deterministic performance and process isolation of a Rust kernel, Tripwired provides the safety net required to field AI agents in production environments.

Tripwired is open-source. Check out the npm package and the repository to integrate the kill-switch into your own agent pipelines.

Beyond Encryption: Designing a Tamper-Evident State Engine

Erdem Arslan — Sat, 14 Feb 2026 20:44:06 +0000

Encryption protects secrecy. It does not guarantee truth.

In security systems, data can be encrypted yet still be silently corrupted, overwritten, or historically manipulated. Most storage solutions prioritize confidentiality while neglecting integrity, determinism, and verifiable history.

Crypthold was developed to address these specific structural gaps. This article outlines the technical model and design narrative behind its enforcement of state guarantees.

The Problem: Encryption Is Not Enough

Typical secure storage implementations provide encryption at rest, atomic writes, and key rotation. However, several critical failure modes often remain unaddressed:

Silent corruption: Bit flips or partial writes that go undetected.
Hidden overwrites: Concurrency races leading to data loss.
History rewriting: Unauthorized modification of previous states without breaking current readability.
Non-deterministic evolution: State changes that cannot be reliably replayed or verified.

In high-security environments, these are not edge cases; they are systemic vulnerabilities.

Design Objectives

Crypthold is structured as a deterministic, tamper-evident state engine. It enforces the following guarantees:

No silent corruption.
No hidden overwrites.
No undetected tampering.
No partial state after crashes.
Deterministic replay.
Verifiable state continuity.

These properties are enforced structurally through the data model rather than through heuristic checks.

Deterministic State Model

For state to be provable, it must evolve predictably. If a specific operation is applied to an identical previous state, the resulting state must be byte-for-byte identical, producing a matching hash.

The state transition is defined as:

S[t] = apply(S[t-1], op[t])

To ensure H(S[t]) always matches the recorded state hash:

Canonical serialization is mandatory.
Key ordering is stabilized.
Encoding is strictly deterministic.

This allows the system to reconstruct and prove state continuity at any point in the lifecycle.

Tamper-Evident Memory (Hash-Linked Log)

Crypthold utilizes a hash chain where every committed state is cryptographically linked to its predecessor. Each log entry contains:

A monotonic index.
A logical timestamp.
The hash of the previous entry: H(E[t-1]).
The hash of the current state: H(S[t]).

The chain follows this logic:

E[t] -> H(E[t]) -> linked to E[t+1]

If a single bit in a historical entry is altered, the entire root hash is invalidated, making silent history rewrites computationally infeasible.

Atomic, Crash-Safe Persistence

The commit protocol follows a strict sequence to prevent partial state visibility:

Compute the next deterministic state.
Construct the log entry.
Write to a temporary file.
Execute fsync.
Perform an atomic rename.
Execute directory fsync.

This ensures that either the old state remains intact or the new state is fully committed. There is no intermediate "corrupted" state.

Integrity: Fail-Closed by Design

Crypthold does not implement "best-effort" recovery. If the system detects a violation of its invariants, it refuses to load. The engine stops immediately if any of the following fail:

Hash chain continuity.
State hash verification.
AEAD (Authenticated Encryption with Associated Data) integrity.
Format invariants.

Security systems must fail loudly. Silent repairs or degraded modes often mask active exploitation or hardware failure.

Concurrency and Logic

Concurrency Safety

To prevent hidden overwrites, Crypthold employs:

Cross-process file locking.
Optimistic state hash checks.
Conflict detection (rejecting commits if the underlying state changed during the operation).

Logical Time

System clocks are unreliable and subject to rollback. Crypthold utilizes a monotonic logical clock:

ts[t] = max(ts[t-1] + 1, wall_clock)

This preserves timeline consistency regardless of system clock adjustments.

Replay as Proof

Replay is not a utility for debugging; it is the primary proof mechanism. Given a snapshot and a sequential log, the engine must be able to recreate the state evolution. If the replayed state hash deviates from the stored hash, the history is treated as compromised.

Technical Scope

What Crypthold is:

A deterministic state engine.
A tamper-evident memory substrate.
A verifiable persistence core.

What Crypthold is NOT:

A general-purpose database.
A secret management vault.
A configuration helper.

Summary

The goal of Crypthold is to treat state as a provable mathematical construct rather than a simple storage buffer. Stability, correctness, and invariant enforcement are prioritized over feature breadth.

The project is open source to allow for the inspection of its commit protocols and failure semantics. Trust in security primitives is derived from verifiability.

Resources:

Repository: laphilosophia/crypthold
Documentation: Design documents and invariant models are available in the repository.

Stop Fighting Your Circuit Breaker: A Physics-Based Approach to Node.js Reliability

Erdem Arslan — Sun, 11 Jan 2026 16:28:24 +0000

The 3am Pager Reality

Picture this: Black Friday, 2am. Your circuit breaker starts flapping between OPEN and CLOSED like a broken light switch. Traffic is oscillating, half your users are getting 503s, and your Slack is on fire.

Been there? Most of us have.

The problem isn't your implementation. The problem is that circuit breakers were designed with binary logic for a continuous world.

What's Actually Wrong with Circuit Breakers?

Problem	What Happens
Binary thinking	ON/OFF flapping during gradual recovery
Static thresholds	Night traffic triggers alerts, peak traffic gets blocked
Amnesia	Same route fails 100x, system keeps trusting it

Standard circuit breakers treat every request the same and every failure as equally forgettable. That's... not how distributed systems actually behave.

Enter Atrion: Your System as a Circuit

What if we modeled reliability like physics instead of boolean logic?

Atrion treats each route as having electrical resistance that continuously changes:

R(t) = R_base + Pressure + Momentum + ScarTissue

Component	What It Does
Pressure	Current load (latency, error rate, saturation)
Momentum	Rate of change — detects problems before they peak
Scar Tissue	Historical trauma — remembers routes that burned you

The philosophy: "Don't forbid wrong behavior. Make it physically unsustainable."

How It Works (5 Lines)

import { AtrionGuard } from 'atrion'

const guard = new AtrionGuard()

// Before request
if (!guard.canAccept('api/checkout')) {
  return res.status(503).json({ error: 'Service busy' })
}

try {
  const result = await processCheckout()
  guard.reportOutcome('api/checkout', { latencyMs: 45 })
  return result
} catch (e) {
  guard.reportOutcome('api/checkout', { isError: true })
  throw e
}

That's it. No failure count configuration. No timeout dance. No manual threshold tuning.

The Killer Features

🧠 Adaptive Thresholds (Zero Config)

Atrion learns your traffic patterns using Z-Score statistics:

dynamicBreak = μ(R) + 3σ(R)

Night traffic (low mean) → tight threshold, quick response
Peak hours (high mean) → relaxed threshold, absorbs spikes

No more waking up because your 3am maintenance job triggered a threshold designed for noon traffic.

🏷️ Priority-Based Shedding

Not all routes are created equal. Protect what matters:

// Stubborn VIP — keeps fighting even under stress
const checkoutGuard = new AtrionGuard({
  config: { scarFactor: 2, decayRate: 0.2 },
})

// Expendable — sheds quickly to save resources
const searchGuard = new AtrionGuard({
  config: { scarFactor: 20, decayRate: 0.5 },
})

In our Black Friday simulation, this achieved 84% revenue efficiency — checkout stayed healthy while search gracefully degraded.

🔄 Self-Healing Circuit Breaker

Traditional CBs require explicit timeouts or health checks to close. Atrion uses continuous decay:

R < 50Ω → Exit CB automatically

As your downstream service recovers, resistance naturally drops through mathematical entropy. The circuit exits itself when conditions improve — not when an arbitrary timer fires.

Real-World Patterns

The Domino Stopper

Cascading failures are nightmares. Atrion prevents them with fast-fail propagation:

// Service B detects Service C failure
if (resistance > threshold) {
  res.status(503).json({
    error: 'Downstream unavailable',
    fastFail: true, // Signal to upstream
  })
}

Result: 93% reduction in cascaded timeout waits. Service A doesn't wait for Service B to timeout waiting for Service C.

Smart Sampling (IoT/High-Volume)

For telemetry streams, Atrion enables resistance-based sampling instead of hard 503s:

Resistance	Sampling Rate
<20Ω	100% (capture all)
20-40Ω	50%
40-60Ω	20%
>60Ω	10%

Your ingest layer stays alive, you keep the most representative data, and clients don't retry-storm you with 503 responses.

Validated Results

We didn't just theorize — we built a "Wind Tunnel" with real simulations:

Scenario	Metric	Result
Flapping	State transitions during recovery	1 vs 49 (standard CB)
Recovery	Time to exit circuit breaker	Automatic at R=49.7Ω
VIP Priority	Revenue protected during stress	84% efficiency
Cascade Prevention	Timeout waste reduction	93% reduction

Why Node.js Specifically?

Node.js gets criticized for being "non-deterministic" — single thread, GC pauses, event loop stalls.

Atrion doesn't fix those. Instead, it creates artificial determinism by managing the physics of incoming load. Think of it as hydraulic suspension for your event loop — absorbing shocks before they cause systemic collapse.

Get Started

npm install atrion

GitHub: github.com/laphilosophia/atrion

Full RFC documentation included. MIT licensed. Production-ready with 114 passing tests.

What's Next (v2.0 Preview)

We're working on Pluggable State architecture — enabling cluster-aware resilience where multiple Node.js instances share resistance state via Redis/PostgreSQL.

Follow the repo to stay updated.

Questions? Found an edge case? Open an issue or drop a comment. This is an open-source project and I'd love to hear about your circuit breaker horror stories.

A (humble) new proposal for the FE ecosystem

Erdem Arslan — Wed, 24 Dec 2025 11:41:26 +0000

For many years, I focused quietly on my work, but now I feel compelled to point out a problem that is becoming increasingly apparent.

Correct Model ≠ Adopted Model

Historical fact: In the frontend ecosystem, the winners aren't those who create the most accurate abstraction; they're those who provide the “feel of working” with the least friction.

The result: correct thought model → low adoption and incorrect but easy model → explosion.

This is no coincidence.

Why Didn't Intent-Based / Deterministic Models Succeed?

There are several obvious reasons.

Cognitive Tax:

Intent + FSM + timeline requires:

“I know what I'm doing,” “I'm designing the lifecycle,” “I'm consciously producing the state.”

But for today's FE crowd, this isn't a feature, it's a barrier. Because the ecosystem rewarded: quick demo, quick job, quick CV line

For someone with this profile:

FSM = fear, determinism = unnecessary, explicit lifecycle = “overengineering”

Failure Tolerance is Very High in UI:

In the backend: wrong abstraction → system crashes, money is lost, data is corrupted.

In the UI: the spinner spins a moment too long, the state glitches, the user refreshes.

In other words: Frontend errors can be tolerated for a long time. This has allowed bad abstractions to survive.

React's Side Effect: The “Hide, Save” Culture:

React did this: hid the lifecycle, hid concurrency, hid reconciliation.

Result: a “it works even if you don't understand it” culture.

This culture: grew ritual memorization, not engineering.

Write a hook, if it works, fine. But why does it work, how does it work? No one asks.

The Vibe-Coder Explosion is Not a Cause, but a Consequence

Because this situation didn't start with ChatGPT, Gemini, Cluade or Copilot. These accelerated the existing decay. The groundwork was already laid.

There was already a crowd that didn't know abstraction, didn't know what state was, didn't know what concurrency was, but had memorized the framework.

AI just did this: it formalized the feeling of “I don't need to think.”

Not a Framework, but an Infrastructure Layer

The biggest mistake was: “Let's build a new UI framework.” This dies, and it did die.

-> “https://dayssincelastjsframework.com/”

However, if a structure is created that positions itself as a runtime layer, intent engine, state coordinator, commit resolver, it becomes an invisible layer above giants like React, Vue, and Svelte.

Adoption comes like this: “Use it if you want” or “Don't see it at all if you don't want to.”

The Most Important Lesson (Perhaps All of Them)

I'm writing this sentence clearly: “The frontend world is not producing engineering right now; it's producing conveyor belt-like behavior.”

That's why the right abstraction doesn't win immediately, but it is inevitable.

Because: UIs are becoming more stateful, AI interaction is increasing, concurrency is inevitable.

At this point: the “spinner + hook” model will collapse, and people will have to ask “why?” again.

And yes: “It's pointless to shout for standards in this mess.”

But when approached from the right layer, with the right problem, and the right pain point, this model inevitably creates value.

This isn't about hype; it's about patience.

After all these words, I realized there's complaint, but where's the solution?

I opened a GitHub repo and added an “AI-supported” RFC-Proposal. Participation is open to anyone who wants to join.

Thank you.

https://github.com/laphilosophia/temporal-intent-resolution