Security Baseline

Nous uses a layered local-first security baseline. Phase 1 established foundational controls, and Phase 2.1 added witness evidence-chain verification for critical actions.

Localhost-Only by Default

The web UI binds to localhost only. No network exposure unless explicitly configured.

Configuration: Next.js dev server and production build default to localhost. For network exposure, set HOST=0.0.0.0 and enable basic auth.

Basic Auth (Optional)

When the backend is exposed on a network, basic auth protects all routes.

Configuration: Set NOUS_BASIC_AUTH=user:password in the environment. The middleware validates the Authorization: Basic header on all protected routes.

CLI: When basic auth is enabled, set NOUS_BASIC_AUTH in the environment when running CLI commands. The tRPC client adds the header automatically.

Trace Sensitivity

Execution traces may contain model output and memory candidate content. By default, sensitive fields are redacted before persistence.

Configuration: security.traceSensitiveData in config (default: false). When false, the following are redacted before trace persistence:

• User input (message)
• Model output (response)
• Memory candidate content in denials

Structure (traceId, projectId, timestamps, Cortex decisions) is preserved.

Witness Evidence Chain (Phase 2.1)

Phase 2.1 introduces a tamper-evident witness baseline for critical action categories:

• model-invoke
• tool-execute
• memory-write
• trace-persist

For each category, the system emits:

• an authorization event,
• a completion event,
• optional invariant events,
• trace evidence references linking to witness artifacts.

Verifier surfaces:

• CLI: witness verify, witness list, witness get --id <report-id>
• API: witness.* procedures and traces.verificationReports

Verifier output includes:

• VerificationReport with chain and signature validation status
• AttestationReceipt (local mode baseline)
• per-severity invariant findings (S0, S1, S2)

Storage Encryption at Rest

Configuration: storage.storageEncryption in config (default: false).

When true, the user must ensure data at rest is protected. Options:

• Filesystem-level encryption — LUKS (Linux), BitLocker (Windows), FileVault (macOS)
• SQLCipher — Future; better-sqlite3 has no built-in encryption

Phase 1: config option validated; runbook documents user responsibility.

CLI Credentials

Never store credentials in CLI config files. Use environment variables:

• NOUS_BASIC_AUTH — For tRPC auth when backend requires it
• NOUS_DATA_DIR — Data directory (optional)
• NOUS_CONFIG_PATH — Config file path (optional)

Package Trust Architecture (Phase 7)

Phase 7 establishes the package trust and lifecycle security baseline. Skill, workflow, and app packages are verified, signed, and governed before execution. The following applies when package lifecycle features are implemented (Phase 7.2+).

Fail-Closed Posture

Unsigned, revoked-signer, incompatible, or policy-violating package actions are blocked. No silent bypass. Denial outcomes emit deterministic reason codes for operator interpretation.

Reason Codes for Package Lifecycle

Lifecycle Orchestration Controls (Phase 7.4)

Phase 7.4 adds deterministic lifecycle orchestration controls on top of Phase 7.2/7.3 package trust contracts:

• explicit transition matrix enforcement (ingest/install/enable/update/import/export/remove)
• staged update snapshots with previous-safe-version rollback targets
• fail-closed rollback posture (rolled_back or disabled, never silent partial apply)
• explicit remove retention governance (export_then_remove or delete_confirmed)
• witness-linked lifecycle outcomes for allowed/blocked/rolled_back/disabled decisions

Operationally, lifecycle success is invalid if witness linkage is missing; such transitions are treated as blocked (PKG-005-*).

Interpreting Package Lifecycle Events

When a package enable is blocked (e.g., unsigned package):

{
  "event_type": "pkg_enable_blocked",
  "package_id": "skill:image-quality-assessment",
  "package_version": "1.2.0",
  "origin_class": "third_party_external",
  "reason_code": "PKG-001-UNSIGNED",
  "witness_ref": "evt_abc123"
}

Action: Re-sign the package with an approved key, or obtain a signed release from the maintainer.

When an update is rolled back (e.g., migration failure):

