DEV Community: kh.vibecoding

Five Layers of Protection for Payments and AI Requests

kh.vibecoding — Fri, 11 Sep 2026 07:06:05 +0000

Ask an assistant to "build payment processing" and you get code that works. Click the button, pay, get access. Tests pass, the demo looks convincing to the client. Then someone opens devtools and pays a dollar instead of a hundred. Here is what an AI assistant leaves broken in payment handling by default, on a real client project, and what we build around payments and AI requests so it does not happen.

Hole one: the price comes from the client

Here is what gets generated by default if you simply ask for "payment processing":

// do not do this
app.post('/checkout', async (req, res) => {
  const { productId, amount } = req.body;        // amount came from the browser
  const session = await psp.createSession({ amount, currency: 'usd' });
  res.json({ url: session.url });
});

It looks logical enough: the frontend knows the price, so it sends it. But the frontend runs on the buyer's machine, and it takes one line in the browser console to edit. amount: 10000 becomes amount: 100, the payment provider happily charges a dollar, and the product ships.

The fix: the client sends only the id of what it is buying, and the server looks up the price itself.

app.post('/checkout', requireAuth, async (req, res) => {
  const product = await products.get(req.body.product_id);
  if (!product) return res.sendStatus(404);
  // record the order before calling the PSP: we reconcile the webhook against it later
  const order = await orders.create({
    user_id:      req.user.id,
    product_id:   product.id,
    amount_cents: product.price_cents,   // price comes from the database only
    currency:     product.currency,
    status:       'pending',
  });
  const session = await psp.createSession({
    amount:   order.amount_cents,
    currency: order.currency,
    metadata: { order_id: order.id },
  });
  res.json({ url: session.url });
});

Three lines of difference. But as long as the amount comes from req.body, any checks further down the code are pointless.

Hole two: the "thank you" page confirms the payment

The second common pattern: the user returns from the payment provider to /success, and access is granted right there. This breaks both ways. Close the tab right after the charge and the money is gone but access never gets granted, and you never find out. Or open /success directly, skip the payment entirely, and get access for free.

The only source of truth for a payment is the provider's webhook. And receiving it is not enough — you have to verify it: signature, timestamp, idempotency, and the order amount.

const crypto = require('crypto');
// express.raw is essential here: the signature is computed over the raw body.
// After JSON.parse and re-serialization the bytes are already different.
app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  const sig = req.get('X-Signature');
  const ts  = req.get('X-Timestamp');
  if (!sig || !ts) return res.sendStatus(400);
  // 1. Replay: a valid webhook intercepted once should not be replayable tomorrow
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return res.sendStatus(400);
  const expected = crypto
    .createHmac('sha256', process.env.WEBHOOK_SECRET)
    .update(`${ts}.${req.body}`)
    .digest('hex');
  // 2. Constant-time comparison. Plain === leaks timing information:
  //    the signature can be brute-forced byte by byte from the rejection speed.
  const ok = sig.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
  if (!ok) return res.sendStatus(403);
  const event = JSON.parse(req.body);
  // 3. Idempotency: the provider retries until it gets a 200.
  //    Without this check, one payment extends a subscription three times over.
  if (await events.exists(event.id)) return res.sendStatus(200);
  // 4. Reconcile the amount against our own order, never trust the event alone
  const order = await orders.get(event.metadata.order_id);
  if (!order ||
      order.amount_cents !== event.amount_cents ||
      order.currency     !== event.currency) {
    await alerts.send('payment_mismatch', { event });
    return res.sendStatus(409);
  }
  await events.save(event.id);
  await orders.markPaid(order.id);
  res.sendStatus(200);
});

By default, an assistant does, at best, the first of these five checks — signature verification. Idempotency, constant-time comparison, and amount reconciliation have to be asked for explicitly, one by one. Neither hole gets caught by ordinary testing: tests check "paid → got access" and "did not pay → no access", and an attacker is interested in the third path nobody on the review side thought to check.

Why the model defaults to this

I am not a senior engineer — I build products with AI, and the first thing that taught me is that the most dangerous thing is not bad code, it is code that looks like it works.

