Ask an AI agent to "wire up the Stripe API" and watch what happens. More often than you would like, it reaches for the fastest path: it pastes the secret key straight into the source file. The integration works immediately. It also just put a live credential one git push away from the public internet.
This is one of the most common — and most expensive — failure modes in vibe coding. It has already bitten real products. On platforms where users built apps with AI, secret API keys were leaked publicly, letting attackers pick them up and run up charges on someone else's account. The owner finds out from a bill, not a breach alert.
Why AI keeps hardcoding secrets
The model is not careless on purpose. It is taking the most direct route from your prompt to working code. Inline is the shortest path — reading from a config file or a secrets manager is more setup, while pasting the literal key is one line that runs on the first try. The agent has no concept of "later": it is thinking about this function compiling now, not the commit, the push, or the public repo six steps downstream. Its training data is full of the pattern — countless tutorials show keys inlined "for simplicity," and the model learned it faithfully. And it cannot see the blast radius: it does not know this repo is public, that the key is production, or that git history keeps the secret even after you delete the line.
That last point is the killer. Once a credential lands in a commit, it lives in history forever. Deleting the line in a later commit does not remove it — anyone who clones the repo can walk the history and read it. A leaked key is not a line you can quietly fix; it is a key you must rotate, everywhere, immediately. And the usual advice — "tell the agent to use environment variables" — helps until it does not. That instruction lives in a prompt or a config file the model may or may not honor on any given turn. One forgetful session, one quick test, one snippet pasted from elsewhere, and the secret is back in the diff. Discipline that depends on the AI remembering every time is not a control. It is a hope.
How afterclick keeps keys out of your code
afterclick is a governance platform for AI-built software, and it treats secrets as a first-class problem. Claude is the developer. afterclick is everyone else — including the part of the team whose job is to make sure credentials never touch the repo. The real fix is to make the raw secret something the agent never handles in the first place, and that is what afterclick does.
A Keys Vault, not a key in the file. Secrets — API keys, passwords, tokens — live in afterclick's encrypted vault, outside your codebase. The agent acts on real systems through governance rather than by pasting raw keys into source. The credential does its job; it just never exists as plaintext in a file you might commit. There is no key in the diff because there is no key in the code, and there is nothing for git history to capture.
A second eye that catches the slip. Vaulting the keys you know about does not help with the one the model inlines from a snippet at midnight. So afterclick's independent second eye reviews secret-touching changes and flags a hardcoded credential before the commit — when fixing it is one edit, not a fleet-wide rotation and an incident writeup. It reads the diff for the shape of a leaked secret, the exact mistake that produced those public-repo headlines, and surfaces it in plain language while it is still cheap to undo.
Advisory by default, enforce when it counts. By default the second eye surfaces the concern and you decide — keep building, or stop and move the key into the vault. For a credential you treat as untouchable, switch on opt-in enforce so a hardcoded secret is blocked rather than merely noted. You set how hard the guardrail pushes; the raw key never sits in source either way.
An audit trail and rollback. Every governed change is recorded on a read-only human dashboard with a rollback path. If something does slip, you can see what changed and undo it — instead of reconstructing the damage from a transcript that already scrolled away. The same vault that holds your Stripe key also holds your deploy and email credentials, so afterclick can govern the business actions those keys unlock, not just the code.
In practice it looks like this: you tell the agent to add a Postmark email integration. Instead of pasting your API token into the source, it pulls the credential from the Keys Vault and wires the call through governance — no token in the file. Later, a snippet it borrows for a webhook handler carries a hardcoded test key; the second eye flags it before the commit, you have it swap to the vault reference, and the dashboard records the catch. Nothing with a live secret ever reaches a commit.
| Aspect | Without afterclick | With afterclick |
|---|---|---|
| Where the secret lives | Pasted inline in source | Encrypted Keys Vault, outside the code |
| Secret reaching a commit / public repo | One git push away | No key in the code means no key in the diff |
| "Use env vars" gets forgotten | Back in the diff next session | Second eye flags the hardcoded secret before commit |
| Leaked key found from a bill | First you hear of it | Audit trail and rollback surface the change early |
A leaked key should be impossible, not just unlucky
The difference between a safe integration and a five-figure surprise is whether the secret ever lived in your source. Telling the AI to be careful is not a control. Removing the raw key from its reach is.
afterclick's Keys Vault keeps credentials out of the code by design, and its second eye catches the slips — advisory by default, free to start, in one paste. Let the AI build the integration. Just stop letting it hold the keys.