# Security questionnaire (CAIQ-lite)

**Codelux AI** — answers as of 28 September 2026, for release 3.7.
Contact: **hello@codelux.ai**. Companion documents: `DPA-template.md`,
`deployment-guide.md`, `responsible-disclosure.md`.

How to read the answers: **Yes / No / Partial / Not yet / From 3.7**, then the fact. Features
marked "From 3.7" need release 3.7 or later of the app and of the website; earlier
versions do not have them. Where something is missing we say so; nothing here is a certification claim.

---

## A. Company and governance

| # | Question | Answer |
|---|---|---|
| A1 | Who provides the service? | A sole proprietor trading as Codelux (codelux.ai), established in Italy. Registered name, address and VAT number are in the Privacy Policy, section 11, and on request. |
| A2 | Do you hold SOC 2, ISO 27001 or similar certifications? | **No.** No SOC 2, ISO 27001, ISO 27701, CSA STAR or other certification yet. |
| A3 | Is there a documented information-security policy? | **Partial.** Security rules are written into the codebase (design documents, code comments, review reports) and this pack; there is no formal ISMS. |
| A4 | Who is responsible for security? | The proprietor. There is no separate security team. |
| A5 | How many people have access to production systems and customer data? | One: the proprietor. |
| A6 | Do staff sign confidentiality agreements / receive security training? | Not applicable today (no employees). Any future staff or contractor with access will be bound by confidentiality before access is granted. |
| A7 | Is there a data protection officer? | No DPO is appointed (not required at this scale). Data-protection contact: hello@codelux.ai. |
| A8 | Which supervisory authority is competent? | The Italian Garante per la Protezione dei Dati Personali. |
| A9 | Is a DPA available? | **Yes.** GDPR Art. 28 template in `DPA-template.md`; countersigned on request. |
| A10 | Do you carry cyber-insurance? | Not stated in this pack; ask us for current status. |

## B. Architecture and data flows

| # | Question | Answer |
|---|---|---|
| B1 | What does the product do? | A local app (single binary) that gives AI coding agents a project memory, notes, a timeline, a code index and file locks between agents, exposed over MCP, REST and CLI on the user's machine. The Team plan shares that knowledge between members, end-to-end encrypted. |
| B2 | Where does customer source code go? | **Nowhere.** Source code, the code index and the local databases stay on the user's machine. No source code or project content is sent to Codelux's servers. |
| B3 | What does the Codelux server receive? | Account data (email, name, bcrypt password hash); licence data (SHA-256 of the machine identifier, SHA-256 of the binary, installation id, IP address and country code); the project list (project names and local folder paths); for teams: membership and roles, device public keys, team key version number, invitation log, lock/presence metadata (relative file path, no content), and team events **as ciphertext** with delivery metadata. |
| B4 | What do teammates receive? | Team events (memories, notes, journal, facts, code maps, timeline events, chat) sealed on the author's machine with the team key; each teammate's app decrypts them locally. |
| B5 | Does Codelux send data to an AI provider or proxy AI traffic? | **No.** The agent talks to its model provider directly under the customer's own account; Codelux is not in that path and keeps no log of it. |
| B6 | Does the product send telemetry or analytics from the app? | No usage telemetry. The app's network traffic is the licence check (heartbeat), release/terms checks, the signed dashboard UI bundle, and on Team the realtime connection. |
| B7 | Which network endpoints does the app contact? | `https://codelux.ai` (443, licence, account, UI bundle); `rt.codelux.ai:4222` over TLS (Team realtime only); the local dashboard page, in the user's browser, loads the Monaco editor and Mermaid from `cdn.jsdelivr.net`. |
| B8 | Does the app listen on the network? | Only on loopback: `127.0.0.1` and `[::1]`, port 8766 by default (configurable). Nothing listens on external interfaces. |
| B9 | Is there an on-premise / self-hosted server option? | **Yes, for integrations (4.1):** the company hub, `codelux-hub`, included with Team and Enterprise, runs on the customer's machine and executes the connectors (Jira, Linear, Asana, Azure Boards, GitHub, GitLab, Slack notifications). An organization is either all on Codelux's hosted service or all on its hub. The hosted service has no connector and never holds customer tokens. |
| B10 | Does the product work offline? | **No.** The licence is checked every 60 seconds; after three consecutive failed checks (about 15 seconds) the app goes offline and refuses writes until the next good check; the signed offline grace is capped at 2 minutes. An offline / air-gapped mode does not exist yet. |
| B11 | Can the customer choose where team data is stored? | No choice needed: the only region is the EU (Frankfurt, Germany). |

