Security Whitepaper

1. Overview

CI-1T is a prediction-stability engine that measures whether AI model outputs are reliable. It accepts numeric prediction scores only — no raw text, images, model weights, or training data ever touch our infrastructure.

This document describes the security architecture across all three components of the CI-1T ecosystem:

• CI-1T API — Rust compute engine hosted on Render.
• CI-1T Dashboard — Astro SSR web application with PocketBase authentication.
• CI-1T Monitor (CLI) — Open-source Python CLI (Apache 2.0) that runs on your machine.

Audience: Engineering teams, security reviewers, and procurement teams evaluating CI-1T for production use.

2. Architecture

The system follows a defense-in-depth proxy pattern that separates authentication from computation:

• Authentication boundary: All dashboard API routes (/api/chat, /api/lab, /api/fleet-session) require a valid Bearer token before proxying requests to the Rust engine.
• Compute engine: The Rust API is a stateless compute service — it processes numeric arrays and returns stability metrics. It holds no user data and performs no authentication itself.
• CLI Monitor: Runs entirely on the user's machine. Communicates with the API over HTTPS to submit scores and receive evaluations.

3. Data Handling

What we process

• Prediction scores: Unsigned 16-bit integers (0–65,535) representing Q0.16 fixed-point probabilities. These are the only payload the engine accepts.
• Account metadata: Email and name from OAuth sign-in, stored in PocketBase.
• Chat messages (paid plans): Forwarded to xAI's Grok API for processing. We log metadata only (timestamps, message count) — never raw message content.

What we never process

• Model weights, architectures, or training data.
• Raw text, images, audio, or any non-numeric input.
• Personally identifiable information beyond OAuth profile data.
• CLI Monitor local files — profiles, state, and alert history remain on your machine.

Data at rest

The Rust engine is stateless by default. Scores are processed in-memory and discarded after the response is returned. Fleet sessions are held in-memory only and are lost on server restart — there is no disk persistence layer.

Internal engine metrics (T1/T2/T3 triplet weights, fleet ratios) are annotated #[serde(skip_serializing)] and never appear in API responses.

4. Authentication & Access Control

• OAuth 2.0: Dashboard sign-in via Google, GitHub, Apple, or X (Twitter) through PocketBase. No passwords are stored — authentication is fully delegated to OAuth providers.
• Bearer tokens: Every dashboard API route extracts and validates the Bearer token from the Authorization header. Tokens are hashed for rate-limit bucketing and audit logs — the raw token is never stored server-side.
• API keys: CLI and programmatic access use API keys. Keys are transmitted only in the Authorization header over HTTPS.
• Key storage (CLI): The Collapse Index CLI encrypts API keys at rest using platform-native mechanisms — Windows DPAPI, macOS Keychain, or Linux Secret Service. The CI-1T Monitor stores keys in local YAML profile files (~/.ci1t/profiles/).

5. Input Validation

Every component enforces strict input validation:

6. Network Security

• TLS everywhere: All communication between clients, dashboard, API, and PocketBase uses HTTPS with TLS certificate validation enforced.
• SSRF protection (CLI webhooks): The CLI Monitor validates all webhook URLs before delivery. Blocked targets include localhost, 127.0.0.1, ::1, 169.254.169.254 (cloud metadata), metadata.google.internal, and any IP that resolves to a private, loopback, reserved, or link-local address.
• Redirect rejection: The CLI Monitor's HTTP source fetcher explicitly refuses to follow redirects, preventing open redirect attacks.
• Webhook timeout: 5-second timeout on all webhook deliveries to prevent the monitor loop from stalling.
• API client retries: 3 attempts with linear backoff. Client errors (4xx) are not retried — only connection errors and server errors (5xx).
• Server-side API keys: The xAI API key and any third-party credentials are stored server-side as environment variables and never exposed to the browser.

7. LLM Security

The Ask Grok chat feature includes multiple layers of prompt injection defense:

• Injection pattern detection: 24+ regex patterns scan incoming messages for known jailbreak techniques — "ignore previous instructions," "DAN mode," "show me your prompt," role impersonation, and similar vectors. Matches are rejected with randomized refusal responses.
• System prompt IP protection: The system prompt contains explicit rules forbidding the model from disclosing engine internals, Q0.16 weight constants, threshold values, Rust source code, or FPGA RTL.
• Role restriction: Only "user" and "assistant" roles are accepted. System-role injection via message history is rejected.
• Tool sandboxing: The chat system's 7 built-in tools (evaluate scores, fleet evaluate, health check, etc.) execute server-side. Results are streamed via SSE — the client never executes tool logic.
• Metadata-only logging: Chat audit logs record timestamps, message counts, and rate-limit events. Raw message content is never logged.

8. File System & Path Safety

• Path traversal prevention: The CLI Monitor rejects profile names containing .., /, \, ~, or empty strings. The same validation applies to state file paths.
• Atomic writes: State files are written to a .tmp file first, then atomically renamed. A crash mid-write never corrupts existing state.
• Graceful recovery: Corrupt or invalid state files return None (never crash the monitor). State file version fields are validated.
• Session ID encoding: Fleet session IDs in dashboard API routes are passed through encodeURIComponent() to prevent path injection.

