Authentication & Security
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Authentication and Security in the ZINC Fusion V15 project encompasses the protection of institutional-grade commodity forecasting data and the integrity of the multi-layer machine learning pipeline. The system utilizes Edge-compatible authentication tokens and strict environment isolation to prevent cross-contamination between projects, particularly during serverless execution on Vercel.
The security architecture is designed to protect sensitive data sources (FRED, Databento, USDA) and ensure that only authorized payloads are processed by the forecasting models. Security measures extend beyond user access to include data integrity gates, such as anti-hallucination checks in AI-generated intelligence and strict environment variable management.
Sources: README.md:3-8, AGENTS.md:5-10, frontend/src/lib/ai-intelligence.ts:8-12
Token-Based Authentication
The project implements a custom authentication mechanism optimized for Edge environments. This system relies on HMAC-SHA256 signatures to verify the authenticity of tokens without requiring heavy dependencies.
Auth Token Structure
Tokens follow a simplified JWT-like structure consisting of a base64url-encoded payload and a signature, separated by a period.
| Component | Description |
|---|---|
| Payload | Contains versioning (v) and "issued at" (iat) timestamp metadata. |
| Signature | An HMAC-SHA256 hash of the payload using a server-side secret. |
Sources: frontend/src/lib/auth-edge.ts:1-5, frontend/src/lib/auth-edge.ts:47-50
Verification Logic
The verification process involves recalculating the HMAC signature and performing a timing-safe comparison to prevent side-channel attacks.
The diagram above illustrates the Edge-compatible verification flow used to authorize requests.
Sources: frontend/src/lib/auth-edge.ts:32-68
Environment Isolation & Secrets
Strict environment boundaries are enforced to prevent cross-project contamination, specifically between ZINC Fusion and unrelated projects like "Rabid Raccoon."
Critical Environment Constraints
Environment variables are used to manage service connections and security parameters. The project enforces specific values for Inngest client identification and database concurrency to maintain stability.
- Inngest Client ID: Must be set to
fusion-jobs. - Database Concurrency: Capped at 5 with
envscope to prevent connection pool exhaustion. - Secret Management: Sensitive keys (Anthropic, FRED, Database URL) must never be hardcoded and must reside in
.env.
Sources: cubic.yaml:26-35, cubic.yaml:39-45, AGENTS.md:100-105
Preflight Security Checks
The project includes automated scripts to verify the security and integrity of the environment before and after changes.
def check_env():
# Verify critical keys exist in .env
critical_keys = ["DATABASE_URL"]
# Verify structure and directory permissions
critical_files = ["AGENTS.md", ".env", "prisma/schema.prisma"]
Sources: scripts/preflight_check.py:65-90
Data Integrity & AI Security
Security in V15 includes the "Anti-Bullshit Gate," a verification layer for AI-generated market intelligence. This ensures that the AI does not fabricate data or include stale information in institutional reports.
Freshness Requirements
- AsOfDate Echo: All AI responses must echo the input
asOfDateto verify data currency. - Verification Gate: Responses without matching timestamps are rejected to prevent hallucinated or cached data from entering the dashboard.
- No Guesswork Policy: AI models are forbidden from guessing; required data (VIX, Crush, CNY) must be verified before being passed to the model.
Sources: frontend/src/lib/ai-intelligence.ts:10-20, frontend/src/lib/ai-intelligence.ts:125-135
Inngest Security Rules
Inngest functions are wrapped in security guardrails to ensure idempotent execution and avoid duplicated side effects.
- Side Effect Isolation: All database queries and API fetches must be wrapped in
step.run()to prevent accidental replays during serverless execution. - Dedup Patterns: New code must use
ON CONFLICT DO UPDATEwithrow_hashfor change detection to prevent data corruption.
Sources: cubic.yaml:47-58, cubic.yaml:96-105
Database Security
ZINC Fusion uses Prisma for schema management but relies on raw connection pools for runtime performance.
Schema Guardrails
The project enforces a strict schema policy, banning specific naming conventions (e.g., raw, gold, silver) to maintain the integrity of the 12 authorized functional schemas.
| Authorized Schemas | Purpose |
|---|---|
mkt, econ, supply | External data landing |
training, model | Machine learning artifacts |
forecasts, analytics | Derived intelligence and results |
ops | Operational logging and auditing |
Sources: AGENTS.md:15-22, scripts/preflight_check.py:155-180
Summary
The Authentication & Security system in ZINC Fusion V15 focuses on Edge-compatible verification, strict environment isolation, and data integrity. By utilizing HMAC-signed tokens and automated preflight checks, the system ensures that institutional commodity data remains secure and that machine learning outputs are derived from verified, point-in-time accurate data sources.