Building Provable AI Agents: An E2E Deep Dive into the FDAA Runtime Integrity Stack

We’ve been building something we think the agent ecosystem is missing:

A provable lifecycle for AI agents — where identity, capabilities, actions, and memory are auditable and tamper-evident without trusting the agent itself.

This post is not a pitch deck. It’s a proof-of-concept with running code, real test outputs, and real failures we had to learn from.

What we set out to prove

• Which agent version ran (and what went into it)
• What that agent was allowed to do
• What it actually did (tool calls + memory operations)
• What it stored and retrieved (with provenance)
• That tampering is detectable

The stack

• FDAA — agent identity, versioning, and hash-verified artifacts
• ACC — capability boundaries (what an agent may do)
• DCT — tamper-evident action ledger (hash-chained)
• GAM — git-native memory with provenance
• RIL — runtime integrity orchestration (enforcement + wiring)
• CIA — conversation integrity assurance (validation/repair of message structure)
• OpenClaw — runtime of record (compiles agent bundle into the real system prompt, runs static agents)

The architecture we shipped (and why it matters)

Here’s the key design decision that made the PoC stable and defensible:

We do not proxy LLM inference. OpenClaw talks to the provider directly. We govern the operational boundary: tools + memory.

Why?

• OAuth/subscription flows (e.g., Claude Max) are fragile — proxying breaks request shape and triggers 401/cooldown cascades.
• The enterprise governance surface is rarely the raw transport layer.
• What matters is: what did the agent do? what did it touch? was it permitted? can we audit it?

Updated system view (PoC-accurate)

• Inference plane (native): OpenClaw → LLM provider direct
• Operations plane (governed): OpenClaw tool calls → FDAA Proxy → ACC + DCT + GAM

This separation gives us repeatability and a clean trust boundary.

1) FDAA Registry: Agent identity you can verify

Every agent starts life as a file-defined artifact bundle (persona markdown + manifest), which is:

• hashed deterministically (SHA-256)
• versioned
• served from a registry with hash verification

Registering an agent

curl -X POST http://localhost:18766/v1/agents \
  -H "Content-Type: application/json" \
  -d '{
    "id": "tony",
    "name": "Tony",
    "description": "GTM strategy",
    "persona_markdown": "## SOUL.md...",
    "allowed_tools": ["web_search"]
  }'

Response:

{
  "id": "tony",
  "name": "Tony",
  "current_version": 1,
  "current_hash": "05177f700d9bc06a...",
  "created_at": "2026-03-02T03:13:12Z"
}

That hash is the anchor for everything downstream: provisioning, runtime provenance, and audit.

2) Provisioning: Static agents + isolated workspaces

When an agent is provisioned into OpenClaw as a static agent, it gets:

• a persistent agent directory (not /tmp)
• strict permissions (700 = owner only)
• isolation from the main agent workspace and secrets

Workspace structure

$ ls -la ~/.openclaw/agents/fdaa/tony/
drwx------  2 claw  4096 Mar 4 .
-rw-------  1 claw   128 Mar 4 .fdaa.json
-rw-------  1 claw    77 Mar 4 AGENTS.md

Each provisioned agent contains provenance metadata:

{
  "agent_id": "tony",
  "agent_hash": "05177f700d9bc...",
  "version": 1,
  "provisioned_at": "2026-03-04T08:46:26Z"
}

What this proves: Agents run in isolated workspaces and cannot read other agent memory, main workspace state, or secrets.

3) ACC: Capability enforcement at the operational boundary

ACC is the policy that defines what an agent is allowed to do.

{
  "agent_id": "tony",
  "allowed_tools": ["web_search", "message"],
  "constraints": {
    "no_file_write": true,
    "no_exec": true
  }
}

Key point: governance lives where the risk lives — tool use and memory access — not in the provider transport.

4) GAM: Memory with provenance (git-native)

GAM gives you long-term memory that is versioned, diffable, and attributable.

PoC rule: every memory write includes provenance fields:

• agent_hash
• run_id
• ledger_entry_hash

That’s what makes memory auditable.

5) DCT: A tamper-evident ledger for operational truth

DCT is a hash-chained ledger that records every attempted action, including denials.

What this proves: You can’t modify history without detection — even if the attacker has database access.

The full lifecycle test (staging)

FDAA Agent Provisioning Lifecycle Test (Staging)

[1/5] Fetching agent 'tony' from FDAA Registry...
  ✓ Agent: Tony
  ✓ Hash: 05177f700d9bc06a...
  ✓ Version: 1

[2/5] Fetching agent's system prompt...
  ✓ Prompt length: 551 chars
  ✓ Hash verified: True

[3/5] Generating OpenClaw agent config...
  ✓ OpenClaw ID: fdaa:tony

[4/5] Verifying workspace files...
  ✓ AGENTS.md exists: True
  ✓ .fdaa.json exists: True
  ✓ Directory permissions: 700 (owner only)
  ✓ Provenance hash matches: True

[5/5] Security isolation verification...
  ✓ Workspace isolated from main: True
  ✓ No path traversal to main: True
  ✓ No memory files leaked: True
  ✓ No systemPrompt in identity: True

✅ ALL LIFECYCLE TESTS PASSED

What we prove (and what we don’t)

✅ Defensible claims

❌ Claims we explicitly avoid

• “We prove internal reasoning.” (not observable)
• “Deterministic inference.” (not true across providers)
• “We cryptographically prove upstream provider accepted token X.” (requires provider cooperation)

Lessons learned (the hard way)

1) Don’t proxy OAuth/subscription inference traffic

We tried. It broke. It’s too easy to subtly change request shape and trigger failures.

2) Silent fallbacks hide failure

We had a fallback that made the system seem healthy while burning credits. Lesson: fail loud during PoC.

3) Never test provisioning on production first

We learned this by breaking workspace resolution with an agents.list[] mutation. Rule: staging → verify → prod.

What’s next

1. LLM call receipts (no proxy): metadata-only hashes logged inside OpenClaw and appended to DCT
2. Pre-execution enforcement: deny tool calls before execution (not just audit)
3. ThreadHQ audit UI: render DCT chain verification + GAM provenance diffs per run
4. Channel integrations: voice/chat channels become delivery mechanisms for governed agents

Conclusion

Provable agents aren’t magic. They’re architecture.

The key insight is simple:

Govern the operational boundary, not the inference boundary. Prove what went into the agent, what it was allowed to do, what it did, and what it remembered — with tamper evidence.

That’s what we built. That’s what we proved.