9. Engine Safety Guarantees

The Rust compute engine is designed for deterministic, memory-safe operation:

• Fixed-size buffers: Episode buffer is a fixed [u16; 8] array. Ghost history is a fixed [u16; 16] ring buffer. Zero heap allocation on the hot path.
• No overflow: All Q0.16 arithmetic uses u32 intermediates to prevent overflow, with proper rounding (+ 0x8000).
• Safety-first defaults: The engine initializes at Authority Level 4 (most restrictive). Trust must be earned through stable predictions — it is never assumed.
• Copy semantics: The output struct (Ci1tOutputs) implements Copy — returned by value via register moves, no heap cloning or pointer sharing.
• Fault codes: Well-defined 4-bit fault codes (0x0–0xA) with a hardware-inspired watchdog timer that fires FAULT_WATCHDOG on timeout.

10. Third-Party Infrastructure

We rely on the following third-party services:

We do not use analytics services, advertising networks, tracking pixels, or third-party cookies.

11. CLI Local Storage & Privacy

The CI-1T Monitor stores all configuration and state locally on your machine:

You control your data. Delete ~/.ci1t/ to remove all local CI-1T Monitor data.

12. Audit Logging

The dashboard uses a centralized audit logging system that records metadata only:

• Timestamps, service name, event type.
• Hashed user identifiers (for rate-limit correlation).
• Request latency and HTTP status codes.

Audit logs never contain: raw message content, API keys, bearer tokens, email addresses, or any personally identifiable information.

13. Open Source Transparency

The CI-1T Monitor CLI is open source under the Apache 2.0 license. You can audit the code that runs on your machine, verify the security claims in this document, and confirm exactly what data leaves your environment.

The Rust engine and dashboard are proprietary. Security-relevant behavior of these components is documented in this whitepaper and our Privacy Policy.

14. What We Don't Do

• No tracking cookies.
• No analytics pixels or third-party analytics services.
• No advertising identifiers.
• No data selling or sharing with data brokers.
• No telemetry from the CLI (opt-in or otherwise).
• No use of your prediction scores to train any models.

15. Security Audit & Hardening Practices

Last audit: February 24, 2026

Dependency scanning

All three codebases are regularly audited for known vulnerabilities in third-party dependencies using native package-manager tooling:

Static analysis

Rule-based static analysis tools are used to catch patterns that AI-assisted review may miss:

• Semgrep — scans Python and TypeScript source for injection, hardcoded secrets, insecure patterns, and common anti-patterns.
• Trivy — scans Dockerfiles and container images (ci1t-api) for misconfigurations and OS-level CVEs.
• GitHub Advanced Security / CodeQL — enabled on CI for automated taint tracking and dataflow analysis on every pull request.

Dynamic testing

Running applications are probed with automated tools that simulate real attacks:

• OWASP ZAP — proxy-based scanner that crawls the dashboard and probes for XSS, CSRF, open redirects, header injection, and other OWASP Top 10 issues.
• Mozilla Observatory — validates HTTP security headers (CSP, HSTS, X-Frame-Options, etc.) on the production domain.

Threat modeling

Each component undergoes a manual threat-model pass covering:

• Where does untrusted input enter? (API payloads, chat messages, webhook URLs, CLI config files)
• How are auth decisions made? (OAuth tokens via PocketBase, Bearer header validation)
• Where are secrets stored and used? (server-side env vars, CLI platform keychain)
• What happens on error paths and 500s? (generic error messages, no stack traces leaked)
• Can rate limits or DoS protections be bypassed? (per-user bucketing, session caps, body size limits)

Least privilege

• Containerized deployment: API runs in a minimal Docker container on Render with no shell access or persistent storage.
• Short-lived tokens: OAuth sessions have bounded lifetimes. Bearer tokens are validated on every request.
• Environment-variable secrets: API keys and credentials are stored in Render’s encrypted environment — never in source control or .env files committed to git.
• No broad permissions: The Rust engine has no file-system access, no database access, and no outbound network calls. It receives numbers and returns numbers.

Continuous monitoring

• GitHub Dependabot: Automatic alerts and pull requests when a dependency CVE is published.
• CI pipeline checks: npm audit, pip-audit, and cargo audit are run on every build to prevent vulnerable dependencies from shipping.
• Manual review cadence: Auth, payment, and data-flow code are reviewed quarterly with a “break your own app” adversarial mindset.

16. Vulnerability Reporting

If you discover a security vulnerability in any CI-1T component, please report it responsibly:

• Email: ask@collapseindex.org
• Response target: 48 hours for initial acknowledgment.
• Scope: API, dashboard, PocketBase configuration, webhook delivery.

Please do not publicly disclose vulnerabilities until we have had a reasonable opportunity to address them.

17. Contact

For general security questions or to request this whitepaper in PDF format:

ask@collapseindex.org

Collapse Index Labs™ · Alex Kwon · Santa Clara County, California