This document describes the security architecture, threat model, hardening practices, and vulnerability disclosure process for the Concord Cognitive Engine. It is intended for operators, contributors, and security researchers.

1. Reporting Vulnerabilities
2. Supported Versions
3. Authentication and Authorization
4. Token Lifecycle
5. OAuth Integration
6. Middleware and Transport Security
7. Input Sanitization
8. Rate Limiting
9. Concord Shield -- Threat Detection
10. Concord Mesh -- Transport Security
11. Content Moderation
12. Economy Security
13. GRC Invariants -- Output Safety
14. Privacy Zones
15. LLM Security Considerations
16. Infrastructure and Container Hardening
17. Data Security and Encryption
18. Unsafe Surfaces Registry
19. Environment Security
20. Dependency Security
21. Ethos Invariants
22. Compliance Considerations
23. Incident Response

Do not file public GitHub issues for security vulnerabilities.

If you discover a security vulnerability in Concord, please report it through responsible disclosure:

When reporting, please include:

• A clear description of the vulnerability and its potential impact.
• Detailed steps to reproduce, including environment details.
• Any proof-of-concept code or screenshots.
• Your preferred attribution name (if you wish to be credited).

We will acknowledge receipt within 48 hours, provide an initial severity assessment within 7 days, and work with you on a coordinated disclosure timeline. We will not pursue legal action against researchers acting in good faith.

Only the current major release receives full security patches. The previous major release receives critical-severity fixes only.

Concord supports four authentication modes, configured via AUTH_MODE:

• Algorithm: bcryptjs
• Default rounds: 12 (configurable via BCRYPT_ROUNDS)
• Registration is rejected if the bcrypt module is unavailable, preventing plaintext storage

The first registered user is automatically assigned the owner role with wildcard (*) scopes. Subsequent users receive the member role with read and write scopes. Privileged operations check for admin, owner, or founder roles, or the economy:admin scope.

Administrative operations in the economy subsystem accept a FOUNDER_SECRET header as an operational backdoor. This comparison uses crypto.timingSafeEqual to prevent timing side-channel attacks.

All authentication cookies are set with the following attributes:

HttpOnly:  true     (inaccessible to JavaScript)
Secure:    true     (HTTPS only, in production)
SameSite:  Strict   (no cross-site transmission)

Revoked tokens are tracked across three layers for defense in depth:

1. In-memory Set -- immediate invalidation, no I/O latency
2. SQLite -- persistent across restarts
3. Redis -- shared across instances (when federation is enabled)

Refresh tokens are organized into families. If a refresh token that has already been rotated is presented again (indicating theft and replay), the entire token family is invalidated, forcing the legitimate user to re-authenticate and locking out the attacker.

• State parameter: A 32-byte cryptographically random hex string is generated per authorization request and validated on callback to prevent CSRF.
• Apple client secret: Generated as a short-lived ES256 JWT signed with the Apple private key, not stored as a static string.
• Provider availability: OAuth routes are only mounted when the corresponding environment variables are configured. Unconfigured providers return 404.
• No external OAuth libraries: Token exchange uses Node.js built-in fetch (Node 18+) to minimize supply-chain risk.

All responses include the following headers, enforced at both the application layer (Helmet.js) and the reverse proxy layer (nginx):

• Script nonce: A 16-byte random nonce is generated per request via crypto.randomBytes(16) and injected into the CSP script-src directive.
• Production mode: unsafe-eval is removed; only nonce-authenticated and unsafe-inline scripts are allowed.
• Development mode: unsafe-eval is permitted for hot-reload tooling.
• Frame sources: Blocked (frame-src 'none').
• Object sources: Blocked (object-src 'none').
• Form actions: Restricted to 'self'.

• In production, ALLOWED_ORIGINS must be explicitly set. Wildcard origins are not permitted.
• credentials: true is enabled for cookie-based authentication.
• The connect-src CSP directive is dynamically populated from ALLOWED_ORIGINS.

State-changing requests (POST, PUT, DELETE, PATCH) require a valid CSRF token using the double-submit cookie pattern:

Cookie:  _csrf=<token>
Header:  X-CSRF-Token: <token>

The server validates that the header value matches the cookie value. The frontend API client handles this automatically.

Per-endpoint body size limits prevent denial-of-service via oversized payloads:

• Request ID: Every request receives a unique identifier for tracing.
• Request timeout: Configurable per-request timeout to prevent hung connections.
• Compression: gzip compression at the application and nginx layers.
• Idempotency: Write operations support idempotency keys to prevent duplicate effects.

All user input is sanitized before processing. The sanitization middleware detects and blocks the following attack vectors:

Blocked patterns:
  <script>...</script>
  Event handlers: onclick=, onerror=, onload=
  Protocol handlers: javascript:
  Data URIs: data:*;base64

