Braintrust Got Breached. Every AI Builder Should Check Their Keys.
Braintrust's cloud breach forced thousands of AI engineers to rotate API keys overnight. For builders stitching together AI services, it exposes how fast one vendor breach cascades across your stack

The notification went out late Tuesday. If you were a Braintrust customer, you already knew the drill. Log into every integration, revoke the old key, generate a new one, and pray you did not miss a cron job somewhere. The company confirmed that hackers broke into one of its Amazon cloud environments, and now every user has to rotate sensitive API credentials.
Braintrust calls itself an operating system for engineers building AI software. That positioning is exactly why this stings. It sits close to the code. It touches your prompts, your evals, your model outputs. A breach there does not stay there. It ripples outward through every connected service, every downstream pipeline, and every production app feeding data back into its dashboards.
The Stack You Stitch Is the Stack You Secure
Most indie builders and small teams are running a patched-together architecture right now. You have your inference provider, your evaluation framework, your vector store, your observability layer, and maybe a hosted fine-tuning service. Each one requires a key. Each one is a door. Lose one tool and the rest of your stack starts to wobble. The thread that ties your app together frays fast.
This is the hidden cost of moving fast. You add a service to run evals, another to manage prompts, another to trace model calls. Suddenly your app has six external dependencies, six sets of credentials, and six separate security postures you never fully audited. You trusted the logo and the terms of service. Then the terms changed at 2 a.m. when attackers compromised someone else's cloud instance.
What to Do Before You Ship Today
Start with the obvious. Rotate keys immediately if you have ever touched Braintrust or any tool with a similar integration. Do not assume you are safe because you stopped using it last quarter. Old keys linger in environment files, CI pipelines, and teammate laptops. Hunt them down and kill them. Then split your environments. Production keys should never live where development happens. If your staging setup can reach live user data, fix that before lunch.
Next, reduce your blast radius. Give each service the narrowest permission it needs. Your eval framework does not need write access to your database. Your prompt manager does not need to delete S3 buckets. Treat every API key like a live wire because that is exactly what it is. One leaked credential should burn only a single function, not your entire user base.
Own the Code That Owns Your Product
There is no such thing as a risk-free stack, but there is such a thing as a transparent one. When your tooling is open source and your code lives in a repo you control, you can see what touches what. You can self-host when a vendor hiccups. You can fork and patch if the upstream response is too slow. Braintrust's breach is a reminder that vendor trust is a liability you actively manage, not a checkbox you tick at signup.
This is part of why we built Botflow to be GitHub-native and fully open source. Your code belongs to you. Your repo is your source of truth. When the next breach hits, and there will be a next one, you want the option to inspect the plumbing, move your backend, or change providers without rewriting your app from scratch. Speed matters when you are shipping features. It matters even more when you are responding to someone else's disaster.
So rotate your keys. Audit your integrations. Ask yourself which tools you could afford to lose tomorrow. If you cannot afford to lose a tool today, you should understand exactly how it touches your stack. Build like the ground is shifting because it is. The builders who survive the breach are the ones who saw it coming and kept their options open.