A model reproduces the most common pattern from what it was trained on, and in tutorials and examples the check is almost always on the client — it is shorter and easier to demonstrate. It implements what is visible in the interface, because the interface is what you described to it.

So for critical features — payments, access, other people's data — my first request is never about code:

"Don't write code yet. Look at the integration docs, the security standards, and the common vulnerabilities (especially price tampering and payment validation). Give me 2–3 ways to do this safely, list the trade-offs of each, and tell me which you recommend and why."

The holes get closed before any code exists — reworking the architecture afterward costs ten times as much. And the side effect turned out to matter more than the main one: you start actually understanding how your own product works under the hood, and you choose the approach deliberately. You do not need this for every button. For payments, it is not optional.

Attacking your own product before handover

Before handing off a project with payments, I open a clean session — not the context the code was written in — give the agents access to the result, and one task: bypass the payment.

The clean session is essential. An agent that knows "how it was meant to work" defends the design and explains why it is correct. An agent that only sees the code looks for a way to fool it.

That time, they found a bypass the first audit had missed.

On backups, separately: the habit started after a day an AI agent, tweaking something minor on a server, took down a client's live site. A snapshot taken before the work started saved it — three minutes, and the site was back. Since then, a backup is the first step of any task, no exceptions.

What we run around payments

Full protection does not exist. The goal is different: make an attack cost more than whatever it could gain.

Log everything. Every request, every operation. Looks paranoid right up until the first incident review.

Automatically block suspicious IPs — bots, spammers, odd request patterns.

Rate-limit spend per account — a sliding window on request count and on money spent:

// Count money as well as requests: 10 expensive calls
// hit the wallet harder than 1,000 cheap ones.
async function guard(accountId, costCents) {
  const WINDOW = 3600;
  const now = Math.floor(Date.now() / 1000);
  const key = `spend:${accountId}`;
  await redis.zremrangebyscore(key, 0, now - WINDOW);
  await redis.zadd(key, now, `${now}:${crypto.randomUUID()}:${costCents}`);
  await redis.expire(key, WINDOW);
  const entries  = await redis.zrange(key, 0, -1);
  const requests = entries.length;
  const spent    = entries.reduce((s, e) => s + Number(e.split(':')[2]), 0);
  const limit = await limits.get(accountId);
  if (requests > limit.requests_per_hour || spent > limit.cents_per_hour) {
    await accounts.block(accountId, 'anomaly');
    await alerts.send('account_blocked', { accountId, requests, spent });
    return false;
  }
  return true;
}

This fires in two cases: either someone found a genuine vulnerability, or a stranger is running requests against a paid AI API on someone else's account — they found an endpoint that proxies calls to the model past the interface and its limits, and is using it as a free ChatGPT. Either way, the response is the same: stop first, investigate after.

Real-time alerts. Not "find out from the logs a week later" — see it now.

A kill switch. A script that cuts every external connection: no data, no API, and a notification to me.

It sounds dramatic for a product built by one person. But over-engineering this ten times over is still cheaper than getting it wrong once with a client's money.

The honest part

AI agents do not replace a pentest. They do not see the full infrastructure, do not know the business context, and confidently claim there is nothing wrong when they simply found nothing — every finding still needs a human check. It is a cheap first filter, not a security audit.

And the code above does not make a product unbreakable. It closes two specific places where mistakes happen most often.

More on how we build this at hikmah-labs.dev/en/ — a studio that builds web apps, bots, and AI agents, with payment and access security handled as a first-class part of the build, not an afterthought.

AI Cross-Posting: Why One Post Does Not Fit Every Platform

kh.vibecoding — Fri, 11 Sep 2026 07:03:38 +0000

We are building PostPilot, a B2B cross-posting platform: a post is written once and goes out on every connected platform, with AI adapting the text to each platform's format. The product is live, currently in stage three of three, with several platforms already connected. Here is what "adapting to a platform" actually means, and why simply duplicating a post does not solve the problem.

Why "one post everywhere" does not work

