API keys are a liability: the security case for keyless AI tooling

Most “connect AI to your tool” guides open the same way: generate an API key and paste it here. It feels like a one-time setup step. It isn’t. The moment you paste that key, you have created a long-lived secret that someone now has to store, scope, rotate, and keep out of every log, config file, and screen-share for the rest of its life. That is not a setup step. That is a standing liability.

This article makes the security case against API keys as the default way to wire AI into your developer tooling, and the case for a keyless alternative. It is an opinion, but it rests on facts you can check.

Disclosure: I work on SQL Sage, which I’ll use later as a concrete example. The argument below holds regardless of which tool you use.

Why is an API key a security liability, not just a credential?

Because a key is a bearer secret: whoever holds it is you, as far as the model provider is concerned. There is no second factor, no device binding, no session that expires in an hour. A string of characters is the whole identity. And strings leak.

They leak at a scale that is hard to overstate. GitGuardian’s State of Secrets Sprawl 2025 found 23.8 million secrets leaked into public GitHub repositories in 2024 alone, a 25% jump year over year. GitHub’s own security team puts the number even higher across all the repositories it scans: 39 million secrets leaked in 2024, with its push-protection system blocking more every minute. API keys are a large share of that: they are short, easy to hardcode, and trivially copy-pasted into a config file that gets committed by accident.

The uncomfortable part is that a leak is not the end of the story, it’s the start of one. The same GitGuardian report found that 70% of the secrets leaked in 2022 were still active years later. A key you forgot you created, pushed to a repo you forgot was public, is very likely still a working door into something.

What actually happens after a key leaks?

Three things, and none of them are quick.

First, someone can spend your money or reach your data. A model API key bills against your account. A leaked one is a blank cheque until you notice. If the key was over-scoped, which most are, because scoping keys tightly is tedious and skipped, the blast radius is everything the key can touch, not just the one thing you wanted it for. OWASP’s Secrets Management Cheat Sheet is blunt about both halves of this: never hardcode secrets, and apply least privilege so a single leaked credential can’t unlock everything.

Second, you have to rotate. That means generating a new key, finding every place the old one lives, updating each one, and revoking the old key without breaking anything still using it. OWASP recommends automating this precisely because doing it by hand “increases the risk of leakage” and “introduces the risk of human errors.” For a solo developer with one key in one tool, rotation is an annoying afternoon. For a team, it is a project.

Third, you carry the key forever, or until you remember to kill it. This is the quiet cost. Every active key is attack surface that never sleeps. Multiply it across a team, several tools, and a few years of turnover, and you get secret sprawl: more credentials than anyone can inventory, most of them over-privileged, some of them forgotten, any of them one bad commit away from a public repo.

Isn’t this an operations problem, not a security one?

It is both, and that is exactly why it is worth taking seriously. The cost of an API key is paid in three currencies: money (per-token billing on a separate meter), operations (rotation, inventory, access control), and security (every one of those credentials is a thing that can leak). Teams tend to notice only the first and discover the third during an incident.

The reframing that helps is this: a secret you never created cannot leak. You cannot misconfigure, over-scope, or forget to rotate a key that does not exist. The most reliable way to secure a credential is to not have one.

What does “keyless” mean, and is it really safer?

Keyless means the tool authenticates through an account you already have and already manage, rather than a new long-lived string you paste in. Instead of minting an API key, you sign in with your existing Claude account (via Claude Code) or your ChatGPT/Codex account (via Codex CLI), and the AI runs on that subscription. The sign-in uses the provider’s own session and token flow, the one already protected by your account’s password, multi-factor auth, and revocation controls.

The security win is concrete, not rhetorical:

• No new secret to store. There is nothing to hardcode, nothing to leak in a config file, nothing to catch in a screen-share.
• No separate thing to rotate. You are not maintaining a key’s lifecycle on top of the account you already maintain.
• Revocation lives where you already look. Lose a laptop? You revoke a session in your provider account, the same place you already manage access, instead of hunting for a stray key in a dozen tools.
• One fewer meter. Keyless runs on a subscription you already pay for, so there’s no second per-token bill to watch.

This is not magic, and it is not a claim that accounts never get compromised. It is a smaller attack surface. You still protect one account well instead of protecting one account and an open-ended set of keys it spawned. If you genuinely need a raw key, for an automated pipeline, say, keeping it as an option is reasonable. Making it the default for every interactive tool is how sprawl starts. I wrote more about the day-to-day of this in getting AI into SSMS without an API key.

How should you evaluate an AI tool’s key model?

A short, checkable list you can apply to any tool, including mine:

• Can it run without you minting a new API key? If the only option is “paste a key,” you are signing up for a secret’s whole lifecycle.
• If it uses a key, is it scoped tightly, or does it get broad access by default? Least privilege should be the default, not a setting you have to find.
• Where does revocation happen, and how fast? You want one place you already know, not a key you have to remember exists.
• Does the vendor sit in the data path? A keyless design that talks to your AI account directly keeps the tool vendor out of the loop entirely. That ties into a separate but related question: what the tool actually sends to the model.

Where SQL Sage fits (the honest part)

I work on SQL Sage, which is built keyless on purpose. It is an add-in for SQL Server Management Studio and a plugin for DBeaver (the DBeaver plugin is Windows-only and covers PostgreSQL, MySQL/MariaDB, Oracle, SQL Server, and SQLite). You sign in with your own Claude (Claude Code) or ChatGPT/Codex (Codex CLI) account; there is no API key to create, store, or rotate. If you prefer to bring your own Anthropic key, you can, but it is an option, never a requirement.

The keyless model also pairs with the rest of how the tool is designed to be safe: it stays read-only by default, so writes wait for your explicit confirmation, and it sends your schema and SQL text to the model, never your data rows unless you opt in per session. You can see both products on the LumaSoft products page.

But the real takeaway is the principle, not the product. Every API key you create is a liability you will carry until you remember to kill it. The most secure credential is the one that was never minted. When you evaluate any AI tool, ask first whether it needs a key at all, because the answer tells you how much of a secret’s lifecycle you are about to inherit.

SQL Sage is made by LumaSoft (LUMA sp. z o.o.). Not affiliated with Microsoft, Anthropic, OpenAI, or DBeaver.