Mindburn Labs
Founding Cohort

Trust Modell

Was HELM beweist, seinen Umfang, sein Bedrohungsmodell und wie man trust unabhängig überprüfen kann.

ASSUMED ADVERSARIAL- LLM provider- External services- Network- Operator future selfTRUSTTRUSTED KERNEL- PEP- ProofGraph- SafeExecutor- Crypto (Ed25519 + JCS)Assumed trusted: HELM binary, signing keys, host OS, and hardware.
Trust Modell: technische Referenz für diese Seite.

Trust Modell

This page defines what HELM proves, what falls outside its scope, and the threat model under which the system operates.

What HELM proves

Property How Strength
Every tool call was policy-checked PEP receipt for every proposal Cryptographic (L1+)
No receipt was modified after creation Hash-linked chain + Ed25519 Tamper-evident (L2+)
Execution history is complete Bundle Root Hash covers all receipts Independently verifiable (L3)
Policy decisions are deterministic Same input → same verdict By PEP design
Operator cannot silently bypass governance No code path skips the PEP Fail-closed invariant

Scope — what HELM does not cover

Outside HELM's scope Why
Model correctness HELM governs decisions, not model quality
Tool implementation Receipts prove a tool was called correctly, not that the tool itself is correct
External service reliability HELM records interactions but can't guarantee external APIs
Key management Compromised signing keys compromise attestation trust
Physical security OS and hardware are outside the trust boundary

Trust boundaries

🟢 Trusted (HELM Kernel)

Component Role
PEP Policy Enforcement
ProofGraph Receipt Chain (hash-linked)
SafeExecutor Gated Execution
Crypto Ed25519 + JCS canonicalization

Proposals and effects cross this boundary ↓

🔴 Assumed Adversarial

Component Threat
LLM Provider May generate malicious proposals
External Services May return malicious data
Network May be intercepted
Operator's Future Self Receipts prevent edits

Assumed trusted

  • The HELM kernel binary (the operator chose to run it)
  • The operator's signing keys (root of trust)
  • The host OS and hardware

Assumed adversarial

  • The LLM — may generate malicious proposals
  • External services — may return malicious data
  • Network — HELM uses receipts, not transport security, for integrity
  • The operator's future self — receipts prevent retroactive modification

Attack surface

Vector Mitigation
LLM generates harmful tool call PEP denies based on policy; Guardian escalation
Operator modifies receipts Hash chain + Ed25519 breaks — detectable at verification
Operator skips PEP entirely No code path exists (fail-closed)
External service returns malicious data HELM receipts the raw response — proof shows what was received
Signing key compromised Key rotation via trust registry; historical attestations valid until revoked
Schema drift in tool output SHA-256 output hash mismatch → DENY_SCHEMA_MISMATCH
WASM runs wild Sandbox: gas + time + memory budgets, deterministic traps
Budget overspend ACID budget locks, fail-closed → DENY_BUDGET_EXCEEDED
Approval disputes Timelock + 4-hash challenge/response ceremony, Ed25519 signed

Verify trust independently

Any party with access to an EvidencePack can verify:

  1. Were all actions governed? — check receipt completeness
  2. Is the history intact? — verify hash chain + Ed25519 signatures
  3. What decisions were made? — read receipts
  4. Were policies followed? — cross-reference receipts against policy definitions
helm verify --bundle evidence.tar

For full verification options, CI integration, and release attestation, see Verify & Export.

The bottom line

HELM provides execution governance, not correctness guarantees. It answers "did the system follow its own rules?" — not "are the rules correct?" Policy design remains the operator's responsibility. HELM makes policy decisions transparent and verifiable.

Next steps

Goal Guide
Understand conformance levels Conformance
Write policy rules Policy Files
See the architecture Architecture