The first idea anyone has about cross-posting is to copy a post and push it to every channel with one button. It is the simplest technical solution, which is exactly why it delivers so little. Every platform reads differently: some show the whole text at once, some show only the first lines before the reader decides whether to keep going, some treat the headline as a separate interface element rather than the first line of the body. The same post, dropped unchanged into every format, either gets cut in the wrong place or reads as foreign on a platform it was never written for.

Duplication solves "the text physically exists on every platform." It does not solve "the text gets read." Those are different problems, and a business paying to maintain a presence across several channels needs the second one solved.

What actually changes during adaptation

In PostPilot, the same source post does not go out unchanged — AI reworks it for the format of each specific channel. Our project card states this directly: headlines and framing change per platform. That means the headline for a platform where it exists as a separate element does not match the first line of the text a reader sees on a platform with no headlines at all. Framing is how the text is built — what comes first, what gets pulled forward, and what can be cut when a platform's format is not built for long text.

We want to be precise about what we are claiming here and what we are not. We will not list a specific set of technical adaptation parameters — character length, tone, markup — beyond what the project card states: the headline and the framing change for each platform. That alone is a non-trivial problem: the system has to understand the format of every connected platform and rewrite the text for it while keeping the author's point intact, rather than turning the adaptation into a different text with a different meaning.

Why a publishing queue, not just a broadcast

Cross-posting to one channel is a "publish" function. Cross-posting to several platforms is a process: a post has to go through adaptation for each platform, join a publishing queue, and go out at the right time on each of them, without losing a copy or duplicating one. If any one of those steps is built carelessly, the outcome is predictable — a post goes out late on one platform, never goes out on another, and goes out twice on a third. For a B2B client paying specifically to avoid manual publishing, any of those failures undermines the whole product, regardless of how good the text adaptation itself is, if the post never actually reached the platform.

Architecture built for growth

The project card states separately that the architecture is built to scale with volume. For a B2B cross-posting platform that is a real requirement, not a throwaway line. A client connects platforms gradually rather than all at once — starting with one or two, confirming the text comes out the way it should, and only then adding the next ones. If the architecture is tightly bound to a fixed set of platforms or to current publishing volume, every expansion becomes a rebuild instead of a configuration change. We built the architecture so that connecting a new platform and growing the number of posts do not require rebuilding the system from scratch — that is what we can confirm on our side, without disclosing the client's specific technical implementation.

What a B2B client actually gets

The practical result for a business maintaining a presence across several platforms: a post is written once instead of being rewritten by hand for each platform separately. That saves the editor's or marketer's time otherwise spent fitting the same message into different formats. Several platforms are already connected and working — this is not a single-platform prototype but a system built for a company's real workflow, where a multi-channel presence is not a one-off campaign but a permanent part of talking to an audience.

When you do not need this

A product like PostPilot solves a specific problem, and it has boundaries:

A single platform. If a company maintains a presence on only one channel, the task of "adapt to several formats" simply does not exist. Cross-posting with adaptation solves the problem of multiple platforms — where there is only one, there is nothing here worth paying for.
Infrequent posts. If posts go out once every week or two, manually adapting a post per platform takes 15–20 minutes — not enough time to justify paying for automation and maintaining platform integrations for that volume.
Content that needs a hand-crafted presentation. Some formats are not primarily about text: posts with complex layout, an authorial voice that needs line-by-line control, material where any automatic change to framing reads to the audience as a loss of authorship. For content like that, an adaptation system gets in the way rather than helping — manual publishing or an editor who adjusts the text per platform themselves works better.

If you fall into one of these three cases, the honest advice is not to build a cross-posting platform — solve it more simply, with a single channel, occasional manual posting, or a human editor with full control.

How we work on projects like this

AI agents and integrations at this level start from $1,400, usually 3–5 weeks, with the price fixed in the technical spec before the start and no increases along the way. If the scope and architecture are not obvious upfront, there is a discovery phase: $170, 3–5 days, a written report with risks and an exact price — the amount counts toward the project. We work in stages, each ending with a demo of a working part of the system, 50% upfront, and 90 days of free fixes after handover. Project data is under NDA by default.

