DAV: DEOS Agent Verification

Verifiable execution for autonomous AI agents

Version 1.0, January 2026

Summary

AI agents now make decisions in healthcare, finance, and other regulated settings where "the agent said so" is not an acceptable explanation. DAV is a runtime that captures every operation an agent performs at the OS level, into a tamper-evident execution trace that anyone can replay and verify. The agent cannot bypass the capture because it happens below the application layer. The trace is deterministic, so replay is exact, not approximate.

DAV is the answer to one specific question: prove the agent did what you say it did, in a way that does not require the auditor to trust the operator.

1. The accountability gap

1.1 What AI agents do now

An AI agent receives a goal or task, makes decisions independently, takes actions through API calls and tool use, and operates with minimal human oversight. By 2027, projections put agents in about 30% of customer service interactions, 20% of financial transactions, and 15% of healthcare administrative tasks. Billions of dollars in autonomous operations.

1.2 What you cannot ask today

When an AI agent makes a decision, the answers to these questions are all "trust us":

• What data did the agent see?
• What logic did it follow?
• Did it follow safety protocols?
• Why did it make that decision?
• Can we prove it was not tampered with?

That is fine for low-stakes use. It is not fine for medical decisions, financial transactions, legal determinations, safety-critical operations, or anything regulated.

1.3 The logging problem

The usual response is "we have logs." Logs do not solve this problem. Application-controlled logging can omit inconvenient events, can be edited after the fact, has no proof of completeness, cannot be independently verified, and the developer decides the granularity. Logs are claims, not proof.

1.4 Regulatory pressure

Enterprises need verifiable AI execution. The driver is legal compliance, not competitive positioning.

2. What DAV does

2.1 OS-level capture

DAV is a runtime where AI agents execute with operating-system-level capture of every operation.

+--------------------------------------------------------+
|                    DAV Runtime                         |
|                                                        |
|  +--------------------------------------------------+  |
|  |              AI Agent (Python, etc.)             |  |
|  |                                                  |  |
|  |  decision = model.predict(data)                  |  |
|  |  result   = tool.execute(action)                 |  |
|  |  response = api.call(request)                    |  |
|  +--------------------------------------------------+  |
|                         |                              |
|                         v                              |
|  +--------------------------------------------------+  |
|  |           DEOS Capture Layer                     |  |
|  |                                                  |  |
|  |  Every syscall logged:                           |  |
|  |  - File reads and writes                         |  |
|  |  - Network requests                              |  |
|  |  - Memory operations                             |  |
|  |  - Time and random access                        |  |
|  |                                                  |  |
|  |  Agent CANNOT bypass this layer                  |  |
|  +--------------------------------------------------+  |
|                         |                              |
|                         v                              |
|              Execution Hash: 0x8f3a2b...               |
|              Replay: Deterministic verification        |
+--------------------------------------------------------+

2.2 What you get

2.3 What DAV proves

2.4 What DAV does not prove

DAV proves agent logic, not external model internals. For full model verification the model has to run inside DAV, which is feasible for smaller models. For external models, DAV proves what was sent and what came back, which covers most of the audit surface anyway.

3. Architecture

3.1 Components

+----------------------------------------------------------+
|                  Customer Infrastructure                  |
|  +----------------------------------------------------+  |
|  |                  DAV Container or VM                |  |
|  |  +----------------------------------------------+  |  |
|  |  |              Application Layer                |  |  |
|  |  |  - Python runtime                             |  |  |
|  |  |  - Agent framework (LangChain, etc.)          |  |  |
|  |  |  - Customer agent code                        |  |  |
|  |  +----------------------------------------------+  |  |
|  |  +----------------------------------------------+  |  |
|  |  |              DEOS Kernel                      |  |  |
|  |  |  - Syscall interception                       |  |  |
|  |  |  - Event logging                              |  |  |
|  |  |  - Determinism enforcement                    |  |  |
|  |  |  - Hash chain generation                      |  |  |
|  |  +----------------------------------------------+  |  |
|  +----------------------------------------------------+  |
|                          |                                |
|                          v                                |
|  +----------------------------------------------------+  |
|  |                  Proof Storage                      |  |
|  |  - Execution traces                                 |  |
|  |  - Hash chain                                       |  |
|  |  - Replay artifacts                                 |  |
|  +----------------------------------------------------+  |
+----------------------------------------------------------+

