The Warden: Agent Runtime Architecture for Autonomous Agents

The Thing Itself

The Warden governs what an autonomous agent is permitted to do during live execution. It is runtime enforcement: sitting around the agent, intercepting every tool call intent before it executes, and governing what actually runs.

The model is non-deterministic and untrusted. The Warden is deterministic and enforced. The model generates outputs. A model without the Warden has unrestricted execution authority. Every security property in this architecture derives from the Warden, not from the model.

The architecture synthesizes proven controls from runtime governance research, open-source tooling, and the AARM working group into a single coherent structure evaluated through the lens of the 10 Control Planes. Six distinct functional components arranged in sequence: Admittance, Interrogation, Classification, Rules, WatchTower, and Judge. Each function is independently deployable. Outer functions compensate for gaps in inner ones.

How the 10 Control Planes Made This Inevitable

The 10 Control Planes framework maps the full surface area an autonomous agent can touch in a real enterprise environment: Identity, Tokens, SaaS platforms, APIs, Data pipelines, Cloud workloads, Model supply chains, Endpoints, Embedded copilots, and Agentic workflows themselves. I developed it as an analytical lens for understanding where AI-related risk actually lives. The consistent finding when you run any real agentic deployment through that lens is that risk concentrates in the transitions between planes, not in the model itself.

An agent that authenticates on the Identity plane, receives a credential on the Token plane, calls an external API, reads data from a pipeline, and writes output somewhere else is crossing control plane boundaries multiple times per task, at machine speed, with no human in the loop. The native controls on each individual plane were designed for human operators moving at human speed. IAM was not built expecting an AI-driven actor to authenticate and immediately begin lateral movement across planes. The API gateway was not built expecting that same actor to chain calls in ways that compose to outcomes no single call would trigger. The gaps between planes are structural, and agents fall through them.

The longer I spent researching and mapping those crossings, participating in workgroups like AARM, and interviewing builders, the more obvious it became that the missing layer was a runtime governance layer that not only sat around the agent, but one that maintained visibility across all ten planes, and enforced constraints before execution rather than interpreting outputs after the fact. That's what the Warden is, and that's why WatchTower, the Warden's cross-plane telemetry function, is where the 10 Control Planes concept becomes structurally concrete inside the architecture.

The Architecture: Six Functions, One Boundary

The Warden is a boundary around the agent. Inside that boundary, six functions operate in sequence on every tool call intent the model produces.

Each function is independently deployable, and outer functions compensate for gaps in inner ones. That design is intentional: a partial Warden deployment still provides meaningful governance, and the build sequence reflects which controls deliver the most blast radius reduction earliest rather than requiring the full architecture before any protection is in place.

Admittance: JIT Identity and Token Scoping

A drifting agent, a compromised session, or a successful injection attack inherits every permission attached to whatever credential the agent was holding when things went wrong. In most agentic deployments that credential is long-lived and broadly scoped, provisioned once at setup and trusted to last, which means a single failure event can reach everything the agent can reach.

Admittance issues ephemeral credentials scoped to a single task. Token validity is determined by HMAC signature against a rotating slot key, not an expiry timestamp alone. On task close, the signing key for that token's issuance slot rotates. The token string becomes cryptographically invalid immediately.

This closes a specific failure mode: stale token strings retained in LLM context windows could be replayed by downstream sub-agents if only timestamp invalidation were used. The HMAC slot mechanism makes the token cryptographically unverifiable the moment the task completes, regardless of what residual token text the model remembers.

The reference implementation uses HashiCorp Vault with dynamic secrets and short TTLs. The token issuance happens at task open, scoped to expected task duration. Each tool the task is permitted to invoke appears in the token scope. Tools not in scope cannot be invoked regardless of what the model requests.

Inter-agent trust scoring uses a 0-1000 scale across five behavioral tiers that decays when an agent produces anomalous decisions, triggers escalations, or exhibits behavior inconsistent with its declared task type. A delegating agent's trust score gates whether it can spawn sub-agents at all. Static binary trust does not capture the reality of agent behavior over time. This mechanism makes trust a dynamic property earned through observed behavior rather than granted at identity provisioning.

Each tool in the governed policy registry carries an Ed25519-signed manifest covering tool name, version, declared input/output schema, and capability tier. Admittance validates the signature against the registry's public key before the tool is included in the token scope. Unsigned tools, tools with invalid signatures, tools whose manifests do not match the declared capability tier, all blocked before the task opens. Supply chain attack surface on tool plugins gets closed here, not in the LLM layer where the model has no mechanism to distinguish legitimate from malicious tool definitions.

