The Agent Can Use Your Stripe Key. It Should Never Be Able to Read It.

Sooner or later every app needs a key. Payments need a Stripe key, email needs a sending key, a map needs a maps key. In an AI builder the obvious move is to paste it into the chat: here is my key, wire it up. The agent will happily oblige, and the integration will work on the first try.

That key is now in the conversation history, in whatever the model wrote to disk, possibly in a commit, and possibly in the JavaScript bundle every visitor downloads. None of those are places you chose. You wanted the app to be able to use the key. You did not need the agent to know it.

Using a secret and reading a secret are different permissions. Most tools hand out both at once.

Why the model should never see the value

A model that can read a secret can be talked into writing it somewhere. It does not take malice: an instruction hidden in a web page it read, a README in a dependency, or a plain misunderstanding of a request is enough to get a key printed into a log file or a config the build ships. The model has no reliable sense of which strings are dangerous. The only robust defence is that it never holds the value in the first place.

So in Vibez.now the agent can ask which secrets exist, and whether each is meant for the server or the browser, but it cannot read a value or set one. When it needs a key that is not there, it asks for it and stops, rather than inventing a placeholder and building on top of it. You add the value yourself, in a form the model never sees, and the code reads it at runtime as an environment variable.

Server keys and browser keys are different things

Most providers give you two kinds of key, and mixing them up is the single most common way an AI-built app leaks one. A publishable key is meant to be public. It goes in the browser and can only do harmless things. A secret key can move money, send email as you or read your customer list, and must only ever run on a server.

The choice is made per secret, when you add it, not inferred from a naming convention. Frameworks often expose any variable that starts with a particular prefix to the browser. That rule is invisible in the code that uses it, and an agent renaming a variable to get something working can move a secret key into the bundle without a single line that looks wrong.

Scan what ships, not just what you wrote

Checking the source code for keys is necessary and not sufficient. A build tool can inline a value into the output even when no source file contains it. The bundle is what the world receives, so the bundle is what has to be checked.

Vibez.now runs a security scan before every publish, over the source and over the built output, looking for the specific shapes of real credentials: Stripe live keys, cloud access keys, AI provider keys, GitHub tokens, private key blocks. Findings block by severity, not by count. One live secret in the bundle stops the publish. A dozen style warnings do not, because a scanner that cries wolf trains people to ignore the time it is right.

A short checklist for any AI-built app

1. Search the chat history for anything that looks like a key. Rotate what you find.
2. Open the deployed page, view the source and the loaded scripts, and search for sk_, secret and key. A secret key there is a live incident.
3. Check that every endpoint that uses a secret also checks who is calling it. A hidden key behind an open endpoint is still an open endpoint.
4. Give each app its own key, restricted to what it needs. One shared key across five projects means one leak is five incidents.
5. Set spending or rate limits at the provider, so the worst case of a leak has a ceiling you chose.

The aim is an app that can use every key it needs while the agent that built it never knew any of them. That is not a limitation on the agent. It is what makes it reasonable to hand one the keys at all.