Zero Standing PrivilegesFinancial Infrastructure & TradingSOX 404 · FINRA 3110 · SEC 17a-4

Just-in-Time (JIT) Production Access

An enterprise engineering playbook for financial institutions to eliminate standing administrative privileges: multi-stage dual-control approval workflows, Zanzibar caveated ephemeral tuples (5–60 min TTL), sub-millisecond Redis PDP fast paths, instant kill-switches (<50ms), and automated SHA-256 Merkle audit trails (with optional paid Thales Luna Cloud HSM hardware root-of-trust).

Phase 01: Core Philosophy & Tiers

Zero Standing Privileges (ZSP) Architecture

Under strict regulatory regimes such as SOX 404 and FINRA Rule 3110, persistent access to production FIX order routing gateways, equities matching engines, and core clearing ledgers represents a severe operational liability.

AuthHub enforces Zero Standing Privileges (ZSP). All production access is ephemeral: granted only after authenticated justification, bound to a specific Change Advisory Board (CAB) ticket, time-limited via caveated SpiceDB relations, cached in Redis for high-speed Policy Decision Points (PDP), and purged automatically upon completion.

Production JIT Classification Matrixauthorization-mode-manager.ts
TierAsset ClassificationMax TTLApproval MandateEnforcement
Tier 0Core Clearing Ledger & FIX Gateway300s–900s (5–15m)Dual Control (Desk Head + Risk)Redis Hot Path + Teleport Lock
Tier 1Pricing Services & Market Feeds600s–1800s (10–30m)Trading Desk Head ApprovalSpiceDB Caveated Tuples
Tier 2Internal Quant Analytics & Risk DBs1800s (30m)Tech Lead / Peer AttestationSpiceDB Caveats
Tier 3Staging, Sandbox & UAT3600s (60m)Self-Service with JustificationStandard ReBAC Relation
Phase 02: Enterprise Identity Sync

Identity Synchronization (SCIM 2.0)

AuthHub synchronizes human operators, trading desk supervisors, and compliance officers from Okta or Entra ID using SCIM 2.0. Financial enterprise attributes (department, supervisory registrations, cost centers) are mapped to evaluate eligibility for production escalation.

POST /scim/v2/Users — Inbound Provisioning
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "marcus.vance@apex-capital.com",
  "name": { "givenName": "Marcus", "familyName": "Vance" },
  "emails": [{ "value": "marcus.vance@apex-capital.com", "primary": true }],
  "roles": [
    { "value": "quant_systems_engineer", "primary": true },
    { "value": "incident_commander_oncall" }
  ],
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "EMP-80411",
    "costCenter": "CC-EQUITIES-TRADING",
    "division": "Global Markets & Algorithmic Trading",
    "department": "High-Frequency Execution Infrastructure"
  },
  "active": true
}
Phase 03: Zanzibar Caveated ReBAC Schema

Fine-Grained Ephemeral Relations & Caveats

In AuthHub’s SpiceDB schema, permissions are not statically granted to roles. Instead, the relation between the user and the critical resource is established with conditional caveats that check timestamp validity, task ID context binding, and dual-control sign-off counts.

schema.zed — SpiceDB Caveated Model
// Caveat definitions
caveat expiration(current_time timestamp, expires_at timestamp) {
  current_time < expires_at
}

caveat task_binding(task_id string, expected_task_id string) {
  task_id == expected_task_id
}

caveat dual_control(approval_count int, required_count int) {
  approval_count >= required_count
}

definition production_target {
  relation platform: enterprise_organization
  
  // Permanent governance roles (Zero Standing Execution Privileges)
  relation technical_owner: user
  relation risk_approver: user
  relation escalation_contact: user

  // Ephemeral JIT relations (bound via caveats)
  relation jit_operator: user with expiration and task_binding
  relation jit_admin: user with expiration and task_binding and dual_control

  // Derived permissions checked by the Policy Enforcement Point (PEP)
  permission view_telemetry = technical_owner + jit_operator + jit_admin
  permission execute_maintenance = jit_operator + jit_admin
  permission emergency_reconfigure = jit_admin
}

definition enterprise_organization {
  relation member: user
}

definition user {}
Phase 04: Submitting a JIT Request

Submitting an Emergency JIT Request

When an operational emergency occurs, engineers submit an authenticated request to the JIT management endpoint. Requests require a ServiceNow/Jira change or incident ticket, justification, and hardware MFA telemetry.

POST /api/v1/jit/requests
curl -X POST https://authhub.apex-capital.internal/api/v1/jit/requests \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1Ni..." \
  -H "Content-Type: application/json" \
  -d '{
    "target_resource": "production_target:ny4-fix-gateway-cluster",
    "requested_permission": "emergency_reconfigure",
    "tier": 0,
    "requested_ttl_seconds": 900,
    "ticket_id": "CAB-INC-8902",
    "justification": "Primary FIX drop NY4 session disconnect during pre-market open; restart listener socket & flush TCP backlog",
    "client_telemetry": {
      "source_ip": "10.240.14.88",
      "hardware_token_id": "yubikey-5c-ser-992140",
      "mfa_verified_at": "2026-09-18T14:32:00Z"
    }
  }'
Phase 05: Multi-Stage Dual Control

Multi-Stage Approval State Machine

