HopBaseThe short answer: enterprise security review of an LLM API vendor comes down to four layers — key governance (least privilege and instant revocation: a leaked key should burn alone, revocable in seconds without touching any other team's traffic), the data path (is request and response content ever persisted, which fields do logs keep and for how long, and can any of it be used for training), audit and reconciliation (every call traceable to a key, a model, and a token count — and failed requests never billed), and vendor verifiability (verbal promises do not count; only behavior you can reproduce does). Below is a ten-item checklist where every row states not just the pass bar but how to verify it yourself — create two keys and revoke one, force a failure and check the bill. Use it against any vendor, including us.
Layer 1: key governance
Nearly every incident starts with a leaked credential. The only sound principle: the blast radius of any single key must be minimal.
- One key per app, per team — a leak burns one key, and revoking it touches nothing else;
- Model allowlists — a key is bound to a group and can only call the models authorized for that group;
- Independent quotas — per key and per group, so a runaway integration cannot burn the global budget;
- Hash-only storage — HopBase stores API keys as one-way hashes; plaintext keys never touch the database, so even a stolen database cannot yield your key.
Layer 2: the data path
Put three questions to any vendor, in writing:
- Is request and response content ever persisted?
- Which fields do logs keep, and for how long?
- Can the data ever be used for training or any secondary purpose?
Our published position: zero content retention — prompts and outputs are never persisted; only billing metadata (model, token counts, latency, status) is kept for invoices and audits, and all traffic is TLS-encrypted in transit. Zero retention has a direct corollary: there is no content store on the gateway, so secondary use is physically impossible on our side. Upstream, each channel is governed by the official platform terms that apply to it — and our channel attributes are fully published, so you can assess them channel by channel.
Layer 3: audit and reconciliation
- Every request leaves a trace — model, usage, latency, status — so anomalies can be traced to a key, a time, a model, and a volume;
- usage detail is exportable, and billed amounts equal actual consumption;
- failures are never billed: any request with a non-empty error code costs nothing, verifiable line by line in the export.
Layer 4: vendor verifiability
Everyone claims no model swapping, no silent nerfs, no data retention. Claims are unverifiable; behavior is not. Require your vendor to:
- publish channel attributes — what each channel is and at what rate, in the open;
- pass errors through — upstream codes are returned as-is, never swallowed or rewritten;
- welcome testing — a vendor that objects to a reproducible fidelity test has already answered your question.
The one-page checklist
| Item | Pass bar | How to verify |
|---|---|---|
| Key granularity | One key per app, instant revocation | Create two keys, revoke one, confirm the other is unaffected |
| Model allowlist | Keys only reach authorized models | Call an unauthorized model; expect a clean rejection |
| Quota isolation | Independent per key/group | Exhaust a test group; others must be unaffected |
| Content retention | No prompt/output persistence | Demand the retention policy and field list in writing |
| Transport | TLS everywhere | Inspect the cert chain; plaintext HTTP is disqualifying |
| Key storage | Server keeps hashes only | Ask: can a database leak reveal plaintext keys? |
| Audit granularity | Per-request model/usage/latency/status | Export usage detail and spot-check it |
| Billing on failure | Failed requests cost nothing | Force failures and check the bill |
| Error passthrough | Upstream codes returned as-is | Trigger a rate limit; compare with official behavior |
| Fidelity | Vendor welcomes testing | Run the five fidelity checks and watch the reaction |
FAQ
Does HopBase store my data or use it for training?
No. Zero content retention is product design, not a verbal promise: prompts and outputs are never persisted, only billing metadata. With no content store on the gateway, training or secondary use is physically impossible on our side.
Is a gateway an extra hop and therefore extra risk?
That one hop buys centralized governance: uniform key tiers, quotas, allowlists, audit, and revocation. The alternative — N teams each holding raw provider keys — has a larger leak surface and higher governance cost. The path itself is TLS end to end.
Can we get a contract and corporate billing?
Yes. Contract terms and corporate procurement are handled by our consultants — get in touch.
How should I use this checklist?
Run several vendors through it in parallel, requiring a demo or written confirmation per item; verify the model side with the fidelity test. Only then talk price.
For enterprise onboarding and security review, contact us; integration details in the docs.