---
title: "Security & Trust"
canonical: "https://helm.docs.mindburn.org/security"
source: "helm-ai-enterprise/docs/public/security-landing.md"
edit: "https://github.com/Mindburn-Labs/helm-ai-enterprise/edit/main/docs/public/security-landing.md"
section: "security"
access: "public"
sensitivity: "public"
last_reviewed: "2026-05-13"
checksum_sha256: "sha256:841c7f05eafc019a5b8f602b59f8cedd19ecd21641bb7d0476a842d68a66f005"
build_timestamp: "2026-05-24T13:40:27.882Z"
---
# Security & Trust

The security route is the public map for HELM security documentation. It points readers to the trust model, verifier model, credential handling, TCB policy, and threat model without duplicating the `/trust` source page.

## Audience

This page is for security reviewers, platform teams, procurement reviewers, and engineers who need to decide which HELM security document answers a concrete question.

## Outcome

After this page you should know where to inspect fail-closed execution behavior, signed receipt verification, credential boundaries, and trusted-computing-base assumptions. Use `/trust` for the main security model and the linked subpages for narrower review.

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        Security["Security route"]
        Trust["/trust security model"]
        Credentials["Credential security"]
    end

    subgraph Evaluation["2. Evaluation & Policy Plane"]
        Threat["Threat model"]
        TCB["TCB policy"]
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        Verify["Verifier trust model"]
        Evidence["Receipts and evidence packs"]
    end

    %% Operational Flow Edges
    Security --> Trust
    Security --> Threat
    Security --> TCB
    Security --> Credentials
    Security --> Verify
    Trust --> Evidence
    Verify --> Evidence

    %% Premium Styling Rules
    style Threat fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style TCB fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style Verify fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
    style Evidence fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
```


## Source Truth

- `docs/public/security-and-trust/security-model.md`
- `docs/public/security-and-trust/threat-model.md`
- `docs/public/security-and-trust/tcb-policy.md`
- `docs/public/security-and-trust/key-management.md`
- `docs/public/security-and-trust/verifier-trust-model.md`
- `docs/public/reference/verify.md`
- `core/pkg/guardian/`
- `core/pkg/proofgraph/`
- `core/pkg/conform/`

## Review Path

| Question | Canonical page |
| --- | --- |
| What does HELM enforce before dispatch? | `/trust` |
| What is inside the TCB? | `/security/tcb-policy` |
| How are credentials scoped? | `/security/key-management` |
| How does the verifier avoid trusting prose? | `/security/verifier-trust-model` |
| What threat assumptions are in scope? | `/security/threat-model` |

## Boundary Notes

The `/security` route is intentionally a map, not a second security model. It
exists because the public navigation needs a stable security entry point while
the canonical model remains `/trust`. Keep the route narrow: link to the exact
security page that owns a claim, name the implementation path that proves it,
and avoid restating route tables, compliance mappings, or release promises that
belong elsewhere.

Security documentation must distinguish three classes of evidence:

- **Runtime controls:** policy evaluation, fail-closed behavior, credential
  scoping, verifier logic, and receipt emission implemented in code.
- **Operator procedures:** deployment, key handling, incident response, and
  runbooks that depend on the operator environment.
- **Release evidence:** checksums, SBOMs, attestations, signatures, and
  evidence bundles attached to a specific release.

Do not collapse those classes into a generic assurance claim. A reviewer should
be able to follow a security statement from this map to a source file, route,
test, release artifact, or narrower public page without relying on private
sales material.

## What This Route Does Not Claim

This route does not claim that every deployment is certified, audit-ready, or
fully compliant. HELM can provide verifiable execution evidence only for the
paths that are wired through its boundary and retained in receipts, proof
records, or release artifacts. Customer-specific controls such as cloud IAM,
network policy, key custody, log retention, and incident response remain the
operator's responsibility unless a narrower HELM document names the exact
managed surface. Keep public security copy precise: describe the control, point
to the implementation or verifier, then state the evidence a reviewer can
collect.

## Troubleshooting

| Symptom | First check |
| --- | --- |
| A security claim points only to this landing page | Move the claim to a specific source-backed security page. |
| `/security` and `/trust` drift | Keep `/security` as the map and `/trust` as the model. |
| A verifier claim lacks a command | Link it to `docs/public/reference/verify.md` or remove it. |
| A private deployment detail appears here | Move it to an authenticated operations page. |