Concepts
Core building blocks of CIFP.
Understanding CIFP's core abstractions makes configuration straightforward. Each concept maps directly to a resource in the API.
Proxy
A Proxy is a dedicated virtual machine with its own dedicated IP address, running CIFP's enterprise-grade proxy stack. Each proxy has:
- A unique URL:
https://proxy-id.proxy.cifp.vril.dev:3128 - An isolated secret store (AES-256-GCM encrypted SQLite)
- Its own set of credentials, firewall rules, and IP allowlist
- A status:
pending,running,paused, orfailed
Each proxy is assigned a dedicated IP address and supports up to26,872 unique authentication credentials simultaneously — one per port in CIFP's multi-port range — all sharing the same IP. Proxies can be paused (VM stops, billing pauses) and resumed. Deleting a proxy permanently destroys all associated secrets.
Mode: Auto-Auth vs Firewall
Every proxy operates in one of two modes, chosen at creation time. The mode determines how CIFP intercepts and handles your outbound requests.
The simplest path to credential injection. You write a Bearer {$SECRET_NAME} placeholder into any request header. CIFP swaps it for the real value on the way out — no TLS interception, no CA cert, no code changes beyond the proxy URL.
- ✓Developers calling APIs from scripts, notebooks, or curl
- ✓Keeping secrets out of source code and CI pipelines
- ✓Sharing credentials across a team without distributing the real key
- ✓Any language or HTTP library — no SDK required
No extra setup. Point your client at the proxy URL and add the placeholder.
Full TLS interception (ssl-bump / MITM). CIFP decrypts every HTTPS request, evaluates it against a CEL rule set, injects credentials automatically, and re-encrypts before forwarding. Your code doesn't change at all.
- ✓AI agents making autonomous API calls
- ✓Auditing every outbound request for compliance
- ✓Blocking calls to unexpected domains or endpoints
- ✓Human-in-the-loop approval before sensitive calls go out
Requires installing the proxy's CA certificate on the client machine or container.
Not sure which to pick? Start with Auto-Auth. It covers the vast majority of use cases with zero extra setup. Reach for Firewall when you need to inspect, filter, or gate traffic — for example, before deploying an AI agent that will run autonomously.
Secret
A Secret is a named key-value pair stored encrypted in the proxy's SQLite database. Secret names follow env-var convention: UPPERCASE_WITH_UNDERSCORES.
- The value is never returned by any API — only the name and metadata
- Secrets are synced to the proxy's runtime store; changes take effect immediately
- Secrets can have an optional expiry date
- In auto-auth mode, use
Authorization: Bearer {$MY_SECRET}to inject
Credential
A Credential is a username/password pair that authenticates a client to the proxy itself (the Proxy-Authorization header). Each proxy can have multiple credentials:
- The username is deterministic:
proxy-id-randomsuffix - The password is randomly generated and returned only at creation
- Credentials can be scoped to specific proxy ports and can have expiry dates
- Revoking a credential immediately blocks future requests using it
Firewall Rule
A Firewall Rule is a named CEL expression with an associated action. Rules are evaluated in priority order on every request in firewall mode.
- action: allow — forward the request (inject credentials)
- action: deny — return 403 immediately
- action: hitl — hold for manual approval in the dashboard
IP Allowlist
An optional CIDR-based allowlist restricts which source IPs can connect to a proxy. When the allowlist is non-empty, any connection from an IP not matching a CIDR is rejected at the network layer before authentication even runs.
API Key
An API Key (cifp_...) is a programmatic credential for the CIFP control plane REST API. Unlike proxy credentials (which authenticate to the proxy itself), API keys authenticate to cifp.vril.dev/api. Keys have:
- Named scopes:
proxies:read,secrets:write, etc. - Optional expiry
- Individual revocation
Tenant
A Tenant is the account boundary. All proxies, secrets, and credentials belong to a tenant. In Phase 2, one user = one tenant. In Phase 3, multiple users can share a tenant (org mode). Tenants are isolated — secrets and credentials never cross tenant boundaries.