{
  "event_type": "pkg_update_rolled_back",
  "package_id": "workflow:persona-engine",
  "package_version": "2.0.0",
  "origin_class": "nous_first_party",
  "reason_code": "PKG-004-MIGRATION_FAILED",
  "witness_ref": "evt_def456",
  "previous_safe_version": "1.5.2"
}

Action: The system reverted to the previous safe version. Review migration requirements before retrying the update.

Evidence Linkage

Package trust decisions are witness-linked. Use witness_ref and evidenceRefs to trace why a package was blocked or allowed. Verifier CLI and API surfaces support audit replay.

Contract Layer Implemented in Phase 7.2

Phase 7.2 defines the shared contract layer that Phase 7.3 and Phase 7.4 enforcement logic consumes:

• Package manifest schema in self/shared/src/types/package-manifest.ts
  • requires: id, name, version, package_type, origin_class, api_contract_range, capabilities
  • enforces self_created_local requirements: author_principal_id, origin_instance_id
• Lifecycle event and transition schema in self/shared/src/types/package-lifecycle.ts
  • standard event envelope: event_type, package_id, package_version, origin_class, witness_ref
  • blocked/denied event types require deterministic reason_code
  • lifecycle state/transition contracts enforce valid transition ordering and reason-coded blocked outcomes
• Compatibility gate schema/helpers in self/shared/src/types/package-compatibility.ts
  • semver range evaluation (api_contract_range vs runtime SDK version)
  • capability delta computation with explicit re-approval requirement on expansion (PKG-002-*)

These contracts are shared definitions only (no runtime bypass). Runtime admission and lifecycle transitions remain fail-closed and are enforced by subsequent Phase 7 implementation slices.

Endpoint Trust Baseline (Phase 11.2)

Phase 11.2 extends the baseline for human messaging and device-adjacent connectors with canonical endpoint trust controls.

Manual Pairing and Immutable Direction

• Every peripheral begins pending until Principal-approved pairing evidence is recorded
• Endpoints register with immutable direction: sensory or action
• Bidirectional endpoint objects are not accepted in this phase

Capability Governance

• Sensor and action capabilities are granted explicitly per endpoint
• Direction-capability mismatches are blocked and evidence-linked
• High-risk action commands require operator-control-compatible confirmation proof before authorization

Transport Integrity

• Trusted sessions track nonce and highest accepted sequence
• Replayed, expired, mismatched, or out-of-order envelopes are blocked
• Session rotation, suspension, and revocation invalidate continued trusted use

Incident and Registry Gating

• Lost-device, compromised-device, MITM, suspend, and revoke incidents fail closed and revoke trusted runtime posture immediately
• Connector and device packages must pass registry install-eligibility before their endpoints can become active trusted endpoints
• Endpoint trust decisions emit witness-linked evidence and incident escalation through existing canonical services

Voice Control Safety Baseline (Phase 11.3)

Phase 11.3 extends the baseline for voice-originated escalation and control intent without creating a voice-only authority path.

Combined End-of-Turn Gating

• Silence alone is never enough to authorize execution
• Voice handoff requires combined semantic completion, silence-window timing, and explicit handoff support
• Ambiguous or low-confidence turns fail closed into continue-listening, clarification, blocked, or text-confirm posture

Dual-Channel and Text-First Protection

• Destructive, critical, or T3 voice actions require dual-channel confirmation from the active Principal session
• Voice alone cannot authorize those actions
• Low-confidence risky intents are routed to explicit text/UI confirmation rather than silently retried

Barge-In and Continuation Safety

• Assistant speech interruption is recorded as canonical runtime state
• Barge-in emits timing evidence and forces explicit continuation-required posture
• Automatic resume after interruption is not allowed

Metadata-First Privacy Posture

• Voice control records persist transcript hashes, signal scores, decision refs, route refs, escalation refs, and witness linkage
• Raw audio is not retained by default
• The system must be able to reconstruct control-affecting turns from metadata and witness-linked evidence alone

Degraded Mode

• Low ASR confidence, low intent confidence, handoff instability, transport degradation, or interruption-recovery posture can activate degraded mode
• In degraded mode, risky controls switch to text-first behavior until recovery is sustained
• Degraded-mode status remains visible to operator surfaces through canonical projection data

Runbook Summary