Request Flow

Authentication Architecture

ArmorIQ uses a JWT-based authentication system:

User ──▶ Sign In ──▶ Backend issues JWT (15min access + refresh token)
                           │
                           ▼
              Frontend stores tokens in localStorage
                           │
                           ▼
              All API calls include:
              • Authorization: Bearer <accessToken>
              • X-Organization-Id: <orgId>
                           │
                           ▼
              On 401 → auto-refresh via /auth/refresh → retry
              On refresh failure → redirect to /auth

Three auth paths converge at the proxy:

Auth Method	Used By	Flow
JWT Bearer	Enterprise SDK	Frontend/SDK → `/iap/process` → receives proxy JWT
API Key	Customer SDK	SDK sends `X-API-Key` header → proxy validates via backend
CSRG Proof	Direct CSRG	Sends `X-CSRG-Path` + `X-CSRG-Proof` headers with token in body

Organization Isolation

Every resource is scoped to an organization:

Frontend sends X-Organization-Id header with every authenticated request
Backend verifies the user is a member of the specified organization
All database queries are filtered by orgId
Proxy extracts orgId from token claims
CSRG embeds orgId in plan metadata for audit trails

End-to-End Request Flow

When an AI agent makes a tool call through ArmorIQ:

1. SDK/Agent requests an intent token
   POST /iap/process → Backend
   
2. Backend validates client + policies, builds plan document
   Backend → POST /intent → CSRG-IAP
   
3. CSRG builds reasoning graph, computes Merkle tree, signs token
   Returns: intent_reference, token, plan_hash, reasoning_graph
   
4. Backend wraps in proxy JWT with step proofs
   Returns proxy_token + plan_id + step_proofs[] to SDK
   
5. SDK makes tool call through proxy
   POST proxy.domain.com/tool
   Headers: Authorization: Bearer <proxy_token>
            X-CSRG-Path: /steps/[0]/tool
            X-CSRG-Proof: [merkle_siblings]
   
6. Proxy authenticates + validates:
   a. Verify JWT signature (HS256/RS256)
   b. Verify composite identity
   c. Backend /iap/verify-step (checks plan state)
   d. CSRG /verify/action (cryptographic Merkle proof)
   
7. If all checks pass → forward to target MCP server
   
8. Response returned to SDK + audit log created

Security Layers

Layer	Mechanism	Purpose
Authentication	JWT + OAuth + API Keys	Verify identity
Authorization	Policy engine (PEP/PDP)	Enforce access rules
Intent Verification	CSRG signed tokens	Prove plan authorization
Tamper Detection	Merkle tree proofs	Detect plan modifications
Trust Chain	Trust deltas (ReAnchor/Delegate/Revoke)	Track trust transitions
Audit	Merkle audit logs	Non-repudiable event trail
Domain Isolation	Domain mapping + DNS verification	Ensure traffic routing integrity

Authentication Architecture

Organization Isolation

End-to-End Request Flow

Security Layers

On this page