We are Hikmah Labs, a small studio building AI agents, automation and web products for businesses. More about us at https://hikmah-labs.dev/en/.

ProxyKey MCP: Giving an AI Agent API Access Without Handing Over a Key

kh.vibecoding — Fri, 11 Sep 2026 07:00:45 +0000

We already wrote about why a credential proxy exists and why "zero-knowledge" is impossible for one by design — that proxy is ProxyKey, our own project. This post is the practical follow-up: how to connect Claude Code or Cursor to ProxyKey over MCP, what the 13 available tools are, why "read the key" is deliberately not one of them, and how the scenario we built all of this for actually plays out — an agent deploying a bot that doesn't have a token yet.

Why an agent needs MCP to a vault, not just a key in .env

An agent like Claude Code or Cursor lays out environment variables, writes configs, and sometimes logs what it's doing. Anything that enters a model's context has to be treated as published: context gets logged, traced, and can be pulled out through prompt injection. Handing that agent a live OpenAI key or a Telegram bot token is functionally the same as handing it to a random script on the internet.

The ProxyKey MCP server solves this at the protocol level, not with a policy the agent is trusted to follow. The agent gets a tool, not a secret. None of the 13 methods has an operation that returns a key's value. The agent can create, revoke, and rotate passes, and inspect limits and request logs — but it cannot read the original, because that endpoint simply doesn't exist in the API.

Connecting: Claude Code and Cursor

The first step is a human one: sign in at app.proxykey.org (GitHub OAuth or a magic link, free), open the MCP section, and create a token in the form mcp_…. Only that token goes to the agent — never the real provider keys.

For Claude Code, one command:

claude mcp add --transport http proxykey https://mcp.proxykey.org/mcp \
  --header "Authorization: Bearer mcp_YOUR_TOKEN"

For Cursor and Claude Desktop, an entry in mcp.json:

{
  "mcpServers": {
    "proxykey": {
      "url": "https://mcp.proxykey.org/mcp",
      "headers": { "Authorization": "Bearer mcp_YOUR_TOKEN" }
    }
  }
}

From there the agent sees ProxyKey's tools like any other MCP tools and can call them on its own, without a human in the loop on every step.

13 tools — and why "read the key" is not one of them

Catalogue and metadata: list_providers lists providers and their auth model. list_secrets shows stored keys, metadata only, never values. get_manual_secret_setup returns a link for a human to enter the real key.
Pass management: create_pass, create_pending_pass, update_pass, rotate_pass, revoke_pass, delete_pass, rebind_pass_ip — the full lifecycle of a virtual token.
Observability: list_passes, get_pass_logs, get_pass_stats — the agent sees each pass's status, limits, IP binding, and request history.

None of the 13 operations has a parameter that returns a secret's value. This isn't "the agent has agreed not to look" — that capability simply isn't in the API contract. For the same reason, the MCP surface can't turn on request-body logging either — that stays human-only in the panel, because otherwise a key could be reconstructed indirectly through the logs.

The pending-secret scenario: an agent deploys a bot without a token

This is the exact reason we built all of this. A common situation: an agent is deploying a Telegram bot, writing the code, wiring up the webhook — but there's no BotFather token yet, because the bot hasn't been created.

Instead of stalling and waiting on a human, the agent calls create_pending_pass. The pass (vlt_…) is issued immediately and can go straight into the bot's config — but proxying real traffic is blocked with the status original_key_required until the secret is filled in. The agent then calls get_manual_secret_setup and hands the resulting link to a human.

The human opens the panel, pastes in the real token once, and the pass activates automatically — no second call from the agent required. The bot comes alive. At no point did the agent see the secret's value; it went through the panel, not through the model's context.

What a human sees in the panel

The panel is the only place a real key's value ever lands — the form used for initial setup or for filling in a pending secret. From there the interface shows the list of stored secrets (metadata only, no values), the list of passes with their status, IP binding and limits, and a per-pass request log — metadata, with no authorization headers and no key material.

