Trust Model
What HELM proves, what it does not prove, and how trust changes from kernel to platform.
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:
- Did governed execution occur?
- Is the causal chain intact?
- What was allowed or denied?
- 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 |