3.2 Execution flow

Step 1: Agent initialization
----------------------------
Customer deploys agent to DAV container
DAV initializes execution context
Execution ID assigned: exec_8f3a2b...

Step 2: Agent execution
-----------------------
Agent runs normally (Python, LangChain, etc.)
Every operation captured at OS level:

Event 0: [SYSCALL] read("/data/patient.json") -> 2,847 bytes
Event 1: [SYSCALL] connect("api.openai.com:443")
Event 2: [NETWORK] send(POST /v1/chat/completions, 1,203 bytes)
Event 3: [NETWORK] recv(response, 892 bytes)
Event 4: [SYSCALL] read("/data/drug_interactions.db")
Event 5: [DECISION] prescription_result = "approve"
Event 6: [SYSCALL] write("/output/decision.json")

Step 3: Hash chain generation
-----------------------------
hash_0 = hash(event_0)
hash_1 = hash(hash_0 + event_1)
hash_2 = hash(hash_1 + event_2)
...
execution_hash = hash_N

Step 4: Proof generation
------------------------
{
  "execution_id":   "exec_8f3a2b",
  "execution_hash": "0x8f3a2b7c...",
  "event_count":    247,
  "timestamp":      "2026-01-15T10:30:00Z",
  "agent":          "prescription-agent-v2",
  "result":         { ... }
}

Step 5: Verification (on demand)
--------------------------------
Any party can:
1. Obtain execution trace
2. Replay in DAV verifier
3. Compare execution_hash
4. If match, execution verified

3.3 Event types captured

3.4 How determinism is enforced

3.5 Language support

Phase 1 (launch): Python via embedded interpreter, Rust native, WASM (any language compiled to WASM).

Phase 2: Node.js, Go, Java via GraalVM.

Framework compatibility: LangChain, LlamaIndex, AutoGPT, CrewAI, and custom frameworks. The OS-level capture means framework choice does not affect verifiability.

4. Trust model

4.1 What is in and out of the trust boundary

DAV verifies the agent's logic, decision paths, data accesses, API calls made, tool usage, and safety checks executed. DAV does not verify external LLM internals (what happens inside GPT-4, model weights, training data).

4.2 Why partial verification is still useful

Most agent liability comes from agent logic, not from model internals. Did the agent check allergies? Did it apply the business rules? Did it escalate high-risk cases? Did it use the correct data? DAV proves all of these. The model itself is the small remainder.

For settings where model internals matter (regulated medical AI, for example), the model has to run inside DAV. For settings where the question is "did the agent do its job correctly," DAV is sufficient.

4.3 Verification levels

4.4 Dispute resolution example

Dispute: "Agent did not check drug interactions"

Resolution:
1. Plaintiff requests execution trace
2. Defendant provides trace and hash
3. Independent verifier replays
4. Verifier reports: "Event #47: query to drug_interactions.db"
5. Dispute resolved with cryptographic proof

5. Integration patterns

5.1 Full agent in DAV

Maximum verification. The whole agent runs inside the container. All logic, all tools, all API calls captured. Best for compliance-critical use cases.

5.2 Decision-point wrapper

Existing infrastructure remains. Only the critical decision runs in DAV. The web app calls into a DAV container at the point that matters, gets back a result plus proof, and continues normally. Best when full migration is too disruptive.

5.3 Verification sidecar

Existing agent runs unchanged. A sidecar mirrors events into a separate hash chain and provides verification. Best for legacy systems where touching the main code path is risky.

5.4 Integration

Before:

def prescribe(patient_data):
    agent = MedicalAgent()
    recommendation = agent.analyze(patient_data)
    return recommendation

After:

from dav import verified

@verified
def prescribe(patient_data):
    agent = MedicalAgent()
    recommendation = agent.analyze(patient_data)
    return recommendation

# Returns: (recommendation, execution_proof)

One decorator. The agent code does not change. The wrapper returns the same value plus a verifiable proof of how it was produced.

6. Use cases