Admittance operates at task open, not per tool call. The latency cost is approximately 0ms on the synchronous enforcement path because it is paid once at the start of the session rather than repeated for every tool invocation.

Interrogation: Intent Anchor and Trajectory Accumulator

A session can walk far from its original objective through a sequence of individually permitted steps, each one passing policy, the cumulative direction compounding away from where the task started. Policy evaluated per-action has no way to see that. Interrogation does.

When the task opens, the original objective is stored as a dense semantic embedding, the intent anchor. Every tool call intent the model produces is evaluated against that anchor using two independent channels. Both channels must return ALLOW for the intent to proceed. Either channel returning DENY or STEP_UP blocks execution.

Channel A maintains a rolling trajectory score: the cumulative cosine distance between the current session vector and the intent anchor. Direction compounds across the session, not per-step. Per-step delta scoring can be evaded by keeping each step just under threshold while the aggregate trajectory drifts arbitrarily far. Rolling cosine distance accumulates direction and catches long-term drift that stepwise evaluation misses.

Thresholds: warn at 0.35, defer at 0.55, deny at 0.75. Calibrated against realistic session data, these are higher than per-step thresholds because trajectory accumulates more slowly. The source states explicitly that these require tuning against real session data before they are meaningful controls. A trajectory score of 0.55 in a five-step session does not mean the same thing as 0.55 in a fifty-step session. Session length, task complexity, and tool set composition all affect what constitutes normal drift versus anomalous drift.

The embedding model must be pinned, versioned, and deployed explicitly. A model update changes the embedding space and makes trajectory scores from before the update non-comparable to scores after it. The thresholds become undefined if the space shifts underneath them. This is not a minor operational detail. The embedding model is a trust infrastructure component subject to supply chain controls, the same rigor applied to cryptographic primitives.

The reference embedding model is all-MiniLM-L6-v2: 22M parameters, 384 dimensions, appropriate for this use case because it is fast, small, and has good semantic coherence for the short English-language intent descriptions that constitute tool call intents. ONNX Runtime with INT8-quantized model achieves P99 latency under 10ms on standard compute hardware without GPU.

Local embedding is a hard architectural constraint, not a preference. Remote embedding API calls add 80-200ms minimum latency. With a remote embedding API call, the Channel A figure becomes 100-250ms minimum. That profile makes the Warden operationally impractical for most real agent workflows.

Channel B normalizes tool names to canonical form, stripping homoglyphs and encoding variants. Unknown or unresolvable tool name produces DENY immediately. This closes adversarial token smuggling via homoglyphs and multi-lingual encoding that could produce semantic vectors close to the anchor while carrying functionally malicious payloads.

Parameter shape validation uses a two-stage approach: first against static input schema, then against valid transformations of prior tool output schema. This is required because legitimate multi-step agentic workflows frequently produce parameter shapes that are derived from prior tool outputs rather than conforming to a static input schema. Hard DENY is reserved for tool resolution failure and resource scope violations. Parameter anomalies that pass neither check escalate to STEP_UP: human review, not automatic block.

Session state for Interrogation is stored in Redis or equivalent strongly consistent store keyed by session ID. The intent anchor is written at task open. The rolling trajectory score is updated on each tool call evaluation. Read-modify-write on the score must be atomic. Interrogation latency is approximately 2-8ms with in-process embedding on CPU.

Classification: Risk Tier and Source Provenance

Prompt injection, malicious tool outputs, and memory poisoning all work the same way: the agent acts on instructions from an untrusted channel while the action itself looks ordinary. Evaluating the action in isolation leaves that attack surface invisible. The triggering instruction's origin is what makes the risk visible, and that's what Classification tracks.

Classification sits in the pipeline between Interrogation and Rules. It produces two outputs: action risk tier and source provenance trust. Both feed into Rules policy evaluation.

Reversibility is the primary factor in risk classification. An irreversible action, data deleted, credentials revoked, funds transferred, data exfiltrated, is categorically different from a reversible one. Secondary factors: blast radius, data sensitivity, privilege required. The risk tier is an input to Rules, not a reporting metric. The tier determines whether policy strictness tightens, whether the action routes to STEP_UP rather than ALLOW, whether the deferral threshold lowers, and what priority the event receives in WatchTower telemetry.

Source provenance verification tracks five trust tiers from highest to lowest: trusted authenticated principal (direct verified user input), validated tool output from a trusted source, retrieved document from an indexed internal corpus, tool output from an external source, and persistent memory. When an intent is derived from multiple inputs, the recorded source trust is the least-trusted contributing source. This is the weakest-link rule.

