Every business that writes or commissions software eventually accumulates API keys: the email platform, the payment processor, the cloud storage account, the CRM integration. And the fastest way to make any integration work is to paste the key straight into the code. It works, it ships, and it quietly becomes the most dangerous line in the file.
We covered this in one of our AI workshops while showing how our own automation platform handles credentials, and it’s worth writing down, because the pattern applies to any business with custom code, scripts, or integrations.
What’s actually wrong with a key in the code?
Code is the most copied artifact in your company. It lives in version control with full history, on every developer’s laptop, in backups, in file shares, and now in every AI tool that reads a file to help someone work. A key pasted into code is replicated into all of those places, and it stays valid in all of them until someone rotates it — which nobody does, because nobody remembers it’s there.
That’s the asymmetry: the key was added in one place, but it now exists in dozens, and revoking access means finding a credential nobody has thought about in years. When a laptop is stolen, a repo is accidentally made public, or an ex-employee’s copy of the code walks out the door, the key goes with it.
Where should keys live instead?
Two tiers, and most businesses should use both:
Environment variables are the minimum: the key lives in the platform’s configuration (an Azure App Service setting, a deployment variable), not in the code. The code asks for it by name at runtime. Anyone with the code has the name, not the value.
A secrets vault is the proper answer for anything beyond a single app. In our own platform, every external service credential lives in Azure Key Vault; when a workflow needs to reach a Microsoft 365 tenant or an outside API, it fetches exactly the key it needs at runtime. One place to store, audit, rotate, and revoke — and looking at the code tells you nothing.
What’s better than protecting the secret? Not having one.
The step most businesses haven’t heard of: for connections inside a cloud platform, you can often eliminate the password entirely. In Azure this is a managed identity: the web app itself is granted an identity, that identity is granted access to the database, blob storage, or vault, and the connection string contains no password at all.
As Greg put it in the workshop: “if the code was compromised, there’s nothing to see.” That’s the end state to aim for — a codebase where a full copy in an attacker’s hands contains no credentials, because the trust lives in the platform, not in a string.
What should a business owner actually do?
You don’t need to read code to manage this risk. Ask whoever builds or maintains your software three questions:
- “Where do our API keys and connection strings live?” The answer should name a vault or platform configuration, not “in the app.”
- “Has a key ever been committed to a repo?” If yes, or if nobody knows, rotate those keys now. Deleting the line doesn’t remove it from history.
- “Which connections could be passwordless?” Anything app-to-database or app-to-storage inside Azure usually can be, and it’s typically a configuration task, not a rewrite.
Credential handling like this is one of the controls cyber insurance applications and client security questionnaires increasingly probe, alongside MFA and backups. It’s also one of the checks in our cybersecurity risk assessment — embedded credentials turn up in almost every environment that has ever commissioned custom software.
Braintek has built and secured software for Houston and Dallas-Fort Worth businesses since 2002, and everything we build runs on vaulted or passwordless credentials by default. If your business runs on custom code and nobody can answer where the keys live, our cybersecurity services team can find out, and the form below is the place to start. Internal apps deserve the same treatment on the login side too — see why your internal apps should use Microsoft 365 single sign-on.