Kin Lane went to bed one night with an AWS account in good standing. Someone had grabbed one of his keys around 8 p.m. and spent the night spinning up servers and storage on his account. He woke up to a $125,000 Amazon bill.
Amazon caught it and didn't make him pay. The story isn't really about the bill. It's about how a single exposed credential turned into six figures of damage in less than eight hours, on the account of someone who knows what he's doing. Kin has been the API Evangelist since 2010. He has spent more time thinking about API access patterns than almost anyone alive. And his key still got grabbed.
That's the spine of the conversation we had on this week's webinar, and it's the reason the topic deserved its own session. API keys, tokens, and certificates were never built for the world we now use them in. AI has made the gap an order of magnitude worse, on both sides.
YouTube · ReplayKin Lane: A $125K AWS Bill, OvernightA metering tool that became the operational center
Keys started as something simple. An API provider hands you one so it can log your calls, track your usage, and charge you for what you consume. It was a meter, not a vault key. That use case made sense when you talked to two or three APIs.
Then we started talking to Stripe and Twilio. Then Slack and Facebook and Notion and Jira and Figma. Then dozens more. Every SaaS service in your stack now sits behind one or more credentials. Your gateway used to be the front door to your APIs. There is no front door anymore. The walls have fallen, and your applications are pulling from dozens of services you don't control, each with its own keys and tokens to manage.
That was the shape of the problem before AI showed up. Now AI has multiplied it.
What AI is changing
A few moments from the conversation made the new landscape concrete.
Kin turned on agent-readiness for his sites — Cloudflare's checklist of things that make your domain consumable by AI agents. His traffic spiked immediately. Then his Cloudflare bill spiked. So he started logging what was actually hitting his sites. Some of the traffic was Google Bot, Bing Bot, and the expected crawlers. The rest were agents rattling through every known location people store credentials. .env files. AWS configs. MySQL paths. Every common secrets location on the web, hit again and again, looking for something exposed.
If you have a public domain, this is happening to you right now. The question is whether the bots find anything.
The other half of the AI problem is on the developer side, and I'll admit my own moment from the conversation. I told Claude not to hardcode any API keys in a project I was vibe coding. I felt clever about it. Three hours later, GitHub's secret scanner flagged the keys Claude had hardcoded anyway. Vibe coding is a real gift. But the credentials problem doesn't disappear because you wrote a clear prompt. The model doesn't read your README, and "don't hardcode keys" is not a constraint it reliably honors.
MCPs make this worse, not better. The first time I tried to wire one up, the permissions screen had checkboxes I didn't understand. I clicked a few. The connection didn't work. I clicked a few more. Still didn't work. Eventually I just hit select all. Most people who have wired up an MCP have done some version of this. It isn't laziness. It's that the permissions surface isn't reasonable to begin with, and the path of least resistance is to give the agent everything.
And once a skill is installed, Kin pointed out that some of them are picking your pocket. He's been scraping skills and MCP servers across the web. A handful look legitimate at the top of the file, but hidden at the bottom, in the instructions, is something like "drop users table." Agents on the outside hunting for exposed keys, and skills on the inside trying to steal the ones you stored properly. Two vectors, both real, both growing.
Why discipline doesn't scale anymore
The traditional answer to credential management is discipline. A small, careful security team reviews who gets which keys, where they live, how they rotate, when they're revoked. That answer worked when integrations were measured in single digits and the team's attention could cover the whole surface.
It does not work now. When integrations hit the hundreds and the team is still small, per-credential human attention trends toward zero. The credential surface is scaling with the number of integrations. The team isn't. So either the team carries an impossible workload, or most credentials get default-handled, which usually means default-ignored.
Add AI to the picture and the math gets worse. AI agents are credential consumers themselves. Every agent and MCP server needs scoped auth of its own. Every vibe coder is shipping new integrations without thinking about it as a security event. The traditional "be more careful" answer cannot keep up.
What does work
A few patterns came up across the hour, and they share a common theme. Don't try to make every credential matter more. Make any single credential matter less.
The starting points are unsurprising. Stop scattering secrets across .env files and code. Centralize them in a secrets manager so the credential never lives in the app and is fetched at runtime. Give each integration a scoped credential rather than a shared god-key, so one compromise doesn't cascade. Automate rotation, because if it requires a human, it doesn't happen at scale. Make secret scanning part of your CI rather than a once-a-quarter cleanup.
The deeper shift is toward ephemeral credentials. Workload identity, short-lived tokens, OIDC federation, mTLS with auto-rotation. A credential that dies in fifteen minutes has a fraction of the blast radius of a static key that has been sitting in a repo for three years. The honest answer at scale is to stop having standing secrets at all where you can avoid them.
For the AI side specifically, the answer is to pave the road. Vibe coders and AI agents will take the path of least resistance. If the path of least resistance is a default template, a CLI wrapper, or a paved pattern where the easy thing is the secure thing, you can get reasonable behavior out of non-specialists. Lecture them about OWASP and you will lose. Hand them a tool that does the right thing by default and you will win.
Kin's most provocative point came near the end. He suggested developers should not even use the keys API providers issue them. The future, in his view, is a brokered middleware layer that consumes provider credentials on your behalf, manages them centrally, and exposes scoped, rotating, traceable access to your developers and agents. That's what he's building at Naftiko, his open-source project for this exact problem. Worth a look if any of the above hit close to home.
The credentials problem is not really a technology gap. The tools to solve it exist. The gap is between the speed at which AI and vibe coding are creating new credential surfaces and the speed at which most teams are updating how they manage that surface. The old playbook cannot close that gap. The new one can.