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.
• MCP Server - Tooling for IDE and agent integration via the Model Context Protocol.

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, /api/api-keys) require a valid Bearer token verified against PocketBase via auth-refresh before proxying requests. Token verification is not prefix-only - every request round-trips to PB to confirm the token is valid and not expired.
• Ownership enforcement: The /api/api-keys endpoint enforces per-user ownership on all CRUD operations. Users can only list, create, modify, or delete their own API keys. The PATCH endpoint whitelists writable fields to enabled and name only - sensitive fields (key_hash, user, scope) cannot be overwritten. All record IDs are validated with a strict regex to prevent PocketBase filter injection.
• 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.

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: Forwarded to xAI's Grok API for processing when using Ask AI. We log metadata only (timestamps, message count) - never raw message content. Requires a positive credit balance. Per xAI’s privacy policy, API-submitted data is not used to train their models.

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.

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. The hosting environment does not retain swap, memory snapshots, or crash dumps - all in-flight data is ephemeral to the process lifetime.

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 GitHub, Google, 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 against PocketBase via auth-refresh on every request. Invalid or expired tokens are rejected with HTTP 401. Tokens are hashed using a non-cryptographic hash (DJB2) for rate-limit partitioning and audit correlation only - never for authentication or security decisions. DJB2 hash collisions only affect bucket grouping; they cannot elevate privileges, bypass authentication, or access another user’s data. The raw token is never stored server-side.
• API keys (dual header support): Programmatic access uses ci_-prefixed API keys. Keys are accepted via the X-API-Key header (preferred) or Authorization: Bearer ci_... over HTTPS. Keys are SHA-256 hashed at rest in PocketBase - the raw key is never stored.
• API key collection rules: The PocketBase api_keys collection has all rules set to null (admin-only). Only server-side code with admin credentials can query or modify key records - unauthenticated PB API access is blocked at the database level.

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.
• 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. Secrets are rotated on a quarterly cadence or immediately upon suspected exposure. Production and development environments use separate credential sets.
• Stripe redirect whitelist: Stripe checkout and portal redirect URLs are validated against an allowlist of permitted hosts (collapseindex.org, www.collapseindex.org, localhost:4323). Spoofed Host or X-Forwarded-Host headers fall back to a hardcoded origin, preventing open redirect attacks via header injection.
• Middleware isolation: The Astro middleware no longer falls back to PocketBase when an /api/* route returns 404. All PocketBase admin API routes are explicitly listed in a fast-path allowlist - unknown paths are not proxied, preventing exposure of PB’s internal API surface.
• DDoS mitigation: Volumetric DDoS protection is provided by Render’s edge network, which handles TLS termination, connection limiting, and upstream rate limiting before traffic reaches the application layer. Application-level rate limiting (per-user bucketing) provides a secondary defense against authenticated abuse.

Security headers

The following HTTP security headers are enforced on production responses:

7. LLM Security

The Ask AI 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. Messages are scanned as-is (no Unicode normalization is applied; NFKC normalization for homoglyph-aware scanning is a planned improvement). Matches are rejected with randomized refusal responses. Regex detection is an additive defense layer and is not relied upon as the sole control - it operates alongside role restriction, system prompt isolation, and tool sandboxing.
• System prompt IP protection: The system prompt contains explicit rules forbidding the model from disclosing engine internals, proprietary algorithms, default parameter values, or implementation details.
• 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

• Session ID encoding: Fleet session IDs in dashboard API routes are passed through encodeURIComponent() to prevent path injection.

9. Engine Safety Guarantees

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

• Fixed-size buffers: All buffers are statically sized with zero heap allocation on the hot path.
• No overflow: All fixed-point arithmetic uses wider intermediates to prevent overflow, with proper rounding.
• Safety-first defaults: The engine initializes at the most restrictive authority level. Trust must be earned through stable predictions - it is never assumed.
• Value semantics: Output structures are returned by value - no heap cloning or pointer sharing.
• Fault codes: Well-defined fault codes with a watchdog timer for timeout detection.

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. 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.

12. Transparency

All CI-1T components - the Rust engine, dashboard, and MCP server - are proprietary. Security-relevant behavior is documented in this whitepaper and our Privacy Policy.

13. 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 or usage reporting.
• No use of your prediction scores to train any models.

14. Security Audit & Hardening Practices

Last audit: February 26, 2026 · Covers commits up to 0e2e3fd (v2.15.0)

Dependency scanning

All 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:

• Bandit - Python static security analyzer. ci1t-mcp: 0 medium+ findings.
• 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)
• How are auth decisions made? (OAuth tokens via PocketBase, Bearer header validation)
• Where are secrets stored and used? (server-side env vars)
• 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)

Adversary categories considered:

• Authenticated malicious user - abuses rate limits, submits injection payloads, attempts privilege escalation via PATCH field overwrite.
• Compromised OAuth token - stolen session used to exfiltrate data or burn credits. Mitigated by per-request PB validation and bounded session lifetimes.
• Stripe replay attacker - replays webhook payloads to double-credit accounts. Mitigated by signature validation, LRU dedup, and atomic writes.
• Prompt injection attacker - attempts to extract system prompt, engine internals, or bypass role restrictions. Mitigated by regex detection, role restriction, and system prompt rules.
• SSRF attacker - crafts webhook URLs targeting internal services or cloud metadata endpoints. Mitigated by URL validation and redirect refusal.
• Supply chain attacker - compromises a transitive dependency. Mitigated by Dependabot, lockfile pinning, and multi-tool audit pipeline.
• Infrastructure compromise (Render) - considered out of scope; mitigated by stateless architecture (no data to exfiltrate from compute containers) and encrypted PB volumes.

OWASP Top 10 alignment

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.

Payment security

• Webhook idempotency: Stripe webhook events are tracked by event ID in a bounded LRU map (max 1,000 entries). Duplicate deliveries return HTTP 200 without double-crediting user accounts. Note: extremely high-volume replay attacks exceeding the LRU capacity could theoretically evict entries and allow re-processing; in practice, Stripe signature validation and the atomic credit writes provide secondary protection.
• Atomic credit operations: Both deductCredits() and addUserCredits() re-read the user’s balance from PocketBase before writing, preventing time-of-check/time-of-use (TOCTOU) race conditions on concurrent requests.
• Retry-safe webhooks: Webhook processing errors return HTTP 500 so Stripe retries automatically. Previously returned 200 on error, which could silently lose paid credits.
• Stripe signature validation: All webhook payloads are verified via stripe.webhooks.constructEvent() with the endpoint-specific signing secret before any processing occurs.

Startup security

• No secrets in logs: OAuth provider configuration is logged as a safe summary (character count + provider count) - client IDs and secrets are never echoed to stdout.
• Admin-only collection rules: The api_keys collection rules are set to null (admin-only) on every deploy. A smoke test verifies unauthenticated access is correctly blocked (expects HTTP 403).

Supply chain CVE response

• Lodash prototype pollution (Feb 2026): Transitive lodash <4.17.23 carried a prototype pollution vulnerability. Patched by adding overrides.lodash: ">=4.17.23" to package.json.
• Markdown link XSS (Feb 2026): Chat markdown renderer accepted arbitrary URL protocols in [text](url) links, including javascript:. Fixed by adding an https?:// protocol allowlist - non-HTTP links render as plain text.
• Rollup path traversal (Feb 2026): Dependabot flagged a High-severity arbitrary file write via path traversal in rollup <4.59.0 (transitive via astro → vite → rollup). Crafted filenames with ../ sequences bypassed the sanitizer and allowed path.resolve() to write outside the output directory. Patched by adding overrides.rollup: ">=4.59.0" to package.json. Verified via npm ls rollup (4.59.0) and npm audit (0 vulnerabilities).

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 an adversarial testing approach focused on bypassing existing controls.

15. Data Retention

We do not maintain long-term archives of user activity beyond what is described above. Account deletion cascade-removes user records, API keys, and external auth entries from PocketBase.

16. Incident Response

Security incidents are handled according to defined severity levels:

• Containment: Affected services are isolated or taken offline. Credentials rotated immediately if compromise is suspected.
• User notification: Affected users are notified via email with a description of the incident, impact scope, and remediation steps.
• Postmortem: All Critical and High incidents produce a written postmortem within 7 days, including root cause, timeline, and preventive measures. Postmortems for public-facing incidents are published on our blog.

17. Business Continuity & Recovery

All compute services run on Render with zero-downtime deploys and automatic health checks. The Rust engine and Astro dashboard are stateless - a fresh container is healthy immediately. PocketBase data resides on an encrypted persistent disk; recovery requires restoring the latest backup to a new volume.

18. Shared Responsibility Model

Security is a shared effort between CI-1T and its users:

19. Security Program

CI-1T maintains a documented security program with the following governance structure:

• Named security owner: Alex Kwon (Founder) serves as the designated security lead responsible for all security decisions, incident response, and control maintenance.
• Annual risk assessment: A formal threat-model review of all components is conducted annually, covering new features, dependency changes, and evolving attack surfaces.
• Quarterly access review: OAuth provider configurations, PocketBase admin credentials, Render access, and Stripe dashboard permissions are audited quarterly. Unused credentials are revoked.
• Change management: All code changes require pull request review. Security-relevant changes (auth, payment, rate limiting, prompt injection) are flagged for additional scrutiny. Direct pushes to main are prohibited for security-sensitive paths.
• Security training: As a solo-founder operation, the security owner maintains currency through adversarial testing, CVE monitoring, and active participation in security communities.

20. SOC 2 Alignment

CI-1T aligns its controls with the SOC 2 Trust Services Criteria (Security, Availability, Confidentiality). While not yet formally certified, the following mapping demonstrates control alignment:

21. Key Management

API keys, secrets, and credentials follow a formalized lifecycle:

22. Access Governance

• Role-based access: Three access tiers exist - (1) end users (OAuth, dashboard features), (2) API key holders (programmatic access, scoped permissions), (3) admin (PocketBase admin, Render console, Stripe dashboard). Each tier has distinct permissions with no overlap.
• Principle of least privilege: The Rust engine has zero access to user data, databases, or network. Dashboard API routes only access the specific PocketBase collections they need. No service account has broad permissions.
• Admin MFA: PocketBase admin access requires credentials stored in Render’s encrypted environment. Render console access is protected by the provider account’s MFA. Stripe dashboard requires its own MFA.
• Offboarding: When a team member leaves (or in a solo-founder scenario, if the project transfers ownership): all admin credentials are rotated, OAuth provider configurations are reviewed, Render access tokens are regenerated, and Stripe API keys are rolled.
• Quarterly access audit: All active admin sessions, OAuth provider configurations, and API key counts are reviewed quarterly. Dormant credentials are revoked.

23. Log Governance

Audit and application logs follow formal governance:

• Access restriction: Application logs are written to Render’s managed log stream. Only the Render account owner can access log data. Logs are not accessible to end users or API consumers.
• Data classification: Logs contain metadata only - timestamps, service names, event types, hashed identifiers, HTTP status codes, and latency. PII (emails, tokens, message content) is never logged.
• Retention: Render retains log data for 7 days. For compliance-sensitive deployments, log forwarding to a customer-managed SIEM or long-term store can be configured at the Render level.
• Tamper resistance: Logs are managed by Render’s infrastructure and are append-only from the application’s perspective. The application cannot modify or delete previously written log entries.
• Review cadence: Logs are reviewed as part of the quarterly security audit, with particular attention to authentication failures, rate-limit events, and unusual traffic patterns.
• Alerting: Render provides built-in health check failure alerts. Rate-limit threshold breaches are logged with sufficient detail for post-incident analysis.

24. Security Roadmap

The following hardening milestones are planned or in progress:

25. Vulnerability Disclosure

We operate a responsible disclosure policy. If you discover a security vulnerability in any CI-1T component:

• Security contact: ask@collapseindex.org
• Acknowledgment: Within 48 hours of receipt.
• Scope: API, dashboard, PocketBase configuration, MCP server.
• Safe harbor: Security researchers acting in good faith will not face legal action for responsibly reported vulnerabilities.

Please do not publicly disclose vulnerabilities until we have had a reasonable opportunity to address them. We aim to resolve Critical issues within 24 hours and High issues within 7 days of confirmation.

26. 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