Security-First Architecture
AgentX implements a defense-in-depth strategy with six distinct security layers. No single point of failure exists in the authentication chain. Every request is validated at the edge, at the proxy, and at the backend — ensuring that even if one layer is compromised, the remaining layers continue to enforce access control.
Server-Side Proxy Security Gating
Every API request to the chaos engine passes through a Next.js route handler that validates the active Supabase session before proxying to the backend. Unauthenticated requests are rejected at the edge with a 401 status, never reaching the Python infrastructure.
- Supabase session validation on every /api/chaos/* request
- Session tokens verified server-side via createRouteHandlerClient
- 401 rejection for missing or expired sessions
- 502 graceful fallback when backend is unreachable
Dual API Key + Hardware ID Authentication
All internal backend communication requires both an API key (X-API-Key: AOS-ALPHA-2026) and a hardware-bound identifier (X-Hardware-ID: AOS-V2-STABLE-LOCAL). This prevents unauthorized nodes from injecting chaos vectors even if they discover an endpoint.
- X-API-Key validated on every backend proxy call
- X-Hardware-ID binds requests to authorized hardware
- Keys rotated per deployment environment
- Rejected keys return immediate 403 with audit log
Hardware Verification Lock
The chaos engine is gated behind a hardware verification handshake. During bootstrap, the Vanguard dashboard polls the backend health endpoint to confirm the hardware ID matches the authorized configuration. If verification fails, all chaos vectors are disabled and the UI enters Hardware Restricted Mode.
- Runtime hardware handshake on dashboard boot
- Failed verification disables all attack triggers
- Visual indicator switches to Hardware Lock Active state
- Guardian system continues monitoring in restricted mode
Tier-Based Access Control
The admin authorization module enforces tier-gated access to restricted attack vectors. Server crash bombs require enterprise or founder tier access. The system checks user email against the admin registry and validates tier privileges before allowing any controlled fault injection.
- canExecuteVector() validates tier + vector combination
- server_crash restricted to Enterprise and Founder tiers
- GlassLockModal UI blocks unauthorized attempts
- Server-side 403 response for bypassed client checks
End-to-End Token Verification
The full request lifecycle ensures token integrity at every hop: the browser session token is validated by the Next.js route handler, which then attaches its own authenticated headers (X-Forwarded-User, X-User-Tier) when proxying to the Python backend. The backend independently verifies these headers.
- Browser → Next.js: Supabase session token
- Next.js → Backend: X-Forwarded-User with verified email
- Backend receives X-User-Tier for access decisions
- Full audit trail from request to response
Next.js Middleware Enforcement
The middleware layer at src/middleware.ts intercepts all requests to /admin/*, /dashboard/*, and /login routes. During the Alpha phase, mock mode bypasses authentication to allow local development, while production deployments enforce full session verification on all protected routes.
- Route matching for /admin/:path*, /dashboard/:path*, /login
- Mock mode detection via environment variable inspection
- Production middleware enforces session validation
- Graceful pass-through for static assets and API routes