AuthHub’s ApprovalChainService manages multi-stage approval policies with timeout escalation. Under the Four-Eyes Principle, Tier 0 production modifications require two independent approvals:

Stage 1: Technical Owner

Trading Desk Head / Lead Systems Architect validates that the commands, parameters, and incident scope match standard runbooks.

Stage 2: Risk & Compliance

Risk Manager confirms market regulatory restrictions (SEC Rule 15c3-5 Market Access, Reg SHO thresholds) will not be breached.

POST /api/v1/jit/requests/req-8902/approve — Approver Sign-off
curl -X POST https://authhub.apex-capital.internal/api/v1/jit/requests/req-8902/approve \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsIn..." \
  -H "Content-Type: application/json" \
  -d '{
    "stage_index": 1,
    "approver_role": "risk_approver",
    "decision": "approved",
    "approver_notes": "Verified FIX reconnect scope limited to NY4 listener socket; no order book tampering risk",
    "risk_attestation_signature": "0x78fbc91024bc0192e4001923..."
  }'
Phase 06: Ephemeral Tuple Issuance

SpiceDB Tuple Issuance & Redis Fast Path

Upon dual approval, issueJitToken creates an ephemeral caveated relationship in SpiceDB and writes the active session key into Redis with strict TTL (EX 900).

src/services/nhi/authorization-mode-manager.ts
async issueJitToken(tenantId: string, userId: string, taskContext: JitTaskContext): Promise<JitToken> {
  const ttlSeconds = JIT_TTL[taskContext.tier] ?? 900;
  const expiresAt = new Date(Date.now() + ttlSeconds * 1000).toISOString();
  const tokenId = crypto.randomUUID();

  // 1. Write Ephemeral Caveated Tuple to SpiceDB
  await this.writeJitTuple(tenantId, userId, {
    resource: taskContext.resourceId,
    relation: 'jit_admin',
    caveat: {
      name: 'expiration',
      context: { current_time: new Date().toISOString(), expires_at: expiresAt }
    }
  });

  // 2. Store in Redis Hot-Path Cache for Sub-Millisecond PDP Checks
  await this.redis.set(
    `gov:nhi:jit:${tokenId}`,
    JSON.stringify({ userId, tenantId, resourceId: taskContext.resourceId, operation: taskContext.operation }),
    'EX', ttlSeconds
  );

  return { token: tokenId, expiresAt, scope: [taskContext.operation], userId };
}
Phase 07: Real-Time Kill-Switch

Instant Session Termination (<50ms)

If real-time behavioral telemetry detects anomalous commands outside the approved CAB scope, the emergency kill-switch severs the active session in under 50ms: deleting the Redis PDP key and broadcasting a Teleport Lock / Envoy TCP drop signal.

POST /api/v1/jit/tokens/jit-tok-9844-ef21/revoke
curl -X POST https://authhub.apex-capital.internal/api/v1/jit/tokens/jit-tok-9844-ef21/revoke \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1Ni..." \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "Anomalous command execution outside CAB-8902 scope",
    "revoked_by": "secops_automated_defense",
    "terminate_active_connections": true
  }'
Phase 08: Expiry Sweep & Merkle Audit

Automated Garbage Collection & Merkle Audit

HSM: Optional Paid Add-On

When the token TTL expires, AuthHub’s spicedb_gc worker purges expired tuples from SpiceDB. Every lifecycle transition is anchored into an immutable SHA-256 Merkle hash chain certified with RFC 3161 timestamps.

Standard InclusionIncluded on All Tiers

Software-backed ECDSA P-256 digital signing with RFC 3161 TSA timestamping over per-tenant Merkle roots. Provides mathematical non-repudiation and cryptographic audit verification out-of-the-box.

Thales Luna Cloud HSMPaid Enterprise Add-On

For institutions with strict hardware security mandates, AuthHub offers a dedicated partition on Thales Luna Cloud HSM (DPoD). Keys are non-exportable and FIPS 140-2 Level 3 certified, satisfying the most stringent national bank and sovereign wealth fund audits.

GET /api/v1/audit/records/jit-tok-9844-ef21 — Luna HSM Attestation
{
  "chain_id": "merkle-jit-2026-09-18",
  "block_height": 140922,
  "merkle_root": "0x4e8a10bc39e102f9a77c88019bcae91204859a0f019a...",
  "rfc3161_timestamp": "2026-09-18T14:49:02.104Z",
  "hsm_slot": "Luna-Network-HSM-7-Partition-Trading",
  "entries": [
    { "index": 0, "event": "JIT_ACCESS_REQUESTED", "ticket_id": "CAB-INC-8902" },
    { "index": 1, "event": "DUAL_CONTROL_APPROVAL_COMPLETE", "approvers": 2 },
    { "index": 2, "event": "EPHEMERAL_TUPLE_WRITTEN", "ttl_seconds": 900 },
    { "index": 3, "event": "ACCESS_EXPIRED_AND_PURGED", "worker": "spicedb_gc" }
  ],
  "tamper_evident_verified": true
}

Regulatory Readiness for Financial Auditors

Every step of this workflow produces artifacts that directly satisfy SOX Section 404 (ITGC Access Controls), FINRA Rule 3110 (Supervisory Reviews), and SEC Rule 17a-4 (Immutable Record Retention). Reports can be downloaded directly from the AuthHub Audit Center with one-click cryptographic verification.