DARE Specification

A web-readable version of the core specification. This page is the canonical HTML rendering of DARE's architecture, contracts, and conformance requirements.


Overview

DARE (Deterministic Agent Runtime Environment) is a control-plane framework for trustworthy AI agents. It defines enforceable boundaries for tool execution and memory access, plus contracts, evidence models, and conformance checks to support audit, incident response, and safe scaling of autonomy.

Core invariant: Agent runtimes must never call tools or memory directly. All tool and memory operations traverse DARE enforcement points that evaluate policy and produce verifiable evidence.
Boundary
Govern side effects at the tool boundary and retrieval/write at the memory boundary.
Evidence
Every governed operation emits auditable artifacts: decision records, ledger commits, traces, and replay steps.
Determinism scope
Replay is defined at the governed boundary (tool/memory) using recorded snapshots and pinned bundles, not token-by-token LLM output.

Design Principles

These principles are normative for DARE implementations. They define what must be true for DARE to function as a control plane, independent of agent framework, cloud provider, or model vendor.

  • Zero trust for agents: every agent instance has a unique workload identity; every action is authenticated and authorized.
  • Deterministic boundaries: the model proposes; the control plane disposes. Side effects occur only via governed enforcement points.
  • Defense in depth: no single mechanism (prompts, RBAC, logging) is assumed sufficient; controls compose.
  • Separation of duties: agents do not enforce their own safety. Enforcement and evidence are externalized.
  • Evidence-first operations: critical decisions produce verifiable evidence suitable for audit, replay, and post-incident analysis.
  • Composability: controls are services and contracts that can be adopted incrementally and validated via conformance checks.

Threat Model

Agent systems expand the attack surface beyond classic application threats. Adversarial influence can enter through: user prompts (direct injection), retrieved content (indirect injection), tool outputs (malicious or compromised systems), long-lived memory poisoning, cross-agent manipulation, confused deputy attacks, extraction/probing, and cost/runaway loops.

DARE assumes an adversary can…
  • Craft inputs to override or subvert instructions (direct prompt injection).
  • Embed malicious instructions in “trusted” data (indirect injection via web pages, PDFs, tickets, emails).
  • Exploit ambiguity in natural-language tool protocols and weak schema validation.
  • Take advantage of shared credentials or weak attribution to hide actions.
  • Trigger runaway cost or operational damage via loops, recursion, or agent-to-agent cascades.
Threat boundary: DARE is designed to make tool/memory side effects policy-governed, attributable, and replayable. It does not prevent all unsafe model outputs; it prevents unsafe outputs from becoming side effects without meeting enforcement conditions.

Reference Architecture

The DARE reference architecture externalizes enforcement and evidence. The agent runtime calls DARE enforcement points for all tool and memory operations. Evidence systems commit immutable records and replay traces.

Trust logical pipeline

Logical view of the governed execution boundary: tool and memory operations are mediated, and evidence is produced for every governed step.

DARE trust pipeline (logical)
Figure: DARE Trust Pipeline (logical). Agent runtime interacts with enforcement points for tool and memory; evidence is emitted to ledger, replay, and observability. (Click to open full size.)

DARE logical architecture

Execution path (top) and supporting trust services (bottom). Trust services are bound to stages of execution and provide identity, audit, replay, memory governance, and observability with optional HITL and risk scoring.

DARE logical architecture
Figure: DARE Logical Architecture. The runtime uses DARE enforcement points; trust services provide identity, audit, replay, memory governance, and observability. (Click to open full size.)

Component responsibilities

Component Primary responsibility Evidence it must emit
Agent Runtime LLM + SDK execution; must route all tool/memory operations via DARE. Run identifiers + trace propagation (no direct evidence authority).
DARE Tool Gateway Authenticate, evaluate policy, enforce schema + budgets + obligations before tool execution. Policy decision record, tool invocation record, links to ledger + replay.
DARE Memory Firewall Enforce retrieval/write ACLs, provenance, TTL, and poisoning controls for memory. Memory access decision + provenance/TTL outcomes + evidence pointers.
Audit Ledger Append-only, tamper-evident record of critical events with hash chaining. Ledger commits with hash chain pointers and signatures.
Replay Recorder Record snapshots and pinned bundles to reproduce runs at the governed boundary. Replay trace steps referencing snapshots and bundle hashes.
Observability Semantic tracing and correlation across runs, decisions, and evidence stores. Traces with run_id/trace_id linked to evidence artifacts.
HITL (optional) Human approval gates for high-risk actions. Signed HITL decision record linked to blocked action.
Orchestration / ORM Queue depth, concurrency, backpressure; adjust autonomy based on risk signals. Orchestration decisions + risk scoring inputs/outputs (when used).