The split is simple: anything that could expose a secret's value is human-only, through the panel. Anything the agent needs for day-to-day work — issuing, revoking, rotating, monitoring — is available over MCP.

The proxy call itself

Once a pass is issued, the application or agent points at the proxy instead of the provider — only the host and the key change; the path and body stay the same:

# before
curl https://api.openai.com/v1/chat/completions -H "Authorization: Bearer sk-..."
# after
curl https://api.proxykey.org/p/openai/v1/chat/completions -H "Authorization: Bearer vlt_openai_..."

Streaming (SSE), request bodies, and headers pass through unchanged. Telegram bots keep their usual URL shape: /p/telegram-bot/<pass>/getMe.

A limitation worth stating plainly

A hosted proxy cannot be zero-knowledge by design: to put a key into a request to the provider, the proxy has to decrypt it in memory at the moment it handles that request. Which means a process with full access — and, by extension, the service operator — can in principle obtain the plaintext. That isn't a bug specific to ProxyKey; it's a property of every hosted solution in this category. We covered this in detail on the security page: what the encryption actually protects against (a database leak, a stolen backup, a log leak) and what it doesn't (a fully compromised server). The agent's MCP access doesn't add new risk on top of that — if anything it's more restricted than a human's access through the panel.

When you don't need this

You have one key and one consumer. If a key is used in a single place you fully control and no agent ever touches it, a proxy just adds a point of failure with no real upside.
Your threat model won't tolerate a third party in the request chain. The proxy sees the traffic, even if it only logs metadata. If that's unacceptable, run your own instance of the pattern, or skip it entirely.
Latency in the single-digit milliseconds actually matters. The extra hop plus a validation-cache lookup adds overhead. For LLM calls it's invisible against the generation time; for some low-latency, non-LLM APIs it can matter — worth running the numbers yourself.

The takeaway

The model is simple: a secret enters the system exactly once, through the panel, and never leaves the server in plaintext again. The agent gets a tool with a deliberately narrow contract — everything it needs to automate issuing and managing access, and nothing that could leak through the model's context. For agents that deploy their own services and bots, that removes the usual blocker — what to do about a key the agent doesn't have yet — without a human on every step.

We build ProxyKey at Hikmah Labs, a small studio. You can read more about our work there.

Building Voice AI Agents for a Call Centre: Two Case Studies

kh.vibecoding — Fri, 11 Sep 2026 06:58:20 +0000

We have two voice agents in our portfolio built for different jobs: one answers inbound calls for a financial services firm, the other calls customers for a logistics company and collects requests. We already wrote about the economics of voice agents elsewhere. This one is about the process itself — how we scoped the task, what decisions we made along the way, what turned out harder than it looked at the start, and what the client ended up seeing on the dashboard.

Two different jobs under one label

"Voice agent" is a broad label for things that work quite differently under the hood. The financial firm's task was inbound: the customer calls in, the agent answers routine questions, and hands the complex ones to an operator. The logistics company's task was outbound as much as inbound: the agent both answers calls and calls people from a list to clarify details or collect a request. Both talk in a natural voice and understand ordinary speech, but the scenarios built into them and the data they work with are different. So even though the projects sit under the same theme, they were put together differently from day one.

Where we started: mapping scenarios and policies

The first step on both projects was not about technology — it was about what actually happens on a call. We work through the call scenarios and the company's policies: what customers ask, what rules operators follow when they answer, where a routine answer ends and an individual case begins. For the support agent, that meant turning the company's policies into a form the agent could actually answer from, without inventing wording of its own. For the calling agent, it meant deciding which fields a conversation absolutely has to fill in for the resulting request to be usable, rather than a string of disconnected phrases.

What comes out of this step is a line: what the agent takes on, and what stays with people. That line gets fixed in the technical spec along with price and timeline before any work starts, with an NDA where needed.

What turned out to be hard in practice

The hard part of either project was never getting the agent to talk — that part is solvable. The hard part is the boundary and the handoff.

