Data Privacy and Compliance

This document describes what personal and client data flows through OGL Cortex, where it is stored, how long it stays, which outside services receive it, and what an operator needs in place for GDPR, CCPA, Mexican privacy law, US marketing law and SOC 2. Secrets handling is in 11-ai-safety-governance.md section 7. Vendors are profiled in 13-vendor-risk.md.

Scope and terms

An enterprise privacy programme has a Data Protection Officer, a record of processing activities, data processing agreements with every vendor, retention schedules, subject-access workflows and annual audits. OGL Cortex ships none of these. It is built for one owner. It does hold real personal data (the owner's messages, clients, their customers, sales leads), so an operator who uses it for client work should add the controls in section 7.

• Personal data: anything that identifies a person: name, email, phone, voice, face, booking.
• Processor: a company that handles data on your behalf. Anthropic processes everything a seat reads.
• Retention: how long data is kept before deletion.

1. Shape of the system

OGL Cortex runs on one host under one OS user account. Every seat runs as that user, so every seat can read every file that user can read. Seats share ~/.claude and ~/.config. There is no per-seat file isolation.

The arrows to outside companies matter most. The model provider sees everything a seat reads. The embedding provider sees what is ingested into the knowledge base. Telegram carries every message between the owner and the fleet.

2. Data inventory

Paths are install-relative. <instance> is the daemon instance name; <org> and <seat> are folder names under $CORTEX_HOME/orgs/.

2.1 Owner messages and media

The daily git auto-commit excludes telegram-images/, node_modules/ and similar folders, and refuses files that match common credential patterns (src/bus/system.ts). Media are not copied into git.

Retention and evidence pull in opposite directions. Approval receipts often cite a file in telegram-images/. If a retention job deletes media, those receipts point at nothing. Pick a retention window longer than your audit window, or copy cited files to a receipts folder before deletion.

2.2 Memory and knowledge layers

2.3 Email, files and calendars

Keep each account's token readable only by the code that needs it. An account guard and an identity check (optional, not included; see 04-failsafe-boundary-log.md) stop one account's token from being written into another account's file.

2.4 Client and lead data

2.5 Client end customers

When the fleet operates a client's booking and marketing stack, it touches the client's customers' data:

2.6 Bus records

• Agent Office bridge state and action log.
• Tasks and approvals under ~/.cortextos/<instance>/orgs/<org>/tasks/ and approvals/. Task descriptions often name clients.
• Event log under ~/.cortextos/<instance>/orgs/<org>/analytics/events/.

3. Third parties that receive data

Check which plan and terms cover each provider. Consumer and subscription terms differ from commercial terms on training use and retention. Keep a signed data processing agreement on file for any provider that processes client data under a client contract.

4. Retention controls

The command-line tool is named cortextos.

Suggested starting values: 30 days for media, 90 days for message logs, and lead lists deleted at the end of the campaign plus the opt-out retention your email law requires.

5. Access and exposure

6. Compliance considerations

This is not legal advice. It lists which frameworks can apply to an OGL Cortex operator and what the software does and does not provide.

Client sites built by the fleet need their own privacy and terms pages. Add a /privacy check to the gate command that harness/tools/ship.sh runs.

7. Recommended controls

In order of impact for an install that handles client data:

1. Encrypt the disk. One host holds client PII, lead lists, OAuth tokens and secrets. Full-disk encryption is the single largest protection against theft or loss.
2. Document AI processing to clients. Everything a seat reads goes to the model provider; ingested memory goes to the embedding provider. Add a short standard clause to client agreements.
3. Set retention. Rotate message logs and media on a schedule, and preserve cited receipts first.
4. Keep personal facts out of boot files. ENTITIES.md and MEMORY.md load into every orchestrator session and are ingested daily. Store contact details for people in the client folder, not in boot files, and keep only a pointer in ENTITIES.md.
5. Close unused public endpoints. Every tunnel or Funnel mapping is a public surface. Remove mappings to ports with no listener.

Known limitations

• All seats run as one OS user. There is no file isolation between seats.
• Telegram logs and media have no built-in retention.
• Knowledge-base ingest sends memory content to the embedding provider; there is no per-file redaction step.
• The dashboard env file and seat .env files are plain text on disk.

Source files

• src/telegram/transcribe.ts
• src/telegram/media.ts
• src/telegram/logging.ts
• src/bus/system.ts
• src/bus/knowledge-base.ts
• src/daemon/agent-manager.ts
• src/cli/bus.ts (archive-tasks, prune-reminders, kb-ingest, kb-query)
• knowledge-base/scripts/mmrag.py
• OGL layer: harness/hooks/shared_surface_guard.py