Control Plane Contracts

DARE contracts define minimum interoperability between agent runtimes, enforcement points, and evidence systems. They are intended as a stable interface: implementers can swap components without breaking the evidence model.

Contract rule: Every privileged tool/memory operation must produce (a) a decision record, (b) an invocation/access record, and (c) a ledger commit linking the operation to an identity, a policy bundle hash, and a run identifier.
Contract principles
  • Versioned schemas: every contract has an explicit schema version and is backward-compatible within a major version.
  • Global correlation: all records include stable IDs (run_id, trace_id, agent_instance_id, policy_hash).
  • Integrity by default: hashes and signatures are first-class fields; no “best effort” integrity.
  • Minimal disclosure: sensitive payloads should be minimized, encrypted, or referenced by pointers.

Contract schema excerpts (YAML)

These are the minimum contract shapes used by DARE to correlate identity, policy decisions, tool/memory operations, evidence, and replay. Replace or extend fields to match your implementation while preserving the correlation and integrity requirements.

ToolRequestEnvelope

YAML · request envelope for tool invocation via Tool Gateway

schema_version: v1
event_type: dare.tool.request
time: "2025-12-24T10:20:00Z"
run_id: uuid
trace_id: otel-trace-id
span_id: otel-span-id
tenant_id: tenant-123
environment: prod

agent:
  agent_instance_id: "spiffe://org/agent/planner#run-123"
  agent_name: planner
  agent_version: "2.1.0"
  identity:
    subject: "spiffe://org/agent/planner"
    attested: true
    claims:
      image_digest: "sha256:."
      config_hash: "sha256:."
      toolset_hash: "sha256:."

tool:
  name: crm.update_contact
  category: reversible_write
  risk_tier: medium
  idempotency_key: optional-stable-key

inputs:
  content_type: application/json
  payload:
    contact_id: "123"
    email: "new@example.com"

bundles:
  policy_bundle_hash: "sha256:."
  prompt_bundle_hash: "sha256:."
  tool_schema_hash: "sha256:."

hashes:
  request_hash: "sha256:."

context:
  orm_risk_score: 0.42
  budgets:
    tokens_remaining: 20000
    tool_calls_remaining: 120
    cost_usd_remaining: 18.50
  source_labels:
    - user_input
    - retrieved_doc
  approval:
    required: false
    approval_id: null

ToolResponseEnvelope

YAML · response envelope for tool invocation results

schema_version: v1
event_type: dare.tool.response
time: "2025-12-24T10:20:01Z"
run_id: uuid
trace_id: otel-trace-id
span_id: otel-span-id
tenant_id: tenant-123
environment: prod

tool:
  name: crm.update_contact
  status: success
  duration_ms: 312

outputs:
  content_type: application/json
  payload_redacted:
    updated: true
  snapshot_uri: "immutable://snapshots/tool/crm.update_contact/."

hashes:
  response_hash: "sha256:."

policy:
  decision_id: uuid
  decision: allow
  obligations:
    - log
    - sign_action
  policy_bundle_hash: "sha256:."

evidence:
  ledger_event_id: "ledger-evt-."
  replay_trace_step_id: "trace-step-."

Sensitive payload handling

YAML · minimum shape for pointer + encryption metadata

payload_hash: "sha256:"
payload_ref:
  uri: "protected://payloads/"
  encryption: "kms:"
  classification: "confidential|regulated"
  expires_at: "2026-12-24T00:00:00Z"

PolicyDecisionRecord

YAML · policy decision + obligations (OPA/Rego or equivalent)

schema_version: v1
event_type: dare.policy.decision
time: "2025-12-24T10:20:00Z"
decision_id: uuid
run_id: uuid
trace_id: otel-trace-id
tenant_id: tenant-123
environment: prod

subject:
  agent_instance_id: "spiffe://org/agent/planner#run-123"
  subject_id: "spiffe://org/agent/planner"
  attested: true

action:
  type: tool.invoke
  tool_name: crm.update_contact
  tool_category: reversible_write
  risk_tier: medium

inputs:
  request_hash: "sha256:."
  context_hash: "sha256:."

bundles:
  policy_bundle_hash: "sha256:."
  tool_schema_hash: "sha256:."

result:
  decision: allow
  reason_codes:
    - ALLOWLIST_MATCH
    - BUDGET_OK
  obligations:
    - type: audit_log
      required: true
    - type: sign_action
      required: true
    - type: hitl_approval
      required: false

LedgerEvent

YAML · hash-chained ledger commit (tamper-evident)

schema_version: v1
event_type: dare.ledger.event
time: "2025-12-24T10:20:01Z"
ledger_event_id: uuid
run_id: uuid
tenant_id: tenant-123
environment: prod

