BYOK security: what an app can actually see when you paste your Anthropic key

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:

1. What an Anthropic API key is (mechanically) and what holding one lets a server do
2. The four things every honest BYOK platform should do with your key — and the failure modes when they don't
3. 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. There is no IP allowlist (Anthropic doesn't offer one as of this writing). 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.com
• sk-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 api03 keys (full API access, you pay per token) and increasingly oat01 tokens (you connect your Claude Pro / Max subscription via OAuth and the platform uses your seat allocation instead of pay-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 only mitigation is per-key spend limits, which Anthropic does support — set them.

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. Read your Anthropic account metadata if they choose to. Your key authorizes calls to organization-info endpoints, not just /v1/messages. 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, image models — the key doesn't differentiate. Anthropic does let you scope keys to specific models in newer console UIs; if your platform doesn't ask which model to use, scope at the Anthropic side.

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 per-user keys

The minimum bar is AES-256 with authenticated encryption (GCM or equivalent) and a key derivation that produces a unique encryption key per user. The reason for "per user" is blast radius: if there's a database breach and every key is encrypted with the same master secret, one stolen master = every customer's key. If keys are derived per user (typically via HKDF or similar), a single user's compromised data doesn't open the rest of the vault.

Plaintext storage is disqualifying. "Encrypted with a shared key" is acceptable if the platform is small but is the next thing to fix. Per-user derived keys is what production-quality BYOK looks like.

VibeKit's implementation, 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. The code is open source; you can read it.

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 — 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." This is the same line OpenAI famously used in 2023, then later clarified that API traffic (unlike ChatGPT) isn't used for training. The trustworthy posture is: prompts and responses are transient. They exist in RAM during the call, then they're gone.

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," walk away. The right answer is "timestamps, token counts, model names, and the encrypted key blob."

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 per-user encryption (see §1) — they get ciphertext, not plaintext. Unmitigated by single-key encryption — they get plaintext after one key crack. 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), per-key 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 Twitter, read the docs — whichever works. The answers matter more than the polish:

1. "What encryption do you use for stored API keys?" Looking for: AES-256-GCM (or AES-256-CBC at minimum) plus per-user key derivation. "AES" alone isn't enough; ask which mode.
2. "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.
3. "Do you log prompt or response bodies anywhere — including third-party telemetry like Sentry or Datadog?" Looking for: no, only request metadata.
4. "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).
5. "Is your platform code open source or audited?" Looking for: yes to either. Bonus points for a public bug bounty.

If you get hand-wavy answers to any of these, that's a signal. A serious BYOK platform has thought about all five 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 — verified by reading the code I just linked, not by reading the marketing page.

Encryption: AES-256-GCM with per-user HKDF-SHA256 derivation. Each user's keys are encrypted with a unique key derived from a master secret + their user ID. The master secret lives in our server env as a 64-character hex string; the database holds the ciphertext.

Direct routing for BYOK: If you've provided an Anthropic key, calls go through our gateway and directly to api.anthropic.com — not through OpenRouter. We use OpenRouter only for users on our free tier who don't bring a key (in which case it's our money, our routing decision). The routing rule is documented in our agent config and enforced at the gateway layer.

Logging: We log request metadata for billing and abuse detection — user ID, timestamp, model ID, input/output token counts, latency, success/error. We do not log prompt or response bodies, and we don't use third-party telemetry services (Sentry, Datadog, etc.) that would create another copy of request data outside our infrastructure. Server logs live on the application VM and rotate on the standard PM2 schedule.

Rotation: The profile page in the iOS app and Telegram bot 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 in place; delete removes the row entirely (not soft-deleted with a flag). New requests use the new key starting immediately.

Audit: The whole codebase is on GitHub. The encryption module, the BYOK routing logic, the request logging — all readable. Issues and PRs are public. If you find something concerning, file an issue — we'll either fix it or explain why we chose what we chose.

This is the bar I think every BYOK platform should meet. We're not perfect — we'd like a formal third-party audit eventually, and our Anthropic-side spend cap UX could be smoother. But the floor is the floor: encryption, direct routing, log hygiene, fast revocation, open code. If your current BYOK platform doesn't clear all five, it's worth asking why.

Beyond the platform: what Anthropic offers

Two features in the Anthropic console that I think more people should use:

Per-key spend limits. You can cap how much a specific API key can spend per month. Set this lower than your absolute risk tolerance — if you're testing a new BYOK platform, give it 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 per-user 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 five 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 genuinely like to hear it. @609NFT on X.