Trust 型号

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