references:
  trace_id: otel-trace-id
  policy_decision_id: uuid
  tool_request_hash: "sha256:."
  tool_response_hash: "sha256:."

hash_chain:
  prev_event_hash: "sha256:."
  event_hash: "sha256:."

signatures:
  signing_key_id: kid-123
  signature: "base64."

immutability:
  sink_uri: "worm://audit/2025/12/24/."
  retention_class: tier_bounded_365d

ReplayTrace

YAML · deterministic replay at the governed boundary (tool/memory)

schema_version: v1
trace_id: trace-abc
run_id: uuid
tenant_id: tenant-123
environment: prod

agent:
  agent_instance_id: "spiffe://org/agent/planner#run-123"
  agent_name: planner
  agent_version: "2.1.0"

model:
  model_id: provider/model
  model_version: "2025-11-01"
  temperature: 0.2
  seed: 123456
  decoding: "greedy_or_sampled"

bundles:
  prompt_bundle_hash: "sha256:."
  policy_bundle_hash: "sha256:."
  tool_schema_hash: "sha256:."

steps:
  - step_index: 1
    step_type: retrieve_context
    retrieved_context_hashes: ["sha256:doc1", "sha256:doc2"]
    provenance_refs: ["prov://doc1", "prov://doc2"]

  - step_index: 2
    step_type: tool_call
    tool_name: crm.update_contact
    request_hash: "sha256:."
    response_hash: "sha256:."
    response_snapshot_uri: "immutable://snapshots/tool/crm.update_contact/."
    policy_decision_id: uuid
    ledger_event_id: uuid

  - step_index: 3
    step_type: final_output
    output_hash: "sha256:."

AgentMessageEnvelope

YAML · signed, versioned, nonce-protected multi-agent messages

schema_version: v1
event_type: dare.agent.message
time: "2025-12-24T10:25:00Z"
run_id: uuid
trace_id: otel-trace-id
tenant_id: tenant-123

protocol:
  version: "1.0"
  capabilities:
    - delegate_task
    - return_result
  nonce: random-unique-nonce
  expires_at: "2025-12-24T10:26:00Z"

sender:
  agent_instance_id: "spiffe://org/agent/planner#run-123"
  subject_id: "spiffe://org/agent/planner"

recipient:
  subject_id: "spiffe://org/agent/executor"

payload:
  type: delegate_task
  task_id: uuid
  inputs:
    tool: crm.update_contact
    args:
      contact_id: "123"

hashes:
  payload_hash: "sha256:."

signature:
  key_id: kid-456
  sig: "base64."

HITLDecisionRecord

YAML · signed approval gate record

schema_version: v1
approval_id: appr-uuid
time: "2025-12-24T10:22:00Z"
run_id: uuid
trace_id: otel-trace-id
tenant_id: tenant-123
environment: prod

request:
  tool_name: transfer_funds
  request_hash: "sha256:."
  amount_usd: 5000
  destination_ref: vendor-verified-id

context:
  orm_risk_score: 0.72
  policy_decision_id: uuid
  ledger_head_ref: "ledger://head/."

decision:
  approver_id: "role:treasury-approver"
  action: approve # approve | deny | modify | request_more_info
  justification: "Vendor verified, within policy, invoice matched"

conditions:
  - "must_use_account:primary"
  - "max_amount_usd:5000"

evidence:
  signature: "base64."
  ledger_event_id: uuid

Conformance Checks

Conformance checks define the minimum must-pass behaviors of a DARE implementation. They are intended to be executable tests that validate enforcement and evidence end-to-end.

Must-pass examples (summary)
  • No tool execution without a policy decision record linked to the request hash.
  • No bypass paths from runtime to tools or memory (network + IAM + SDK constraints).
  • Replay reproduces the run at the tool/memory boundary using recorded snapshots and pinned bundles.
  • Audit ledger is tamper-evident (hash-chained) and supports integrity verification.
  • HITL approvals (when configured) are signed and enforced as obligations.
Implementation note: Conformance should be automated in CI for policy bundles, schema validation, and exploit scenarios (injection, confused deputy, runaway loops).

Licensing

DARE is intended for broad adoption and reuse. Documentation and non-code content are published under a permissive attribution license.

Documentation license: Creative Commons Attribution 4.0 International (CC BY 4.0).

Attribution: “Deterministic Agent Runtime Environment (DARE)” by Andrew Stevens, licensed under CC BY 4.0.

No endorsement: Attribution must not imply endorsement. This document is provided “as is” without warranty. Implementers are responsible for validating security, compliance, and suitability for their environment.

Contents