Logged and monitored patterns:
  UNION SELECT, INSERT INTO, DROP TABLE
  DELETE FROM, UPDATE SET, EXECUTE

Note: Concord uses parameterized queries (prepared statements) via better-sqlite3 as the primary SQL injection defense. The sanitization layer provides defense-in-depth logging and alerting.

Blocked keys in request bodies:
  __proto__, constructor, prototype

Rate limiting is enforced at multiple layers:

The nginx rate limiting operates independently of the application layer, providing defense against attacks that bypass the application.

Concord Shield is a three-layer security architecture that orchestrates open-source security tools and feeds all findings into the DTU lattice.

  Incoming Data
       |
       v
  [ SCAN ] -----> ClamAV (malware), YARA-X (patterns)
       |
       v
  [ ANALYZE ] --> Suricata (network IDS), Snort (IPS), Zeek (behavioral)
       |
       v
  [ FORTIFY ] --> OpenVAS (vulnerabilities), Wazuh (SIEM/host monitoring)
       |
       v
  Threat DTU --> Pain Memory (never pruned)

• Every detection is stored as a threat DTU tagged with pain_memory.
• Pain memory DTUs are never pruned by the forgetting engine.
• Threat signatures propagate to all users in one heartbeat tick, providing collective immunity: a threat detected for one user instantly protects all users.
• Meta-derivation runs cross-threat pattern discovery across all threat DTUs.

1. Additive only -- Shield never modifies existing systems.
2. Silent failure -- Shield itself never crashes the platform.
3. Every detection is a DTU -- full audit trail.
4. Pain integration -- every threat becomes pain memory, never pruned.
5. Collective immunity -- one detection protects all users.
6. All through chat -- no separate security UI.

Concord Mesh provides infrastructure-independent DTU transmission across seven transport layers, each with distinct security characteristics.

• Self-verifying: Every DTU carries a SHA-256 content hash in its 48-byte header. Recipients verify integrity without relying on TLS or channel security.
• Self-contained: DTUs require no server lookup, no session state, and arrive complete. No man-in-the-middle can inject partial state.
• Store-and-forward: DTUs survive disconnected operation. No persistent connection is required. The DTU waits for the next available channel.
• Automatic routing: The mesh selects the optimal transport path. Users never manually pick channels, reducing misconfiguration risk.
• Adaptive failover: If a channel drops, the next available channel picks up instantly with no data loss.

The moderation system supports ten report categories:

  User Report / Auto-Flag
         |
         v
  [ Pending ] --> [ Reviewing ] --> [ Resolved ]
                       |                  |
                       v                  v
                 [ Escalated ]     [ Dismissed ]

1. Flag -- mark content for review
2. Warn -- issue a warning to the user
3. Restrict -- limit content visibility
4. Remove -- remove content (preserving original for restoration)
5. Suspend -- suspend user account
6. Restore -- restore previously removed content

Repeated violations escalate through a strike system: warnings progress to temporary suspensions and, for persistent violations, permanent action.

Content is automatically flagged via keyword pattern matching and pattern detection. Auto-flagged content enters the moderation queue with the source recorded as auto_keyword or auto_pattern.

Every moderation action produces an audit log entry. Content is never silently removed. Every action has a paper trail, and removed content can be restored.

The Concord economy handles token transfers, purchases, and marketplace transactions with financial-grade safety guarantees.

All transfers execute inside a single SQLite transaction. If any step fails, nothing commits. There is no partial state:

BEGIN TRANSACTION
  1. Validate sender balance (inside transaction to prevent race conditions)
  2. Compute fee
  3. Create debit record (sender)
  4. Create credit record (recipient)
  5. Create fee record (platform)
COMMIT   (all-or-nothing)

Balance validation occurs inside the SQLite transaction, not before it. This prevents time-of-check-to-time-of-use (TOCTOU) race conditions where concurrent requests could overdraft an account.

Every economy action is logged to the audit_log table with the following fields:

Audit entries are written to both the SQLite database (persistent) and console (real-time monitoring).

The Governance, Risk, and Compliance (GRC) module enforces seven core invariants on all system outputs before they reach users.

When an invariant check fails, the GRC module attempts automatic repair:

1. The payload is analyzed to identify the violation.
2. A repair is attempted that preserves the semantic intent.
3. If repair succeeds, the output continues with a repair annotation.
4. If repair fails, the output is blocked and the failure is logged.

Repairs follow strict rules: no new claims are introduced, semantic intent is preserved, and content is never sanitized to the point of uselessness.

System jargon patterns (e.g., references to DTUs, substrates, lattices, macros, Ollama, brain cortex) are automatically removed from user-facing output to prevent information leakage about internal architecture.