For the support agent, it was teaching it to honestly recognise the moment a question falls outside its policies, rather than guessing. An agent that confidently gives a wrong answer to a financial firm's customer is worse than one that admits, in time, that the question is not its to answer and calls in an operator.

For the calling agent, it was keeping one underlying logic for both inbound and outbound calls, with different scenarios inside each, while still producing data in the same structured shape regardless of who started the conversation. A call the customer starts and a call the agent starts read very differently — the record that comes out of either has to be equally usable.

And one principle applied to both: the agent does not pass itself off as a human. It introduces itself as an automated assistant. We treated that as a matter of trust in the client's brand rather than a technical constraint — the pretence gets uncovered quickly and damages the impression more than talking to a machine ever would.

How context reaches the operator

When the support agent hands a call to a person, the conversation history goes with it — what the customer has already said and what the agent already clarified. The customer does not have to repeat everything to an operator who just picked up. For a call centre where patience runs out faster on the second explanation than on the first, this was a requirement from the start of the build, not an option added later.

What went into the dashboard

The two dashboards were built around different questions a manager actually asks. The support agent's dashboard shows calls, topics and load: how many calls came in, what people ask about most, how load is distributed over time. The calling agent's dashboard shows calls, requests and outcomes: how many conversations happened, how many turned into a request, and how each call ended. In both cases the goal is the same — the manager sees the raw picture of what is happening on the line for the first time, rather than an operator's summary of it.

What handover looked like

Both projects ran in stages, each ending with a demo of the live agent — something you can actually call and talk to, not a slide deck. Price was fixed in the technical spec before the start and did not change along the way. After handover, we fix issues free for 90 days, then move to retainer support if the client wants it.

Where this approach does not fit

The company has no written policies yet. If operators' answers live in their heads rather than in a documented set of rules, the agent has nothing to work from. Turning that knowledge into a form the agent can answer from is a separate task that has to happen before the agent itself gets built.
Every call needs legal or medical judgement. Where the cost of a wrong answer is high, the agent should honestly flag that risk during discovery, and the project should at most capture a contact for a specialist rather than try to replace the consultation.
There is no one to pick up escalations quickly. A dashboard full of topics and load is useless if transferred calls have no one to answer them — the agent removes load from the phone line, but the bottleneck just moves to an already overloaded operator.

We build voice AI agents and other AI-driven automation at Hikmah Labs. More about the studio at https://hikmah-labs.dev/en/.

We open-sourced our vault's encryption code — and wrote honestly about what it doesn't guarantee

kh.vibecoding — Thu, 10 Sep 2026 19:28:32 +0000

We build proxykey, a credential proxy: real API keys sit encrypted on our side, and apps and AI agents talk to us using revocable virtual tokens instead. We recently wrote about the scheme itself. Underneath that post and in DMs, one question kept coming up — the right question to ask any service like this:

"Can you read my keys yourselves?"

Short honest answer: technically, yes. Instead of hiding that behind marketing fog, we did two things: published the crypto module in full, and wrote a threat-model page where this point is first and in bold. This post is about why, and exactly what we opened up.

Why "zero-knowledge" is impossible here by design

A proxy has to decrypt the key to put it into the request to the provider — that's the entire job. A password manager can be zero-knowledge: the server never needs your password. A credential proxy can't be: at the moment of the request, the plaintext key exists in the process's memory.

That leads to an uncomfortable but unavoidable conclusion: a process with full access — and therefore the server operator — can in principle obtain the plaintext. This is a property of the architecture, not a bug. It's the same for every hosted solution in this category — secret managers, proxies, cloud vaults. The only difference is who says so out loud.

What the encryption actually protects against

Against a set of concrete, and much more likely, scenarios:

Scenario	Protected?
Database dump leak	Yes — secrets are encrypted, the master key isn't in the database
Backup theft	Yes — same ciphertexts, no key
Log leak	Yes — no keys or auth headers in logs
Database-only compromise	Yes — without the KEK from the process environment, ciphertexts are useless
Virtual token leak	Yes — IP binding, rate limits, one-click revocation
Full server compromise / malicious operator	No — honestly, no

The full version of this table is on the security page.