## C. Encryption in transit

| # | Question | Answer |
|---|---|---|
| C1 | Is all traffic encrypted in transit? | **Yes.** HTTPS to codelux.ai, TLS to the realtime service. A release build refuses to start if its licence-server URL is not `https://`, and refuses a realtime URL that is not `tls://`. |
| C2 | Where is TLS terminated? | Web traffic: at Cloudflare's edge, then over HTTPS to the origin (Let's Encrypt certificate). Realtime: directly on the origin server. |
| C3 | Is HSTS enabled? | Yes: two years, includeSubDomains. |
| C4 | Are licence responses protected beyond TLS? | Yes. Every licence-server response is signed with Ed25519 (public key embedded in the binary), encrypted with a per-account AES-256 key, and must echo the request's random nonce, so a fake or replayed response is rejected. |
| C5 | Are app updates / UI code authenticated? | The dashboard UI bundle is Ed25519-signed and verified before use. The app binary itself is **not code-signed** (no Windows Authenticode, no Apple notarization) yet; downloads carry SHA-256 headers for integrity. |
| C6 | Local dashboard ↔ app traffic? | Plain HTTP over loopback (never leaves the machine). The session cookie is HttpOnly and SameSite=Strict. |

## D. Encryption at rest and key management

| # | Question | Answer |
|---|---|---|
| D1 | Is team content encrypted end to end? | **Yes.** AES-256-GCM with a 256-bit team key. The additional authenticated data binds each event to team, project, key version and author, so the server cannot move, relabel or re-attribute an event. |
| D2 | Where is the team key generated and stored? | Generated on the team owner's machine. Stored only on members' machines, sealed (D6). **Never sent to Codelux**: the server stores only the key's version number. |
| D3 | How is the team key distributed to new members? | Machine to machine over the realtime service in an envelope sealed with static-static X25519 between the two devices' registered keys + HKDF-SHA256 + AES-256-GCM; the recipient accepts it only if the sender's key matches a key registered for that sender. The server relays it but cannot open it. It can also be handed over out of band as a 64-character hex string. |
| D4 | Can Codelux recover a lost team key? | **No.** No copy, no escrow, no recovery. If every member loses it, the stored ciphertext is permanently unreadable. |
| D5 | Is key rotation supported? | **Yes.** The owner's app rotates the key (for example after removing a member); a rotation adds a new version, old versions stay on members' machines so history remains readable to them. From 3.7, SCIM deprovisioning requests a rotation. |
| D6 | How are local secrets protected? | Device token, identity, team keys, the device X25519 key pair are sealed with AES-256-GCM under a key derived from the machine identifier (PBKDF2-SHA256, 50,000 iterations): a copied file does not open on another machine. The state directory is restricted to SYSTEM, Administrators and the installing user (Windows, inheritance removed) or mode 0700 (Linux/macOS); a directory owned by someone else is refused. This does not protect against the machine's own user or malware running as that user. |
| D7 | Are the local project databases encrypted? | **No, by design** (as with other local developer tools): the index, knowledge, timeline and log databases are plaintext files in the project's `.codelux` folder. We recommend full-disk encryption (BitLocker, FileVault, LUKS). |
| D8 | How are server-side data protected at rest? | Passwords with bcrypt. Recoverable secrets (from 3.7: SSO client secrets) with AES-256-GCM, key held outside the database. SCIM tokens stored as hashes. Team content is ciphertext the server cannot decrypt. The server disk itself is not described here as encrypted. |
| D9 | Who controls the server's signing keys? | The proprietor. The licence signing key never leaves the server; the binary carries only the public key. |
| D10 | What residual trust is placed in the server for key exchange? | Device public keys are distributed by the server. A compromised server could try to substitute a public key during a key hand-over; there is no in-app fingerprint verification yet. Teams that need to exclude this can hand the key over out of band (D3). |