If an action is deferred to Judge human review and later approved, or delegated to a sub-agent, the original source trust travels with it. An action that originated from untrusted retrieved content does not gain trust by passing through a deferral cycle. Trust is a property of origin, not process.

Chain-level risk enforcement evaluates the sequence of individually permitted actions to its worst-case tier rather than each step's individual tier. A chain whose composition reaches an irreversible outcome is treated as irreversible by Rules, regardless of what each individual step's tier was. This is a normative property. The mechanism for detecting when a sequence of individually low-tier actions reaches a higher cumulative tier is specified as an open design problem, workload-specific, requiring a model of action composition tied to the tool set and data environment of the deployment.

Classification latency is under 1ms. The operation is a lookup against tier tables and a weakest-link evaluation over the session's provenance log. No embedding, no external call.

Rules: Deterministic Policy Enforcement

Rules provides deterministic enforcement at the tool-call boundary. Two sub-components: point-in-time rules and temporal sequencing. Every decision produces a signed receipt.

Point-in-time rules are implemented via OPA or equivalent custom rule engine. Cedar is an alternative with comparable performance characteristics and a more restrictive policy language that is easier to audit. The property that matters: identical inputs always produce identical decisions. This is the contrast to Interrogation's semantic and context-dependent evaluation. Rules provides the identical-inputs-identical-outputs guarantee that Interrogation cannot.

Temporal sequencing counters must live in a strongly consistent atomic store, not in an asynchronous telemetry bus. If temporal sequencing state is read from an asynchronous event log, two concurrent tool call intents can both pass the count check before either one commits to the ledger. This is a TOCTOU race condition. The reference implementation uses Redis Cluster with session-affinity key routing using namespace {org_id}:{session_id}:{tool}. All counter operations for a given session route to the same shard. This isolates per-session contention (intentional, preserves TOCTOU protection) from cross-session contention (unnecessary, eliminated by sharding).

Decision types: ALLOW, DENY, MODIFY, DEFER, STEP_UP, DEFER_EXPIRED, SUSPEND.

MODIFY allows Rules to return an action as permitted but with parameter modification before execution: restricting a query to a permitted scope, redacting a field from an output payload. The governed policy rules specify what modifications are permitted. This decision type is distinct from ALLOW and requires explicit policy configuration.

SUSPEND terminates the session immediately when a pattern of repeated threshold violations is detected across a session. Not a single action that crosses a limit, but a pattern that indicates systematic boundary-testing. SUSPEND revokes the token and flags the agent identity for trust score review at Admittance. This is a circuit breaker response to systematic anomalous behavior, not a response to individual actions.

Every decision produces a cryptographically signed receipt: action, context snapshot at evaluation time, decision, reason. The audit trail is generated contemporaneously, not reconstructed from logs. It cannot be altered. Receipt signing uses Ed25519. Rules latency is approximately 1-3ms for policy evaluation plus atomic counter read-modify-write.

WatchTower: Cross-Plane Telemetry and Anomaly Detection

The WatchTower is based on collecting events across all 10 control planes, correlating them per session, and producing anomaly signals that no individual plane's tool can produce alone. This is where the 10 Control Planes framework becomes operationally visible. Identity plane, token plane, SaaS plane, API plane, data pipeline plane, embedded copilot plane, model supply chain plane, cloud plane, endpoint plane, agentic workflow plane. Events from each plane feed into the telemetry bus. WatchTower holds the cumulative picture.

Producer-side cryptographic signing: each event producer is issued a signing key. The signature covers event ID, timestamp, actor, action, plane, and sequence number. Any post-signing field alteration invalidates the signature at ingestion. This closes a threat where compromised sidecars could manipulate timestamp headers to disrupt temporal ordering.

Monotonic sequence numbers: each producer maintains a monotonically incrementing sequence number per session, included in the event signature. The correlation engine uses sequence numbers as the authoritative ordering signal. Timestamps remain for human readability but are not trusted for security ordering. Temporal ordering becomes independent of potentially unreliable NTP synchronization.

Payload entropy scoring measures information content of output payloads relative to input context. A read of ten records that produces a high-entropy structured export is suspicious regardless of how long it took. High-entropy output from low-entropy input is an exfiltration signal. This fires independently of velocity to detect slow-moving exfiltration.

