How It Works

Request flow through CIFP from client to upstream.

This page walks through exactly what happens when a request passes through CIFP — from your client to the upstream API and back.

Auto-Auth Mode Flow

bash

Client                     CIFP Proxy                    Upstream API
  │                            │                               │
  │── CONNECT api.openai.com ──►│                               │
  │   (proxy auth: user:pass)  │                               │
  │                            │ ← authenticate with auth DB   │
  │                            │                               │
  │── GET /v1/models ──────────►│                               │
  │   Authorization: Bearer    │                               │
  │       {$OPENAI_API_KEY}    │                               │
  │                            │ ← resolve {$OPENAI_API_KEY}   │
  │                            │   from encrypted SQLite       │
  │                            │── GET /v1/models ────────────►│
  │                            │   Authorization: Bearer       │
  │                            │       sk-proj-real-key        │
  │                            │◄── 200 OK ────────────────────│
  │◄── 200 OK ─────────────────│                               │

The real key never touches your client. The client only ever sees its proxy credential (username + password) and the response from the upstream.

Firewall Mode Flow

Firewall mode adds TLS interception and CEL rule evaluation:

bash

Client                     CIFP Proxy                    Upstream API
  │                            │                               │
  │── CONNECT api.stripe.com ──►│                               │
  │                            │ MITM: issue cert for          │
  │◄── TLS handshake (CIFP CA)─│ api.stripe.com signed by     │
  │                            │ CIFP mitmproxy CA             │
  │                            │                               │
  │── POST /v1/charges ────────►│                               │
  │   (plain HTTP inside TLS)  │ ← evaluate CEL rules:        │
  │                            │   request.host=="api.stripe.com"
  │                            │   && request.method=="POST"   │
  │                            │   → action: ALLOW             │
  │                            │                               │
  │                            │ ← inject credentials          │
  │                            │── POST /v1/charges ──────────►│
  │                            │   Authorization: Bearer       │
  │                            │       sk_live_real_key        │
  │                            │◄── 200 OK ────────────────────│
  │◄── 200 OK ─────────────────│                               │

Proxy Authentication

CIFP's authentication layer validates the proxy Proxy-Authorization header against the credential store on each connection. Each credential is:

Unique to a proxy (username encodes the proxy ID)
Independently revocable without affecting other credentials
Optionally scoped to specific proxy ports
Optionally expiring

Secret Resolution

CIFP's credential injection layer intercepts every outgoing request header before forwarding. It scans header values for ${VAR_NAME} patterns, looks up the decrypted value from the encrypted store, and rewrites the header in-flight.

Secrets are stored encrypted with AES-256-GCM using a per-proxy key provisioned at creation time. The key never touches disk and never appears in logs.

CEL Rule Evaluation (Firewall Mode)

CEL rules are evaluated in priority order (lower number = higher priority). The first matching rule's action is applied:

allow — request proceeds normally
deny — CIFP returns 403 immediately; request is logged
hitl — request is held; a notification appears in the dashboard; the operator approves or denies within the timeout window

If no rule matches, the request is allowed by default. Add a catch-all deny rule at low priority (e.g. priority 9999) to flip this to deny-by-default.