The pattern is the same in every case: the agent runs in DAV, every operation is captured, the output is a result plus a replay-verifiable execution proof. Three representative examples.

6.1 Healthcare: AI-assisted prescribing

An agent recommends medications based on patient data. If something goes wrong, the question is whether the agent checked allergies, current medications, drug interactions, and dosage rules. DAV's trace answers each question by name. The replay shows the database queries, the safety checks, the LLM calls, and the rule applications. Malpractice defense becomes a mechanical check.

6.2 Finance: algorithmic trading agent

A trading agent executes orders based on client parameters. If a client disputes a trade, the question is whether the agent followed the risk parameters and constraints the client agreed to. DAV's trace shows the parameter loads, the market data fetches, the strategy model run, the position checks, and the execution call. Arbitration becomes a hash comparison.

6.3 Insurance: claims processing

An agent evaluates claims, applies policy terms, and produces decisions. If a claimant appeals or sues, the question is whether the evaluation was fair and the policy was applied correctly. DAV's trace shows the policy lookup, the document analysis, the rule application, and the decision derivation. Regulatory complaints become resolvable in minutes.

Other domains follow the same shape: legal contract review, customer service, autonomous booking, anywhere an agent makes a decision a third party may later need to question.

7. Regulatory alignment

7.1 EU AI Act

7.2 FDA AI/ML Guidelines

7.3 SEC

7.4 HIPAA

8. Comparison to alternatives

8.1 DAV vs application logging

8.2 DAV vs observability tools (Datadog, etc.)

8.3 DAV vs blockchain logging

8.4 Summary

9. Roadmap

Phase 1: Foundation (Q1 2026)

• Python runtime in DEOS (RustPython integration)
• Basic LangChain compatibility
• Execution trace format specification
• Replay verification tool
• Docker container packaging

Phase 2: Launch (Q2 2026)

• Production-ready container
• SDK for Python developers
• Proof export formats (JSON, PDF reports)
• Integration documentation
• First healthcare pilot customer

Phase 3: Enterprise (Q3 and Q4 2026)

• SOC 2 compliance
• HIPAA-ready deployment option
• On-premise installation support
• Advanced analytics dashboard
• Multi-agent support

Phase 4: Ecosystem (2027)

• Additional language support (Node.js, Go)
• Third-party verifier network
• Industry-specific compliance packages
• API marketplace for verified agents
• Certification program

10. Conclusion

AI agents will make decisions affecting health, wealth, and safety. The current approach of asking auditors to take operator word for what the agent did is not going to survive contact with the regulators who are already writing the rules.

DAV is one specific answer: capture every operation at the OS level, hash-chain the events so tampering is detectable, run the agent under a deterministic kernel so the trace can be replayed exactly. The cost is real (you run on a custom kernel, you pay for the trace storage). The benefit is that the audit trail is mechanical rather than narrative.

For settings where regulators or counterparties may later need to verify what the agent actually did, DAV is the substrate to build on.

Appendix A: Execution trace format

{
  "version": "1.0",
  "execution_id": "exec_8f3a2b7c",
  "timestamp_start": "2026-01-15T10:30:00.000Z",
  "timestamp_end":   "2026-01-15T10:30:02.847Z",
  "agent": {
    "name":    "prescription-agent",
    "version": "2.1.0",
    "hash":    "0x1a2b3c..."
  },
  "events": [
    {
      "seq":    0,
      "type":   "SYSCALL",
      "name":   "read",
      "args":   {"path": "/data/patient.json"},
      "result": {"bytes": 2847},
      "hash":   "0x..."
    }
  ],
  "execution_hash": "0x8f3a2b7c...",
  "signature":      "0x..."
}

Appendix B: Verification API

POST /verify
{
  "execution_id": "exec_8f3a2b7c",
  "claimed_hash": "0x8f3a2b7c..."
}

Response:
{
  "verified":            true,
  "replayed_hash":       "0x8f3a2b7c...",
  "event_count":         247,
  "verification_time_ms": 1823
}

Appendix C: Glossary

Related papers

• DEOS Determinism Model: /whitepapers/determinism-model
• Verifiable AI Inference on DEOS: /whitepapers/verifiable-inference
• DCO: DEOS Computing Oracle: /whitepapers/dco