The Atlas Signal Cortex implements a four-tier privacy architecture with absolute guarantees at the highest level.

Interior data for ABSOLUTE zones is never generated. The reconstruction algorithm skips the interior volume entirely. There is nothing to reveal, filter, or hide -- the data does not exist.

The following are suppressed at every privacy tier, including sovereign:

• Personal presence detection -- no person-tracking at any level.
• Vehicle tracking -- no vehicle identification or tracking at any level.

These suppressions cannot be overridden by any role, configuration, or API call.

When using LLM features (chat, forge, dream), the following mitigations are in place:

Cloud LLM features require explicit opt-in at two independent levels:

1. Environment level: CLOUD_LLM_ENABLED=true must be set.
2. Session level: The user must explicitly enable cloud LLM per session.

No data is sent to external LLM APIs without both levels of consent.

For maximum data sovereignty, Concord supports local LLM via Ollama:

OLLAMA_HOST=http://localhost:11434
OLLAMA_MODEL=llama3.2
LLM_ENABLED=true
CLOUD_LLM_ENABLED=false

In this configuration, no data leaves the host machine.

• Rate limiting at the reverse proxy layer (independent of application).
• Security headers applied at the nginx level as well as the application level.
• Let's Encrypt ACME challenge path exposed for automated certificate renewal.
• client_max_body_size aligned with backend limits.

• Each user's DTUs are isolated by ownerId.
• Permission system controls read, write, and delete access.
• Global DTUs require council approval.

# Backups stored in DATA_DIR/backups
# Restrict permissions to the owning process user only
chmod 700 /data/backups

The following capabilities expose attack surface beyond standard CRUD operations. Each is disabled by default in production unless explicitly enabled.

curl -s http://localhost:5050/api/status | jq '.infrastructure.capabilities'

Returns:

{
  "sqlite": true,
  "jwt": true,
  "bcrypt": true,
  "ollama": true,
  "exec": false,
  "federation": false,
  "whisper": false,
  "piper": false,
  "imagegen": false
}

The following must be set before deploying to production:

JWT_SECRET=<minimum 32 characters, 64+ recommended>
ADMIN_PASSWORD=<minimum 12 characters>
NODE_ENV=production
ALLOWED_ORIGINS=https://your-domain.com

Never commit secrets to version control.

Security-relevant events are logged to the audit_log table:

• Authentication attempts (success and failure)
• Authorization failures
• Rate limit triggers
• Input sanitization triggers (potential attack attempts)
• Admin actions
• Economy transactions

Access audit logs via /api/auth/audit-log (admin-only endpoint).

Optional dependencies with native code (better-sqlite3, @xenova/transformers) are:

• Only installed when explicitly needed.
• Compiled in isolated Docker build stages.
• Not required for core functionality (the system falls back gracefully).

These security-relevant principles are immutable and enforced at runtime. They cannot be changed by configuration, environment variables, or API calls:

NO_TELEMETRY           The system never phones home.
NO_SECRET_MONITORING   No hidden tracking or monitoring.
NO_USER_PROFILING      No behavioral analysis or profiling.
CLOUD_LLM_OPT_IN_ONLY Explicit two-level consent required for cloud LLM.

Concord's architecture supports compliance with common regulatory frameworks:

1. Isolate -- Disconnect affected systems from the network immediately.
2. Preserve -- Capture logs, database snapshots, and system state before any changes.
3. Rotate -- Change all secrets: JWT_SECRET, FOUNDER_SECRET, SESSION_SECRET, API keys, and database credentials.
4. Notify -- Report to the security team at security@concord-os.org.
5. Analyze -- Review audit logs (/api/auth/audit-log), economy audit entries, and nginx access logs to determine scope.
6. Remediate -- Apply patches, update dependencies, and harden configurations based on findings.
7. Communicate -- Notify affected users per your disclosure obligations.

Before deploying to production, verify the following:

• ENABLE_TERMINAL_EXEC is absent or set to false
• JWT_SECRET is at least 32 characters (64+ recommended)
• ADMIN_PASSWORD is at least 12 characters
• ALLOWED_ORIGINS is explicitly set (no wildcards)
• NODE_ENV is set to production
• GRAFANA_USER and GRAFANA_PASSWORD are explicitly set (no defaults)
• nginx security headers verified via curl -I https://your-domain.com
• /api/status confirms "exec": false
• npm audit shows no high or critical findings
• Grafana bound to localhost or behind VPN
• TLS certificate is valid and HSTS is active
• Backup directory permissions set to 700
• Log rotation is configured

This document is maintained alongside the codebase. If you identify inaccuracies or have suggestions for improvement, please submit a pull request or contact security@concord-os.org.