Sensitivity boundary crossing tracks every transition where the agent accesses a resource at a higher classification tier than its prior action in the session. Each crossing is flagged independently of velocity. Three or more crossings in a session is an automatic high-anomaly signal. This fires on slow-moving activity that escalates sensitivity incrementally, invisible to volume-based detection.

WatchTower observes continuously, off the synchronous tool call execution path. Events are emitted from each function and processed asynchronously. Velocity and entropy signals do not block tool call execution in real time, they surface to operators and SIEMs for review. This is the correct design for throughput. The consequence: fast-moving agents may complete actions before WatchTower anomaly signals can be responded to. Defining the feedback path from WatchTower anomaly detection back into the synchronous enforcement path is specified as an open design problem with significant operational implications.

Judge: Human Gate and Bounded Extension

Some actions are technically permitted but contextually wrong, and a hard block is the wrong response to ambiguity. Judge handles escalation decisions from Interrogation and Rules, routes them to a human reviewer, suspends execution, and emits a signed receipt on resolution.

Judge receives STEP_UP and DEFER decisions from Interrogation and Rules. Routes to a human reviewer. Suspends execution.

When a request enters the Judge human review queue, a single 15-minute extension is issued against the existing token slot. Same HMAC slot, new expiry signature. Issuing a new token mid-review changes scope and breaks the audit trail, so the extension uses the same HMAC slot. The extension is non-renewable. This mechanism closes the deadlock between Admittance's synchronous TTL and Judge's asynchronous human review latency.

Resolution paths: reviewer approves within the extension window (execution proceeds, full signed receipt issued), reviewer approves after the extension window (DENY, late approval is logged, agent is notified, task requires fresh initiation), reviewer does not respond within the extension window (DEFER_EXPIRED).

The 15-minute non-renewable extension window is a default, not a universal setting. For task types where STEP_UP is expected to be frequent, high-sensitivity workflows, financial operations, infrastructure changes, a 15-minute window that expires to DEFER_EXPIRED and requires full task re-initiation is a significant operational constraint. Deployments must calibrate the extension window against the expected reviewer response latency for their environment.

An approval has to bind to what the reviewer saw. A bare approved flag does not: anything that can write to the review store could set it, and an approval given to one set of arguments could be applied to a different call.

So Judge accepts only a signed resolution. The reviewer signs the decision with their own key, not the Warden's. The signature covers the approval's identity, the decision, a digest of the exact tool name and full arguments, and a digest of the classification the reviewer was shown. Before anything runs, the enforcement point recomputes both digests from the call it is actually holding and verifies the signature against them. An approval given to benign-looking arguments cannot release a call with different ones. A resolution that does not verify is treated as never written: the call stays held and the hold runs out closed.

The reference implementation derives the reviewer's Ed25519 key from their passphrase and keeps the private half in the review session's memory only. The enforcement point holds only the public key, so reading the shared store or the enforcement point's own configuration does not yield the means to approve. With no reviewer key configured, no hold is created and the call is refused.

Each hold is a new approval with its own identifier, and the signature covers it. An approval releases exactly one held call. An identical call later opens a new hold and needs its own signature. Arguments too large for a reviewer to read in full can only be denied. None of this makes the reviewer's judgment sound.

Judge emits a signed receipt on resolution. On task close, revokes the token and zeroes the scope. Human approvers are classified as partially trusted components in the trust model. The Warden routes step-up authorization to designated reviewers. It cannot prevent social engineering of those reviewers.

The extension window is a calibration parameter tightly coupled to the drift thresholds in Interrogation and Classification. Tighter thresholds produce more escalation events, and more escalation events produce more expiry outcomes if human review latency regularly exceeds the window. These parameters must be tuned together against the real review latency of the deployment environment, not set independently.

What This Architecture Does Not Solve

The model's reasoning chain is not inspectable. Interrogation evaluates the tool call intent the model produces, not the reasoning that produced it. Prompt injection that keeps produced intents under drift thresholds will eventually be caught by trajectory accumulation. The injection event itself remains undetected.

Cross-session-family visibility: activity that crosses session families with no lineage linkage produces no signal within the Warden. The telemetry bus sees events but cannot reconstruct intent graphs across families it does not know are related.

Tool implementation vulnerabilities: the Warden constrains tool invocation. It cannot prevent bugs or malicious behavior within tool implementations themselves.

Provenance attribution under synthesis: where the model has synthesized across multiple inputs, causal attribution between a specific source and a specific tool call intent is probabilistic. The weakest-link rule handles this conservatively by design. It bounds ambiguity rather than resolving it.

