---
title: "Security"
description: "Account isolation, authority boundaries, protocol safety, content safety, and procedural respect."
navLabel: "Security"
order: 40
nav: false
navGroup: "Explore"
eyebrow: "Trust boundaries"
status: "canonical"
theme: "main"
visibility: "public"
---

## Primary rule

Everything may be addressable. Only explicit resolved authority permits a consequential transition.

## Account resolution and isolation

A Pre Account is a custody and authorization boundary. Every customer, family, or organization read or mutation must resolve account scope before account-owned repository access.

A trusted account request boundary follows this order:

```text
normalize host or explicit account reference
  -> resolve an admitted external binding
  -> authenticate the acting identity
  -> resolve account membership, context grants, and capabilities
  -> classify action and field risk
  -> query or mutate only the resolved account scope
```

Security rules:

- A `*.pre.bi` hostname, custom domain, slug, path, query parameter, cookie field, or request header is not authority.
- Client-supplied account IDs and account headers are untrusted lookup hints and must not override trusted host and session resolution.
- Every storage query, cache key, background job, protocol query, export, and artifact retrieval must carry an admitted account scope once multi-account operation begins.
- Unknown, missing, conflicting, suspended, or unauthorized account bindings fail closed.
- Cross-account reads and actions require explicit bounded grants or capabilities; shared people and relationships do not merge custody boundaries.
- Public projections are field allowlists from one resolved account, not a weaker authentication mode for the whole store.
- Account export, restore, deletion, domain change, and succession are consequential operations with explicit evidence and receipts.
- A shared wildcard application is not acceptable until tenant isolation, normalized persistence, account-scoped queries, backup, and restore are tested.

During early manual provisioning, unrelated real accounts should use isolated stores or data boundaries rather than share HARnest's inherited whole-ledger checkpoint.

## Identity and authority

- Identity is resolved by trusted server or controller boundaries.
- Client-supplied participant IDs, account IDs, roles, permissions, approval states, evidence verdicts, completion states, risk labels, context references, and `claimedAuthority` references are not authoritative.
- A Pre address identifies or names a referent; its kind or namespace segments grant nothing.
- A role grants nothing unless an admitted capability explicitly names its membership or participant subject.
- Schema-valid authority objects supplied by clients are not admitted authority records.
- The resolver trusts only records already held by an authenticated authority store.
- `resolvedAuthority` may be emitted only by a trusted action boundary.

## Immutable grants and revocation

Identity bindings, memberships, context grants, and capabilities are immutable records.

Revocation is a separate immutable record. This preserves what was granted, who granted it, when it applied, who withdrew it, and why.

Revoking an ancestor invalidates its delegated descendants. A replacement record does not silently erase historical authority.

## Delegation only attenuates

A child capability or context grant may narrow:

```text
subject
account
actions
targets
fields
risk ceiling
time window
delegability
```

It may not widen any parent dimension. Delegation depth and issuer and subject linkage are validated through the complete chain. Cycles, missing parents, expired ancestors, revoked ancestors, and cross-account widening fail closed.

## Risk and field boundaries

The trusted boundary classifies risk independently of the caller. A caller cannot rename deletion, payment, publication, disclosure, domain reassignment, export, or another consequential operation as `read`.

Fields are part of authority. Permission to read a title does not expose private notes. Permission for Linear to update status does not grant Linear authority over owners, approvals, evidence, account bindings, or capabilities.

## Idempotency and incomplete execution

Idempotency is durable request state, not a best-effort HTTP header.

- exact finalized retry returns the original result and receipt;
- changed input under the same participant and key scope is denied;
- an admitted request without a final receipt is surfaced as incomplete;
- incomplete work is not silently executed again;
- ordered events preserve partial progress and failure;
- an idempotency scope must not accidentally collide across accounts.

## Evidence and verification

Evidence producers do not automatically become objective evaluators.

A successful executor may report `execution: succeeded` while the objective remains `unverified`. A verified objective requires a durable verdict from an explicit evaluator with authority and evidence references.

Conflicting active verdicts remain visible and project as disagreement.

## External systems and succession

External adapters receive only field-level authority declared by their binding. Unknown fields are denied. External deletion does not imply canonical deletion.

Brevo, Gmail, Microsoft, GitHub, Vercel, Instant, object storage, payment services, and model providers do not own canonical account identity, messages, relationships, tasks, evidence, or history. Provider IDs are external bindings.

Succession records always state `authorityTransferred: false`. Replacement agents, models, devices, account stewards, domains, or custodians require new identity and authority records. Continuity is not a privilege-escalation mechanism.

## Billing and entitlement boundaries

An engagement, invoice binding, payment receipt, subscription, quota, or entitlement does not automatically grant access to all account records or actions.

Payment may be executed by an external provider while Pre preserves the obligation, authorized amount, deliverables, acceptance, payment binding, and receipt. Payment and account administration remain consequential actions.

## Content is untrusted input

Markdown may describe code, commands, links, people, actions, policies, accounts, or hostnames. It cannot execute any of them.

The content compiler:

- supports a bounded Markdown subset;
- produces structured inline tokens rather than raw HTML;
- rejects unsafe link schemes;
- never evaluates embedded JSX, HTML, JavaScript, or event handlers;
- maps trusted theme names to a code-owned design registry;
- does not accept arbitrary Tailwind strings from stored content.

A schema-valid `PageDocument` is not inherently trusted. Render-authoritative presentation and future capability references must be produced or re-resolved by a trusted server projection boundary.

## Public and private projections

Publication fails closed. A page is public only when canonical metadata contains the exact value `visibility: "public"` and the resolved account projection permits those fields.

Private or invalid documents must not disclose document-specific body content, metadata, navigation entries, Markdown, JSON projections, or the existence of a private account through public routes.

Public pages must never expose:

- credentials or environment variables;
- capability or authentication tokens;
- private prompts or chain-of-thought;
- unsanitized filesystem paths;
- private repository content;
- unpublished security findings;
- personal information without authority;
- private room messages or context grants;
- billing, payment, or entitlement details without explicit authorization;
- records from another account because of a cache, query, or hostname-resolution error.

## Local capability boundary

The web application must not receive ambient shell, filesystem, browser-profile, repository, or device authority.

A local controller or Stow client performs a bounded action only after resolving a capability that binds participant, account, target, action, fields, risk, expiry, and receipt behavior.

## Preservation without surveillance

`encounter` is not equivalent to `preserve everything`.

Stow should support graduated capture:

```text
ephemeral encounter
reference
preserved snapshot
extracted assertion
explicit evidence
bounded action
```

The user or authorized community governs which level becomes durable, which account receives it, and who may see it.

## Procedural respect

Persistent participant or account identity does not imply unlimited autonomy or permanent control. Model migration, domain change, account stewardship, constitution change, override, refusal, correction, disagreement, export, and succession remain explicit events.