Mindburn Labs
DEMO

Trust Model

What HELM proves, what it does not prove, and how trust changes from kernel to platform.

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 Model: technical reference for this page.

Trust Model

This page defines what HELM proves, what remains outside scope, and how the trust boundary changes from the OSS kernel to the platform layers around it.

What HELM proves

Property How Strength
Proposed action crossed the governance boundary PEP decision + receipt Cryptographic
Receipt history was not silently changed Hash chain + signatures Tamper-evident
Policy decisions are reproducible Deterministic evaluation Structural
Execution history can be replayed EvidencePack + replay surface Independently verifiable
Operators cannot silently bypass the kernel Fail-closed boundary contract Architectural

What HELM does not prove

Outside scope Why
Model correctness HELM governs execution, not intelligence quality
Tool correctness HELM proves a tool call happened under policy, not that the tool itself was correct
External API honesty HELM records what crossed the boundary, not the truthfulness of a third party
Key custody outside HELM Compromised keys weaken attestation trust
Physical-world correctness Physical actuation and hardware reality require extra layers beyond the current kernel

Trusted vs adversarial surfaces

Trusted

Component Role
HELM kernel Deterministic policy and receipt boundary
Signing keys Root of trust for attestations
ProofGraph / EvidencePack verifier Offline verification surface

Assumed adversarial or untrusted

Component Threat
LLM providers May propose unsafe or malicious actions
External services May drift, lie, or fail
Networks May be intercepted or partitioned
Future operators May try to rewrite history after the fact

Kernel trust vs platform trust

HELM OSS trust boundary

HELM OSS proves governed execution at the kernel boundary:

  • allow or deny verdicts
  • receipts and proof chains
  • replayability

HELM Platform trust boundary

HELM Platform extends this into organizational operations:

  • shared approvals
  • workspace and pack lifecycle
  • Mission Control surfaces
  • public and institutional evidence workflows

The platform must never weaken the kernel boundary. It may add workflow, but not new bypass paths.

Why this matters for organizations

Organizations increasingly operate through mixed systems:

  • humans
  • agents
  • software
  • policies

Trust fails when authority is ambiguous. HELM’s job is not to make decisions morally perfect. It is to make execution attributable, bounded, and provable.

Verify independently

Anyone with an EvidencePack can verify:

  1. Did governed execution occur?
  2. Is the causal chain intact?
  3. What was allowed or denied?
  4. Can the outcome be replayed under the same evidence?
helm verify --bundle evidence.tar

Bottom line

HELM provides execution authority, not omniscience. It answers:

Did the organization execute under its declared rules and boundaries?

It does not answer:

Were those rules wise, complete, or morally correct?

That distinction is the whole trust model.

Next steps

Goal Guide
Understand the architecture Architecture
Understand the product boundary Platform Boundary
Learn how to verify evidence Verify & Export