The question this post is answering
"Bring your own key" is marketed as the safe option. Pay the model provider directly, the platform is just a thin wrapper, your data goes "straight to Anthropic." That framing isn't wrong, but it papers over a real question: what does the platform actually do with the key between the moment you paste it and the moment a token comes back?
If you've ever pasted an sk-ant-api03-... key into a website and felt a tiny pause before hitting Save, that pause is the right instinct. This post is about what that instinct is detecting, and what to look for so you can paste with confidence.
I'm going to walk through three things:
- What an Anthropic API key is (mechanically) and what holding one lets a server do
- The four things every honest BYOK platform should do with your key, and the failure modes when they don't
- How to evaluate any BYOK platform in 5 minutes, with concrete questions to ask
I'll use VibeKit as a worked example at the end, partly because it's the product I built, and partly because writing this honestly requires me to publish what we actually do. If we're not the right fit for you after reading this, that's also a useful outcome.
What an Anthropic API key actually is
An Anthropic API key like sk-ant-api03-... is a bearer token. That means: whoever holds the bytes is allowed to make API calls billed to your account. There is no second factor. There is no per-request signature. The key is the entire authentication.
This is the same model as a credit card number: possession equals authorization. The reason people don't panic about this is that, like a credit card, you can rotate it and there's some level of fraud protection on the backend (Anthropic does have abuse detection). But for the moment a key is live, possession is total authorization.
Three different prefixes exist:
sk-ant-api03-...: standard API keys you create in console.anthropic.comsk-ant-oat01-...: OAuth tokens (issued when you connect Claude Pro / Claude Max to a third-party app)sk-ant-sid01-...: session tokens (short-lived, used internally by Claude apps; you generally won't paste these anywhere)
Most BYOK platforms accept only api03 keys (full API access, you pay per token), and a few also accept oat01 tokens (you connect your Claude Pro / Max subscription and Anthropic bills that third-party use to your plan's prepaid extra usage instead of per token). Both grant API call authority on your behalf. The OAuth path has the same "possession = authorization" property, just with a different billing relationship behind it.
For the rest of this post, when I say "your key," I mean either kind.
What a BYOK app can see (the honest list)
A platform that holds your key, by definition, can do the following things. None of these are bugs. They're inherent to how HTTP API authentication works:
1. Make any API call your key is authorized for. This includes calls you didn't initiate. A platform with your key could, in principle, fire 1,000 Claude requests at 3 AM and you wouldn't know until the next billing email. The main mitigation is a spend limit, which Anthropic sets per workspace: give keys you hand to platforms their own workspace with a low limit.
2. See every prompt your agent sends. The platform is the thing making the HTTP request to Anthropic, so it constructs and sees the full request body before sending it. That means your code, your design docs, your "fix this confidential issue" prompts: all of it is visible to the platform's servers in plaintext at the moment of the call.
3. See every response Anthropic returns. Same logic, opposite direction. Generated code, tool calls, planning text: all of it flows back through the platform on its way to your screen.
4. Call other endpoints on the same key. A standard key isn't limited to /v1/messages. It can also list models, count tokens, or run batch jobs on your account. Most platforms don't bother, but they technically can.
5. Use your key to call models you didn't choose. Cheaper models, more expensive models: the key doesn't differentiate. If a platform doesn't tell you which model it calls, ask, and watch the per-key usage in the Anthropic console.
That's the full list of what's technically possible. Now: which of these things SHOULD a well-behaved BYOK platform actually do, and which should they refuse to do?
The four things every BYOK platform should do
This is my checklist. If a platform you're evaluating fails any of these four, it's not a "BYOK platform" in the meaningful sense. It's a regular platform that happens to require you to provide the funding source. There's a difference.
1. Encrypt the key at rest, with the secret outside the database
The minimum bar is AES-256 with authenticated encryption (GCM or equivalent), with the encryption secret stored somewhere other than the database. That separation is what protects you in the most common breach: an attacker who dumps only the database gets ciphertext, whether the platform uses one shared key or derives one per user.
Per-user key derivation (typically HKDF from a master secret and the user ID) is a further step. A single leaked derived key opens one user's record rather than all of them, and the same API key stored by two users doesn't produce matching ciphertext. It does not shrink the blast radius of a stolen master secret: anyone holding the master and the user IDs can derive every per-user key.
Plaintext storage is disqualifying, and so is an encryption key kept in the same database as the ciphertext. Per-user derivation is good practice on top.
VibeKit's implementation for Anthropic credentials, for reference, is AES-256-GCM with HKDF-SHA256 derivation using each user's ID as the salt, so the database holds a unique ciphertext per user even when the underlying key is identical.
2. Send the key only to the model provider, not to an LLM proxy
A growing number of "BYOK" platforms accept your Anthropic key and then route the call through OpenRouter, LiteLLM, or another LLM aggregator. This means two third parties now see every prompt and response: the platform and the proxy. The proxy is also a single point of failure: if it logs your prompts (some do, for "analytics") or gets breached, your code goes with it.
A real BYOK call goes from your browser → platform server → directly to api.anthropic.com. One hop, one third party, one place to audit. Ask any platform you're evaluating: "When my BYOK key is used, does the request hit Anthropic directly or does it go through an intermediate LLM router first?" If the answer is anything other than "directly to the model provider," you're not getting BYOK in the sense the marketing implies.
(Worth noting: for users who don't provide a BYOK key, routing through OpenRouter is fine, since it's the platform's money at that point, not yours. The rule is "BYOK keys go direct; platform-funded calls can go wherever the platform wants.")
3. Log requests minimally, prompts never
Every platform needs some request logs, for debugging, abuse detection, billing reconciliation. The honest version of this logs metadata only: timestamp, user ID, model ID, token counts, latency, success/error. The prompt body and response body should never land in a log file you can grep next year.
The dishonest version logs the full prompt "for quality improvement" and never tells you. The trustworthy posture is: prompt and response bodies stay out of logs and telemetry. If the product keeps your conversation history, it says so, tells you who can read it, and tells you what deleting it actually does.
Ask: "If I had to GDPR-request all data your servers retain about my last week of agent activity, what would I get?" If the answer includes your prompts sitting in request logs or a third-party telemetry tool, walk away. The right answer is "request metadata and the encrypted key blob," plus a straight description of any chat history the product stores.
4. Make rotation and revocation trivial
Rotation is the only post-incident lever you have. If something seems off (a bill that's too high, a platform breach in the news, a key you used at an old job), you need to be able to:
- Generate a new key in Anthropic console
- Paste it into the platform (replacing the old)
- Confirm the old key has been deleted from the platform's database
- Revoke the old key in Anthropic console
A platform with a "Replace key" button that confirms deletion is doing this right. A platform where you have to email support to remove a key is dangerously slow on incident response. A platform that won't tell you whether the old ciphertext is actually deleted (vs. soft-deleted with a deleted_at flag) hasn't thought about this hard enough.
The attack scenarios that actually matter
I'll be specific about three threat models, because the term "secure BYOK" is meaningless without naming what you're securing against.
Threat 1: Platform database breach. Attacker dumps the keys table. Mitigated by encryption whose secret lives outside the database (see §1): they get ciphertext, not plaintext. Not mitigated if they also get the server's environment, where the master secret lives: then every stored key can be decrypted, per-user derivation or not. This is the most common breach pattern across SaaS.
Threat 2: Malicious or compromised platform code. Someone in the platform's CI pipeline (or a rogue employee) modifies the server code to siphon prompts or use keys for unauthorized calls. No encryption scheme defends against this. The platform's own code has to decrypt the key to make the API call; if the code is hostile, the key is exposed at use time. Mitigations: open-source platforms (audit the code), workspace spend limits on the Anthropic side (cap blast radius), and reputation. Small platforms with a few users are less attractive targets than large platforms with millions of keys, but small platforms also have less code review.
Threat 3: Log file leak. Server logs, error reports, third-party telemetry tools like Sentry, or backup tarballs accidentally exposed. Mitigated by §3 (never log prompts). Unmitigated by anything else: if your prompts are in a Sentry breadcrumb, encryption at rest doesn't help you.
The mitigations aren't the same. Encryption helps with database leaks. Code audits and Anthropic-side spend caps help with malicious platform code. Log hygiene helps with telemetry leaks. A platform that markets "bank-grade encryption" but logs every prompt has solved Threat 1 and ignored Threat 3.
What I'd ask any BYOK platform before pasting
A 5-minute evaluation. Email the support address, ask the founder on X, read the docs, whichever works. The answers matter more than the polish:
- "What encryption do you use for stored API keys?" Looking for: AES-256-GCM (or AES-256-CBC at minimum), with the encryption secret kept out of the database; per-user key derivation is a plus. "AES" alone isn't enough; ask which mode and where the secret lives.
- "When I make an inference call with my BYOK key, does the request hit Anthropic directly, or does it go through an intermediate LLM router?" Looking for: direct.
- "Do you log prompt or response bodies anywhere, including third-party telemetry like Sentry or Datadog?" Looking for: no, only request metadata.
- "How do I rotate or revoke my key, and how long until the old ciphertext is actually deleted from your database?" Looking for: a self-service "Replace key" button, with immediate hard delete (not soft delete).
If you get hand-wavy answers to any of these, that's a signal. A serious BYOK platform has thought about all four and can answer in two sentences each.
How VibeKit handles each of these
In the spirit of "show, don't tell," here's what we actually do: the specifics, not a marketing-page summary.
Encryption: Your Anthropic key or Claude sign-in is encrypted with AES-256-GCM under a key derived per user (HKDF-SHA256 from a master secret + your user ID). The master secret lives in our server env as a 64-character hex string; the database holds the ciphertext. OpenAI keys and Codex sign-ins are encrypted with the master key itself, not a per-user key. One exception to encryption at rest: so your agent can call Anthropic, the key is also written, decrypted, into the agent runtime's credential store on our servers, a file only the service that runs agents can read.
Direct routing for BYOK: If you've provided an Anthropic key, your agent's chat calls go through our gateway and directly to api.anthropic.com, not through OpenRouter. Users without a key (free tier or paid credits) route through OpenRouter, and a few platform-side tools run on our own key through OpenRouter even when you bring one: memory-search embeddings, web search, screenshot checks, music and video generation, and our automated session review. The routing rule is documented on our BYOK page and enforced at the gateway layer; the privacy policy lists every exception.
Logging: Our web server logs record IP, user agent, path, status and time, and are kept for 10 days. Credentials are never written to logs, and known key formats are redacted from anything that gets logged. We don't use third-party error or performance telemetry (Sentry, Datadog, etc.) that would create another copy of request data. The conversation itself is different: your agent's transcript is stored so you can scroll history, our staff may read it while debugging, and finished sessions go through an automated quality review. Deleting a workspace archives its chat rather than erasing it; the privacy policy has the details.
Rotation: The Profile tab in the iOS app and Settings on the web both expose key replace and delete actions, backed by PUT /api/v1/claude-key and DELETE /api/v1/claude-key respectively. Replace overwrites the encrypted blob and updates your agents' credential store, so new requests use the new key. Delete removes the database row entirely (not soft-deleted with a flag), but the copy in the agent runtime's store isn't removed yet, so after a delete, also revoke the key in the Anthropic console.
Verify what you can: The externally-checkable claims here are testable without taking our word for it: put the key in a dedicated Anthropic workspace with a low spend limit and you can watch exactly where your BYOK calls land; key replacement is immediate and self-service. For the parts you can't see from the outside, ask us a specific question and you'll get a specific answer. If something's wrong we'll fix it or explain the tradeoff we chose.
This is the bar I think every BYOK platform should meet. We're not all the way there: we'd like a formal third-party audit eventually, and a disconnected key should leave the runtime store the moment you remove it. But the floor is the floor: encryption, direct routing, log hygiene, and fast revocation. If your current BYOK platform doesn't clear all four, it's worth asking why.
Beyond the platform: what Anthropic offers
Two features in the Anthropic console that I think more people should use:
Workspace spend limits. You can cap how much a workspace can spend per month. Set this lower than your absolute risk tolerance. If you're testing a new BYOK platform, give its workspace a $10/mo limit until you trust it. If something goes wrong, the bleeding stops at $10 instead of $10,000.
Workspace separation. Anthropic Console supports multiple workspaces, each with its own keys, members, and limits. Use a dedicated workspace for "keys handed to third-party platforms" so you can audit and rotate without disturbing your personal/team work.
Both of these are free features. They take 60 seconds to set up. They are dramatically more effective at limiting downside than any platform-side promise.
The takeaway
The naive version of "is BYOK safe" is "yes, you control the key." The accurate version is "BYOK is a category of platform, and platforms within it vary by a lot." A well-built BYOK platform with properly separated encryption, direct routing, minimal logging, and self-service revocation is a substantially safer way to use AI than handing prompts to a vendor's hosted account. A poorly-built BYOK platform that proxies through three layers and logs every prompt is functionally worse than a transparent flat-rate vendor, because at least with the flat-rate vendor you knew you were trusting them.
Don't paste keys based on logos and vibes. Ask the four questions in §"What I'd ask any BYOK platform" before pasting. The platforms that can answer them well are the ones worth using; the rest will probably get there eventually, but you don't have to fund their learning curve with your sk-ant-api03-....
If you want to test this against a working implementation, try VibeKit for free (BYOK on the free tier, no credit card). Or read the related posts on BYOK vs platform-paid economics and the Anthropic API key format itself.
If you ship a BYOK platform and disagree with anything above, especially the parts about your platform specifically, I'd like to hear it. @609NFT on X.