## E. Identity and access management

| # | Question | Answer |
|---|---|---|
| E1 | How do users authenticate? | Email + password, with a one-time email code (6 digits, CSPRNG, short expiry, 5 attempts) on every sign-in that issues credentials — website and app. |
| E2 | Password policy? | Minimum 10 characters with letters and digits, not equal to the email; stored with bcrypt. |
| E3 | Brute force and enumeration? | Per-IP and per-email rate limits on every public authentication endpoint; identical responses and constant-time checks for unknown accounts. |
| E4 | SSO? | **From 3.7:** per-organisation SSO with OIDC (Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak) and SAML 2.0, with an optional "require SSO for this domain" rule (password and social sign-in disabled for those addresses, except the owner's break-glass account). Social sign-in (Google, GitHub, Slack) also from 3.7. |
| E5 | SCIM provisioning? | **From 3.7:** SCIM 2.0 user provisioning and deprovisioning with an organisation bearer token (stored hashed). Deprovisioning removes the member from the owner's teams and requests a team-key rotation. |
| E6 | Roles and least privilege? | Three roles (4.1): Admin (buys and administers; the organisation's Admins see all teams), Manager (coordinates one team, in the app) and Member (works). Managers add and remove the members of their own teams and see the Manager workspace and the audit export; members see their own work. Organisation admins administer all the owner's teams but cannot delete the organisation or change billing. |
| E7 | How is access revoked? | Removing a member stops their access at the next licence check (at most 60 seconds) and closes their realtime session; the realtime credential lasts 15 minutes at most. Data already on their machine stays there (local-first); rotate the team key to protect what is written afterwards. |
| E8 | Device control? | Paid builds are bound to one machine; one Codelux runs per machine, and across machines the latest sign-in wins. Each account holder can revoke their devices from the Console (My account › Account › Devices). |
| E9 | Who can call the local API? | Browsers only with the dashboard session cookie and a loopback Origin/Host (cross-origin pages and DNS rebinding are refused). Non-browser processes on the same machine (the CLI, the MCP client, scripts) are admitted without a token: the local machine user is trusted. Malware running as that user can use the API. A per-session token for local callers is not implemented. |
| E10 | Administrative access to production? | SSH with public-key authentication only (password login disabled), by the proprietor. |

## F. Application security

| # | Question | Answer |
|---|---|---|
| F1 | Secure development practices? | Written threat notes next to the code, regression tests for every security fix, security review before releases; releases built from a single development tree and promoted by hand. |
| F2 | Input validation and injection? | Prepared statements for every SQL query; request bodies capped on public endpoints; strict path containment in the local file API (traversal, symlink and junction escapes refused); protected-file deny lists (secrets, CI configs, git hooks) for agent writes; command execution restricted to an allow-list with a sanitised environment. |
| F3 | Web security headers? | HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, an enforced narrow CSP (base-uri, object-src, frame-ancestors, form-action); the full script/style CSP is still report-only. |
| F4 | Third-party code in the product? | Go and PHP dependencies pinned in the repository. The local dashboard loads Monaco and Mermaid from jsDelivr **without Subresource Integrity yet**. |
| F5 | Is the binary protected against tampering? | A release binary refuses to run without its embedded public key or with a non-TLS server URL; the server checks the binary's hash against the builds it produced. |
| F6 | Can an AI agent push code or change branches on its own? | Branch operations for agents are read-only; `git push` from an agent requires a human approval in the dashboard. |

## G. Logging, monitoring and audit

| # | Question | Answer |
|---|---|---|
| G1 | What is logged server-side? | Security and account events (registration, sign-in, 2FA changes, plan changes) — 12 months; sessions, heartbeats and device online/offline — 30 days; invitation log — 12 months; from 3.7 an organisation audit log of SSO/SCIM/admin changes. |
| G2 | What is logged in the app? | A timeline of every write: memories, notes, file edits through the app or the plugin hooks, locks taken/released/refused, commits, messages between agents, project changes — each with person, agent and time. Deletions keep the previous content. |
| G3 | Can we export audit data? | **Yes.** Any user can export the timeline (JSON or CSV, what they see or everything). Team owners and admins can download a team audit ZIP (members, projects, timeline, memories, notes, code maps, checkpoints, lock history). Both are produced locally, because the server cannot decrypt team data; every export is itself recorded as an audit event. |
| G4 | Is chat included in the audit export? | No, by design: chat and chat groups are excluded. |
| G5 | SIEM integration / log streaming? | **Not yet.** Exports are files; with the company hub (`codelux-hub`) the Manager's confirmed standups and finished tasks can be notified to Slack, executed by the hub. |
| G6 | Are logs tamper-evident? | Not cryptographically. The team timeline is replicated to every member's machine, so one copy cannot be silently rewritten everywhere. |
| G7 | Security monitoring and alerting? | Rate-limit triggers and failed-authentication events are logged; the realtime service bans IPs sending forged credentials. There is no 24/7 monitoring team. |

## H. Vulnerability management and testing

| # | Question | Answer |
|---|---|---|
| H1 | Have you had a penetration test? | **Yes, internal only.** Two penetration tests in September 2026, performed by Codelux itself — not by an independent third party: (1) the public website and API at codelux.ai; (2) the local app (dashboard and API on loopback). Neither found a critical or high-severity issue; one low-severity operational observation. |
| H2 | What did the external test cover? | Security headers, cookies, account enumeration, rate limits, authentication and access control on API routes without a token (401), the payment webhook without a valid signature (400), injection, information leaks, open redirects, CORS. |
| H3 | What did the local test cover? | Cross-site requests and DNS rebinding against the local API (blocked by Origin/Host checks and SameSite cookies), path traversal (refused), protected files and secret leaks through file operations, the command allow-list and its environment, information leaks. |
| H4 | Other security reviews? | 14/09/2026 review of the public sign-in and registration endpoints: two issues found and fixed (a timing difference that revealed whether an email had an owner account on one endpoint; request bodies without a size cap). 15/09/2026 four-part code review (website, app, realtime service, dashboard UI): 38 findings, one critical — a shared HTML note rendered in an iframe could run script with the dashboard's privileges and read the team key — fixed with the others before the Team plan launched. One item is kept as a design choice (E9). |
| H5 | What has not been tested yet? | A dedicated penetration test of the realtime service (cross-team tokens, replay), a cross-account access-control test with two real accounts, and an adversarial test of the app–server licence protocol. No independent third-party test yet. |
| H6 | Vulnerability disclosure program? | Yes: `responsible-disclosure.md` — acknowledgement within 3 business days, fix or mitigation plan within 30 days for confirmed issues. No paid bug bounty. |
| H7 | Patch management for the server? | The production host runs a current Ubuntu release, patched by the proprietor; the web and realtime services are redeployed with a backup of the replaced files. No formal patch SLA yet. |
| H8 | Dependency scanning? | Not automated yet. |

## I. Incident response

| # | Question | Answer |
|---|---|---|
| I1 | Is there an incident response plan? | **Partial.** Responsibilities and notification duties are defined (proprietor; DPA clause 7); there is no separately tested runbook yet. |
| I2 | How fast are customers notified of a breach? | Without undue delay and in any case within the period agreed in the DPA (template: 48 hours). |
| I3 | What would a server breach expose? | Account and licence data, team metadata, lock/presence metadata and ciphertext. Team content stays unreadable without the team key, which the server never holds. |
| I4 | Can you cut off a compromised member or device? | Yes: remove the member or revoke the device (effective at the next licence check, at most 60 seconds), then rotate the team key. |

## J. Business continuity

| # | Question | Answer |
|---|---|---|
| J1 | What happens if Codelux's servers are down? | The app needs the licence server: after about 15 seconds without a successful check it refuses writes, and the Team realtime stops. Local data is not lost; work resumes on the next successful check. |
| J2 | Hosting redundancy? | Single virtual server (Kamatera, Frankfurt) behind Cloudflare. No multi-region failover. |
| J3 | Backups? | Each deployment keeps a backup of the replaced files. A formal, tested backup-and-restore policy for the account database is not documented yet. Team content also exists on every member's machine. |
| J4 | RTO / RPO commitments? | **Not yet.** No contractual SLA. |
| J5 | What if Codelux ceases business? | The Terms commit to at least 60 days' notice of a permanent discontinuation, a pro-rata refund, and best efforts to release a final app update that reduces the dependency on the servers. Local data remains on the customer's machines in open (bbolt) database files; the timeline and audit exports are JSON/CSV. |

## K. Sub-processors

| # | Question | Answer |
|---|---|---|
| K1 | Which sub-processors do you use? | Kamatera (server hosting, Frankfurt, Germany); Cloudflare (DNS, CDN, TLS, abuse protection; USA/global edge); Dynadot (mailbox and transactional email; USA); Stripe (payments; USA). |
| K2 | Transfer safeguards for non-EU sub-processors? | EU Standard Contractual Clauses; Cloudflare also under the EU-US Data Privacy Framework. |
| K3 | Are AI providers sub-processors? | No. Codelux sends nothing to AI providers. |
| K4 | How are changes to sub-processors notified? | By email in advance (DPA template: 30 days), with a right to object. |

## L. Data residency, retention and deletion

| # | Question | Answer |
|---|---|---|
| L1 | Where is customer data stored? | Account database and realtime service: Frankfurt, Germany (EU). Local data: on the customer's machines. Email and payment data pass through the US providers in K1. |
| L2 | Retention periods? | Account data while active; sessions/heartbeats/devices 30 days; security events 12 months; invitation log 12 months; team metadata and encrypted events while the team exists; locks/presence at most 24 hours; billing records 10 years (Italian fiscal law). |
| L3 | Can a team be deleted immediately? | Yes. The owner deletes it from the Console (Teams): encrypted events, cursors, locks, presence, key-request log, folder paths and pending invitations are erased at once (realtime erasure within seconds). A history entry remains until the owner deletes it too. |
| L4 | What happens on account deletion? | The account is disabled: name, password and 2FA settings erased, sessions revoked; the email and machine hash are kept for abuse prevention and billing records for the fiscal period. |
| L5 | Can we get our data back? | Team content: from the app (timeline export, audit ZIP), since only your machines can decrypt it. Account metadata: JSON on request. |
| L6 | Data on employees' machines after they leave? | It stays on those machines; Codelux cannot erase it remotely. Manage it with your device management, and rotate the team key. |

## M. Endpoint and deployment

| # | Question | Answer |
|---|---|---|
| M1 | Supported platforms? | Windows x64; Linux x86_64 and ARM64; macOS Apple Silicon and Intel. macOS is the newest and least field-tested port. |
| M2 | Installer packages (MSI, PKG, DEB/RPM)? | **Not yet.** One ZIP with one executable per platform. See `deployment-guide.md`. |
| M3 | Service mode? | Windows service (auto-start) and systemd unit via `codelux install-service`. Not on macOS yet. The service runs as LocalSystem / root. Optional micro-apps are refused under the Windows service; the same block for the Linux service is not implemented yet. |
| M4 | Silent, pre-activated mass deployment? | **Not yet.** Each paid user downloads a personal build from the Console (My account › Downloads) and authorises the device by signing in. |
| M5 | Automatic updates? | **Not yet.** The app shows when a newer version is available; the binary is replaced by the user or IT. The dashboard UI updates itself (signed bundle). |
| M6 | Proxy support? | HTTPS calls honour `HTTPS_PROXY` / `NO_PROXY`. The Team realtime connection needs direct outbound TLS to `rt.codelux.ai:4222`; proxying it is not supported yet. |
| M7 | Multi-user machines, VDI, terminal servers? | One Codelux per machine: only one user at a time on a shared host. |

## N. Privacy and legal

| # | Question | Answer |
|---|---|---|
| N1 | Is there a privacy policy? | Yes, published at codelux.ai/legal (current version v9). |
| N2 | Legal bases? | Contract (licence, authentication, project list), legitimate interest (security, fraud prevention, anonymous page-flow analytics), legal obligation (tax), consent (optional analytics). |
| N3 | Data-subject requests? | hello@codelux.ai, subject "GDPR Request"; answered within 30 days. |
| N4 | Direct messages in team chat — private from other members? | No. They are encrypted with the same team key every member holds; the separation is in the interface only, and the app says so. |
| N5 | Per-member reports and monitoring of workers? | The Manager's per-member views and exports (3.7) describe work progress. Their use towards employees is the customer's responsibility under its labour rules. |