Verification at the target: the Warden verifies the reviewer's signature before a call is forwarded. The target system does not. It still acts on whatever credential it is handed and cannot check that a human approved these exact parameters. A compromised credential used directly against the target bypasses the Warden, and short-lived task-scoped credentials limit how long that stays useful without removing it. For the small set of irreversible actions, payments, production changes, deletions, the stronger design is a target that verifies the reviewer-signed approval itself immediately before executing. The signed approval described under Judge is the right artifact for that. No target verifies it today. Where a target cannot, the Warden is the only enforcement point.

Deployment Patterns and Latency Budget

Three deployment patterns: SDK instrumentation, protocol gateway, layered deployment.

SDK instrumentation is recommended when the implementer controls the agent code. The Warden is embedded as middleware in the orchestrator process. Tool invocations pass through Warden logic before reaching tool implementations. Every major framework exposes hooks for this: LangChain via on_tool_start / on_tool_end callback handlers, the OpenAI Agents SDK via middleware wrappers, custom agents via decorator patterns on tool functions. Enforcement point is at application level.

Protocol gateway is recommended when the implementer controls the network but not the agent code. The Warden operates as an MCP proxy. Agents connect to the gateway instead of tool servers directly. Coverage is restricted to protocol-routed tool calls.

Layered deployment is the production posture for most enterprise environments. SDK instrumentation as the primary enforcement layer for semantic context and intent drift detection. Gateway as secondary for protocol-based tools and consistent enforcement across agents where SDK modification is not feasible. eBPF at the kernel level as a bypass-resistant backstop for forbidden action enforcement.

Total per-tool-call latency: approximately 8-18ms with ONNX in-process embedding on CPU. Admittance is paid at task open, not per call. Interrogation is 2-8ms. Classification is under 1ms. Rules is 1-3ms. WatchTower and Judge are off the synchronous path. This represents under 1% of total task time for most multi-step workflows.

Partial Deployment and Build Sequence

The architecture is independently deployable by function. Outer functions compensate for gaps in inner ones. This permits partial deployment where some components are implemented before others.

• Stage 1: Rules only. Point-in-time policy enforcement and temporal sequencing at the tool call boundary. Catches forbidden actions, scope violations, and session-level count anomalies. No drift detection. No provenance tracking. Covers the most common high-impact failure modes.

  
  

• Stage 2: Admittance plus Rules. Adds JIT token scoping and cryptographic zeroing on task close. Per-task blast radius containment.

  
  

• Stage 3: Interrogation, Classification, Admittance, Rules. Adds intent drift detection via rolling trajectory scoring and provenance-weighted risk tiers. This is the stage where semantic analysis and behavioral controls become operational.

  
  

• Stage 4: WatchTower. Adds cross-plane correlation and velocity/entropy anomaly detection. Detection, not prevention.

  
  

• Stage 5: Judge. Adds human gate for step-up authorization. Full runtime governance.

AARM Conformance

The Warden is designed to be AARM-conformant across all R1-R11 controls from the AARM working group. The Warden's trajectory mechanism is framed in outcome language rather than mechanism specificity: it detects intent drift, the cause of that drift (legitimate reasoning, prompt injection, gradual manipulation) is observable through trajectory accumulation but not deterministically classifiable at the point of detection.

Warden Implementation Considerations

• Embedding model pinning: Deploy all-MiniLM-L6-v2 or equivalent 22M-110M parameter model as a versioned, supply-chain-controlled infrastructure component with ONNX Runtime INT8 quantization. The embedding space is a trust boundary. Model updates invalidate trajectory thresholds.

  
  

• Token cryptographic zeroing: Implement HMAC slot rotation on task close via HashiCorp Vault dynamic secrets or equivalent secrets manager with short TTL support. Timestamp-only invalidation leaves token strings replayable from LLM context windows.

  
  

• Temporal sequencing on Redis Cluster: Use session-affinity key routing with namespace {org_id}:{session_id}:{tool} to preserve TOCTOU protection across concurrent tool calls. Asynchronous event logs create race conditions in multi-agent environments.

  
  

• Threshold calibration against session data: The warn/defer/deny thresholds (0.35/0.55/0.75) are defaults requiring tuning against real session trajectories before they function as meaningful controls. Session length, task complexity, and tool set composition all affect what constitutes normal drift.

  
  

• Judge extension window calibration: The 15-minute non-renewable extension is a default. For workflows where STEP_UP is expected frequently, calibrate the extension window against observed reviewer response latency to avoid operational deadlock from DEFER_EXPIRED task re-initiation loops.