Security

TaurusX is designed with security as a first-class architectural concern — not an add-on. The platform uses a layered defence model: each surface enforces its own security controls, and all controls reinforce each other. No single point of failure can compromise the system.

The Phase 2 security baseline covers ten areas: web hardening, API hardening, mobile security, OS Chat input safety, Meta-Agent limits, Governance enforcement, Routing Engine isolation, Preferences encryption, Terminal/CLI hardening, and developer guidelines.

All TaurusX web surfaces (OS, Guardian Console, public site) enforce the following controls on every response:

CSRF Protection

TaurusX uses a double-layer CSRF defence. For JSON API calls, Origin/Referer headers are validated against the allowed-host list. For form-based submissions, the Double-Submit Cookie pattern is enforced: the tx_csrf cookie must match the X-CSRF-Token header. Bearer token and API-key callers are exempt (not browser CSRF targets).

XSS Prevention

All user-generated content (personal notes, profile fields, preferences) passes through sanitize.ts before storage and before rendering. The sanitizer strips dangerous HTML tags, event handlers, and javascript: / data: URIs. AI-generated Markdown is sanitized before rendering to prevent injected scripts.

Session Security

Authentication & Authorization

Every API endpoint is protected by one or more of: session cookie, Bearer token, or API key validation. All three are checked and validated against the database — not just verified for presence. The apiGuard() helper combines auth, role checks, IDOR validation, rate limiting, and input validation in a single composable call.

Input Validation

All JSON bodies, query parameters, and path parameters are validated against Zod schemas before processing. Validation errors return structured 400 responses with per-field issue details. Raw validation errors never reach production responses.

Rate Limiting

Sensitive endpoints — /api/security, /api/meta-agent,/api/governance, /api/preferences,/api/billing, /api/agents,/api/workflows — are on the 20 req/min strict tier.

Error Responses

Production API errors return a sanitized envelope: error (code),message (user-safe text). No stack traces, no file paths, no SQL details, no internal class names. Development environments include a dev field with the full error for debugging.

Safe Logging

All server-side logs pass through safeLog.ts. The logger automatically redacts Bearer tokens, session cookies, API keys, JWTs, email addresses, phone numbers, credit card numbers, and file paths before writing to stdout. Strings are truncated at 2,000 characters.

The TaurusX mobile app (iOS / Android) applies the following security measures:

The OS Chat Screen and Desktop Continuum apply a security pipeline to every message before it reaches the Routing Engine and before any response is rendered:

Prompt injection detection looks for patterns such as "ignore previous instructions", "DAN mode", injected system prompts via code fences, and role-reset instructions. Detected patterns are neutralized — the user message is still processed with the injected content replaced by a safety placeholder.

The meta-agent action registry defines exactly which actions the agent may execute. Any action not in the registry is rejected. Actions are classified by category (read / write / external / system) and risk level (low / medium / high / critical).

The Governance Engine evaluates every high-impact action before execution. Actions are classified by risk, reversibility, and external effect.

Governance rules are validated on creation using a strict Zod schema. Invalid configurations are rejected before saving — you cannot create a rule that would deny all low-risk actions or has a malformed condition value. All governance decisions (allow, deny, require-approval) are written to the immutable audit log.

User boundaries from Personal Preferences are enforced by the Governance Engine. Topics marked as off-limits are checked against every proposed action and response. Boundary violations are denied and logged.

Session ownership is validated on every routing request. If a session ID is presented for a different user ID than was registered at session creation, the request is rejected with a hard failure (not a safe fallback).

Personal Preferences — notes, boundaries, tone settings, accessibility flags — are stored using expo-secure-store on mobile (AES-256 hardware-backed) and in the encrypted session context on web. They are never stored in plaintext local storage or in unencrypted cookies.

Boundary enforcement runs on every AI response and action across all surfaces (web, mobile, terminal, meta-agent, voice). The boundary check happens inboundaryEnforcer.ts and is called before any content is sent to the user or any action is executed.

The CLI credential file (~/.taurusx/credentials.json) is written with mode 0o600 (owner-only read/write). The preferred storage is the OS keychain via keytar.

Required for every API route

• Use apiGuard() or manually call getSession() + hasRole()
• Validate all inputs with validateBody() / validateQuery() and a Zod schema
• Use safeError() / safeInternalError() in all catch blocks — never NextResponse.json({ error: err.message })
• Log with safeLog — never console.log for server events
• Check resource ownership for user-scoped routes (IDOR prevention)
• Add rate limiting via checkRateLimitPg() for mutating endpoints

Never do these

• Log tokens, passwords, session IDs, or API keys
• Return raw error.message or stack traces in production API responses
• Store tokens in AsyncStorage, localStorage, or cookies without HttpOnly
• Render user-provided content as HTML without passing it through sanitize.ts
• Hard-code secrets, API keys, or credentials in source files
• Skip governance checks for meta-agent actions that affect external systems
• Accept deep-link parameters named token, session, or api_key

Security modules reference