Security in the Cortex Protocol is not a feature — it is the foundational layer that ensures the Sovereignty Abstraction Layer (SAL) remains uncompromised. We assume a zero-trust model: no module, agent, or external entity is trusted by default.

This document also acknowledges what security cannot guarantee — because a security policy that overstates its own coverage is itself a vulnerability.

All core functions operate without internet connectivity.

• Local-only inference: Intent parsing, clinical analysis, and biometric processing occur on local silicon (NPU/GPU).
• Network kill-switch: Any module attempting unauthorized network calls is immediately quarantined.
• No telemetry: The protocol does not collect usage data, error reports, or analytics by default.

• Signed rulesets: Only Clinical Capability Modules (CCMs) signed by authorized Governance Nodes can access sensitive hardware sensors.
• Session isolation: Per-session HMAC-SHA256 keys derived from ephemeral salts. No cross-session correlation is possible without the session salt.
• Hardware attestation (KEROS): In Level 3 deployments, TPM 2.0 attestation verifies that the SAL code has not been tampered with at the firmware level.

Biometric data is treated as an extension of the human body, not as data points.

• Ephemeral processing: Raw sensor data is processed in volatile memory via context manager pattern and destroyed immediately after clinical feature extraction. See RawBiometricFrame.__exit__().
• Encryption at rest: Any persistent configuration or long-term clinical trends must be encrypted with user-only keys stored in the device's Secure Enclave.
• Memory zeroing: data.fill(0) is called deterministically on context manager exit — not deferred to garbage collection.

The protocol protects users from malicious AI agents. It provides reduced — but not zero — protection against malicious human operators.

What cryptographic measures cover:

• Raw biometric data cannot be transmitted externally without breaking the SAL architecture.
• Tensors cannot be reversed to raw values without the session salt.
• CCMs cannot be forged without a Governance Node's GPG private key.

What cryptographic measures do NOT cover:

• An operator who configures non-standard CDI thresholds to reduce sensitivity.
• An operator who uses technically compliant audit logs for unauthorized purposes.
• An operator who presents consent requests to users in states of reduced capacity.

These risks are addressed by institutional governance (GOVERNANCE.md §5) and the planned User-Verifiable Audit Protocol (UVAP, Milestone 2) — not by cryptography alone.

data.fill(0) zeroes the NumPy array in Python-managed memory. On systems with memory-mapped files, swap partitions, or copy-on-write kernels, zeroed memory may persist on disk. Production deployments in high-threat environments should integrate OS-level secure memory (mlock, SecureZeroMemory on Windows) or hardware-backed Trusted Execution Environments (OP-TEE, Intel TDX).

The LIMES proof of liveness relies on the statistical distinguishability of biological entropy from synthetic entropy. This assumption is currently valid. It is subject to annual review by the White Branch and may require hardware-bound entropy sources (TPM TRNG) as generative AI advances. See STANDARD.md §2.6 and DISCLAIMER.md §4.1.

Prompt injection — adversarial instructions embedded in content that the Acolyte processes — is classified as the top LLM application vulnerability (OWASP LLM Top 10, 2025). The current protocol does not include a Semantic Boundary Validator. This is a known gap, planned for Milestone 2.

The current KEROS reference implementation uses a 5-second timestamp freshness window for seal verification. This is too strict for sequential demonstration use and too loose for high-security production deployments. The White Branch will define domain-specific timestamp windows in CIT specifications.

Do not report security vulnerabilities as public Issues.

If you discover a vulnerability that could compromise user sovereignty or clinical safety:

1. Open a private GitHub Security Advisory.
2. Include: detailed description, affected component, proof of concept if available.
3. Protocol Stewards will acknowledge within 72 hours and work on a local-first patch.
4. Vulnerabilities affecting Clinical Bridge thresholds or CDI logic require White Branch review before patch release.

Unlike traditional software, Cortex Protocol security audits include a Clinical Audit:

• Engineering review: Memory safety, IPC security, cryptographic strength, timing attacks.
• Clinical review: Ensuring security patches do not accidentally override safety margins defined in the Clinical Bridge.
• Governance review: Ensuring patches do not introduce operator capabilities that violate Anti-Capture Provisions.

All three reviews are required for patches affecting Sections 2.1–2.7 of STANDARD.md.

"Security is not what protects the system from the user. It is what protects the user from everyone else — including the system's own creators. And it is honest about what it cannot yet protect against."

Security Policy v1.1 — Cortex Protocol. Maintained by Protocol Stewards. Clinical patches require White Branch approval.