What we open-sourced

The proxykey-crypto repo is exactly the envelope-encryption module that encrypts secrets in our production system. 450 lines of TypeScript with tests, no dependencies besides node:crypto:

every secret gets its own DEK; the plaintext is encrypted with AES-256-GCM using AAD = the secret's id (a ciphertext can't be silently swapped into another record);
the DEK is wrapped with a master key (KEK) that lives only in the process environment — it's never in the database;
decryption happens in memory for the duration of a single request; the DEK and the plaintext copy are zeroed in finally on every code path, including exceptions;
virtual tokens in the database are stored only as SHA-256 hashes;
18 tests: roundtrip, ciphertext/tag/wrapper tampering, wrong AAD, wrong key version.

What the open code does NOT guarantee

Also stated plainly, because this is the other half of being honest:

Open code is not proof. You can review the design, but a repository can't cryptographically prove that this exact code is what runs on the server. It's a transparency gesture, not an attestation.
fill(0) is best-effort. V8 may have already copied buffers internally as part of its own operations, and a decrypted key stored in a JS string is immutable — you can't overwrite it, it lives until garbage collection. We narrowed the window; we didn't close it — and we're saying so.
We validate the KEK's length, not its entropy. There's no KDF, on purpose: the master key is required to be a random key (openssl rand -base64 32), not a password.

The repo's README has a "Design notes" section answering the standard reviewer questions — the bounds on the random nonce for GCM, why the DEK wrapper isn't bound to the AAD (to allow future KEK rotation), and so on. If you find something to pick apart beyond that, file an issue — that's the best possible contribution to everyone's security.

How to reduce risk even against "the operator"

A practical takeaway for anyone using any hosted key vault, not just ours:

create scoped keys, not master keys: an OpenAI project key with a $20 budget instead of a key for the whole account — then even a full vault compromise costs you $20, not everything;
set limits on the provider's side — a second line of defense after the vault's own limits;
rotate the originals — reissuing at the provider zeroes out the value of anything that may have leaked earlier;
if you don't trust any of this — that's a rational position: the design is reproducible, the crypto module is open, go build your own instance.

Disclaimer

We're the people behind proxykey (proxykey.org). The service is free. This post isn't "trust us, we're secure" — it's the opposite: here's the boundary up to which it's secure, here's the code, and here's what's left resting on trust. We think that's more honest, and more useful for anyone deciding where to keep their keys.

I build ProxyKey at Hikmah Labs. You can try the vault at proxykey.org.

Your API Key Will Leak. Make That Not Matter

kh.vibecoding — Thu, 10 Sep 2026 19:15:38 +0000

According to GitGuardian's State of Secrets Sprawl report, about 23.7 million secrets — API keys, tokens, passwords — leaked into public GitHub in 2024 alone. The overwhelming majority aren't the result of a hack; they're ordinary commits, logs, and client-side bundles. A fresh key that lands in a public repo gets tried by bots in under a minute.

The conclusion we reached after the Nth incident: fighting to keep a key from leaking is a war you lose. The winning move is to make the leak useless.

Why keys always leak

A single OpenAI key in an average project lives in five places at once:

in .env on developers' laptops;
in CI secrets (and sometimes in CI logs — a printenv in a debug step);
in the production config;
in "just for a minute" scripts (test_gpt.py with the key hardcoded as a string);
and, more recently, in the context of an AI agent that "writes the code itself."

Every copy is an independent point of failure. The classic countermeasures all work, but each one has a ceiling:

Measure	What it covers	What it doesn't cover
`.env` + `.gitignore`	an accidental commit	logs, CI, agents, "just a quick script"
Scanners (gitleaks, trufflehog)	a leak into git before push	every other channel
Secret managers (Vault, AWS Secrets Manager)	storage and delivery	the key still ends up in the app's runtime environment
Provider-scoped keys	blast radius	not every provider supports them; revoking one still breaks every consumer of that key

The common thread: in every scheme, the real key ends up in the consumer's hands at some point.

Which means it leaks along with it.

The scheme: credential proxy

