Privacy Tiers

Not all personal data is equally sensitive. chris-os classifies data into three tiers and enforces each tier’s protections through architecture: database roles, network isolation, authentication policies, and processing constraints. The tiers are not guidelines. They are technical boundaries.

The Three Tiers

Tier 1: Sacred (Local Only)

What: Therapy sessions, clinical records, raw audio recordings.

Rule: Never leaves the local network. Never processed by cloud AI. Never stored in any system that transmits data externally.

Enforcement:

• Stored in a dedicated therapy PostgreSQL schema with its own isolated database role. No other role can access this schema, including the remote MCP role.
• The MCP proxy for database access connects as a scoped role that has no grants on the therapy schema. Even if someone compromises the MCP endpoint, Tier 1 data is unreachable.
• No n8n workflows process Tier 1 data. No cloud APIs ever receive it.
• Voice recordings processed locally are never forwarded to external transcription services.

Danger

Tier 1 data must never appear in AI conversation context, memory server entries, log aggregation, or any system that syncs to an external service. This is a hard rule with no exceptions.

Tier 2: Sensitive (Protected Access)

What: Health records, financial transactions, private messages (iMessage, WhatsApp, Discord), contacts.

Rule: Accessible through authenticated channels with API-key or SSO protection. Encrypted in transit (TLS). Can be processed by cloud AI only when the user explicitly invokes it through MCP.

Enforcement:

• Database access requires the app role (local applications) or the scoped remote MCP role (remote MCP, limited to SELECT + INSERT/UPDATE on approved tables, no DELETE, no DDL).
• MCP endpoints are authenticated: Cloudflare Access JWT (for claude.ai) or API key (for Claude Desktop/Code). No anonymous access.
• Dashboard access requires Authelia two-factor authentication.
• External webhooks (Gmail, Calendar, GitHub) are authenticated per-service and only ingest data; they do not expose it.
• The all_messages canonical view unifies messages across platforms (iMessage, WhatsApp, Discord) without exposing raw source tables.

Tier 3: Convenience (Standard Auth)

What: Calendar events, weather data, workout metrics, task lists, Peak State scores.

Rule: Standard authentication. Acceptable for cloud processing. Lower sensitivity if exposed.

Enforcement:

• Same database roles and MCP auth as Tier 2 (the infrastructure does not relax security for lower tiers).
• These data types appear in the dashboard, morning briefings, and AI-generated summaries without additional access controls beyond standard SSO.
• n8n workflows freely process and aggregate Tier 3 data.

How the Architecture Enforces Tiers

The tiers are not enforced by a single mechanism. They are the result of multiple architectural layers working together:

Database Role Isolation

PostgreSQL roles are the first line of defense. Each role can only see and modify what it is explicitly granted access to.

Role	Purpose	Schema Access	Can DELETE?	Can DDL?
superuser	Superuser (admin only)	All	Yes	Yes
app	Application queries	public, memory	Yes	No
therapy_app	Therapy data only	therapy	Yes	No
readonly	Dashboard, reporting	public, memory (read)	No	No
remote_rw	Remote MCP access	public (scoped)	No	No

The remote_rw role, used by all remote MCP connections, cannot access the therapy schema, cannot delete rows, and cannot modify the database structure. This is the role that AI assistants use when they query the database. Its permissions define the boundary between what AI can see and what it cannot.

Network Segmentation

Docker bridge networks prevent containers from reaching services they should not talk to. The MCP proxy containers sit on net-mcp and net-data, bridging the AI tool layer to the database tier. But they connect as the scoped remote role, not as a privileged role. Even though the proxy can reach PostgreSQL, the database enforces what it can read.

Authentication Layers

Three authentication systems protect different access paths:

Layer	Protects	Mechanism
Authelia SSO	Browser access to dashboard, n8n, Grafana	TOTP two-factor, session cookie on .ataraxis.cloud
MCP Auth Middleware	AI assistant access to MCP endpoints	Cloudflare Access JWT or API key
Dashboard API Auth	Machine-to-machine API calls	Per-service API keys, validated in Fastify

Each layer operates independently. Compromising one does not compromise the others. A leaked API key gives access to a specific MCP endpoint; it does not grant browser access to the dashboard or Grafana.

Processing Constraints

Tier classification determines where data can be processed:

Processing Location	Tier 1	Tier 2	Tier 3
Local PostgreSQL	Yes	Yes	Yes
Local n8n workflows	No	Yes	Yes
Cloud AI (via MCP)	No	Yes (user-invoked)	Yes
Cloud AI (automated)	No	No	Yes
Dashboard display	No	Yes (2FA required)	Yes (SSO required)

The distinction between Tier 2 and Tier 3 for cloud AI is about automation. AI assistants can see Tier 2 data when you explicitly ask (for example, “search my messages for…”), but automated workflows that send data to cloud APIs only process Tier 3.

Why Tiers Instead of All-or-Nothing

An all-or-nothing approach (either everything is locked down or nothing is) does not match how people actually think about their data. Most people are comfortable sharing their calendar with a cloud service but would not share their therapy notes. The tier system encodes that intuition into infrastructure.

The key insight is that privacy decisions should be made once, at the architectural level, not repeated in every feature and every workflow. When a new n8n workflow is created, it does not need a privacy review. It connects with the appropriate database role, and the role already enforces what it can see. The tier boundaries are invisible to the workflow author because they are built into the roles, schemas, and network topology.