The idea isn't new (it's how, say, payment tokenizers work), but for API keys it's barely used. Break the link between the app and the key:

app ──(vlt_pass)──▶ proxy ──(real key)──▶ provider
                       │
              status / IP / limits → log

Secret — the real key. Entered once, encrypted, and never returned by any API, ever.

Pass — a virtual token bound to a secret. Its own IP binding, its own rpm/rpd limits, its own lifetime, its own log. This is what applications, scripts, and agents actually get.

Proxy — validates the pass, decrypts the secret in memory for the duration of a single request, substitutes it, and streams the response back.

Consequences:

The zone where the original key can leak shrinks down to a single server.
A leaked pass isn't an incident: wrong IP → 403, over the limit → 429, revocation is one click, the original is never touched.
Side bonus: you can see who is calling each downstream service and how much, because every consumer has its own pass.

For your code, the switch is two lines: api.openai.com → <proxy>/p/openai, sk-… → vlt_…. The path, body, headers, and SSE streaming all pass through unchanged.

How it works under the hood (our implementation)

We built this scheme as a service — ProxyKey (Node 22 + Fastify 5 + PostgreSQL + Redis). A few technical decisions that might be interesting independent of the product:

Envelope encryption: every secret gets its own DEK (AES-256-GCM, AAD = secret id), and the DEK is wrapped by a KEK from the environment. Decryption happens in memory for the duration of a single request; the plaintext is never cached or logged anywhere, and the DEK is zeroed out after use.
Tokens aren't stored: the database only holds SHA-256 hashes of passes; the hot path validates against a Redis cache (TTL 300s) with a fallback to Postgres.
Degradation is asymmetric: if Postgres goes down, we serve from cache (fail-closed for anything not cached); if Redis goes down, we validate against Postgres, but rate limits fail open — validation does not.
SSRF guard: custom base URLs are resolved and checked against private/metadata IP ranges — otherwise a proxy that accepts user-supplied upstreams is a ready-made SSRF vector.
Request logs: Postgres partitioned by month, metadata only, no authorization headers or key values.
Telegram bots are a special pain: the bot token lives in the URL path, and aiogram/grammY (popular Telegram bot libraries) validate its format before the first request. The proxy accepts bot<digits>:vlt_… and ignores the digits — the format passes client-library validation, and the real token gets substituted server-side.

AI agents: the main new consumer of keys

This is the actual reason we got into this in the first place. Agents (Claude Code, Cursor, and the like) spin up services and configure bots — they constantly need keys. But anything that ends up in a model's context has to be treated as published: context gets logged, traced, and can be extracted via prompt injection.

The fix is to give the agent a tool, not a secret: an MCP server for the vault. The agent connects via a URL with an mcp_… token and can issue, rotate, revoke passes, and read logs. "Read the real key" is simply not in the tool set — that's a property of the access protocol, not a promise we're trusting the agent to keep.

Our favorite scenario is the "pending secret": an agent deploys a Telegram bot whose token doesn't exist yet. The agent creates a pending pass, wires it into the config, and hands a human a link; the human enters the real token in the panel, the pass activates, and the bot comes alive. The agent finished the job without ever seeing the secret.

Honest trade-offs

The proxy is a critical dependency. If it's down, all your calls are down. Replicas and validation caching help, but you need to understand this going in.
The proxy sees the traffic. The question isn't whether it sees it, it's what it logs. In our implementation, only metadata; body previews are optional and opt-in per pass. If your threat model doesn't allow a third party in the loop, run this pattern yourself — it's reproducible.
Latency. One extra hop plus a cache lookup adds single-digit milliseconds against hundreds of milliseconds of LLM generation. For low-latency, non-LLM APIs, do your own math.

Disclaimer

We're the people behind ProxyKey (proxykey.org). The service is free, no card required; the panel, the proxy, and the MCP server are described here honestly, limitations included. The credential-proxy pattern is reproducible without us — if you build your own, just don't skip the SSRF guard and the fail-closed validation path.

Built at Hikmah Labs, a small studio I run. ProxyKey itself lives at proxykey.org.