Aptible

Two weeks ago, our Head of Engineering built an AI security scanner in about an hour (during a meeting). It cost $20 and found bugs that had survived a $25k pentest. Here’s what this means for modern security programs: As fast as we can prompt an LLM to scan our codebase for vulnerabilities, the attack side can move just as fast. They have access to the same models and the same prompts that we do (they just don’t have direct access to our codebase, but that’s not a necessary precursor to an attack). The window to patch before exploitation used to be ~72 hours, and now it’s just 1 or 2. So given how accessible AI-powered attack tactics have become, it’s no longer realistic to try to protect against breaches. The focus instead should be minimizing the blast radius of the breach that inevitably happens. That means building for containment as well as prevention: - Network segmentation so a compromised system can't reach everything else - Identity segmentation so a single compromised credential doesn't either - Log infrastructure that can answer "what did they access and when” (not just stored logs, but queryable ones) - Revocation and kill switches that work at machine speed, not ticket speed Because most compliance frameworks don't require this^ layer, so many incident post-mortems start with things like, "despite passing our last audit… ☠️" But it’s not as scary as it sounds, it’s just a change that security programs must adapt to. The same AI that lowered costs and increased speed for attackers has done the same for the defending team. And companies like Vercel (and soon Aptible 🤫) are starting to open source the agents they’ve built to help with this. Our Head of InfoSec, Mat S., wrote up an article about the changes he’s seen in the industry, where it’s going, and what we’re doing about it. Link to his post in comments 🔗

If you’re a health tech startup trying to get a BAA with Anthropic... 🪦 Here’s what you should know about what’s covered and what isn’t: Things I’ve heard from customers just this week about their experience trying to get a BAA with Anthropic… - “I asked about a BAA, but… they didn’t seem to know anything about it.” - “We had to go to their manager to find a friend of a friend who knew their head of sales to tell them that we’ve been waiting for three months to get a response from their sales team.” To get Claude Code covered under a BAA, you need: Zero Data Retention enabled, an enterprise plan, a qualified account, and the number of a sales rep. That all takes time and $$$, if you can get it at all. Developers building agents on top of Epic and Cerner APIs end up running Claude Code in environments where PHI is present: test fixtures, local database dumps, dev logs. That's all in scope for HIPAA. The terminal can be covered with ZDR configured. But the web interface, desktop app, and review and security tools have no coverage path; they’re incompatible with ZDR regardless of your plan 🥺 We wrote up a guide for digital health teams struggling with this BAA debacle: what's covered with your Claude BAA (if you have one), what requires ZDR and what doesn't, and what you still need to build on your own to remain compliant. Link in comments 👇 Happy to chat in comments or DMs if anyone has more questions that aren’t answered in there 👋

Google’s DORA report says 90% of companies have adopted platform engineering. I’m not buying it. If platform engineering was truly that mature, we wouldn’t be staring down the security and compliance mess AI is creating right now. Today, developers spend hours a day inside AI tooling. But trust is low, and guardrails are almost nonexistent. Most organizations still lack the ability to: * Validate AI-generated code quality at scale * Govern sensitive data flowing into AI systems * Track compliance for AI-driven changes * Adopt the right models without surprise costs * Secure deployment pipelines moving at AI speed These aren’t just “nice to haves.” In regulated industries, they’re existential. That’s why we think platform engineering needs to evolve beyond Kubernetes clusters and wiki pages and into something that can keep up with AI adoption. Now that AI is everywhere, teams need to start thinking about security, compliance, and governance as first-class features, not afterthoughts. We're thinking about baking it directly into our PaaS so that AI guardrails are in place from the start. 👉 Here’s what I’d love to know: If we solved these AI security and compliance problems out of the box, what would that unlock for you? Tell me all about it in the comments 👀 💬

🚨 CrashLoopBackOff 🚨 If you run Kubernetes, you’ve seen it. You hope it won’t show up. And yet… it always does. This has been a recurring annoyance for early Unpage users. And it always seems to happen at the worst possible times 🫠 * Right after a “clean” deploy. * When customer traffic peaks. * Mid-incident when it’s the last thing anyone needs. And every time, the cycle repeats: chasing logs, combing through manifests, checking health probes. Another 20 minutes of toil. Again. After enough times of hearing about this happening for Unpage users on K8s, we built an agent to automate it for them. Here’s what it does when a pod is stuck in a crash loop: 1. Pulls pod status, restart counts, and recent events. 2. Captures current + previous container logs. 3. Checks resource usage (CPU, memory, OOM kills). 4. Validates ConfigMaps and Secrets. 5. Correlates errors in Datadog. 6. Verifies connectivity to external dependencies. 7. Posts a clear root cause + recommended actions back to PagerDuty. In other words: 🔍 Same checks as an SRE. ⚡ Just a few lines of YAML. ⏱ Already saving them hours every week. Now, CrashLoopBackOff alerts don’t slow anyone down. With our open source project, you can create an agent for pretty much any repetitive SRE task. This is just one example 😏 We wrote a guide for the CrashLoopBackOff agent so you can run it using Unpage, too. 👉 Want it? Comment “k8s” and I’ll send it your way.

❌ Deploy failed You’ve seen this screen before. And you know what happens next. You’re ready to ship. The code is clean. Tests pass locally. You push to GitHub. The build kicks off... ‼️ Build failed. Now you’re stuck doing this instead of shipping: * Digging through logs * Guessing what went wrong * Trying a fix * Pushing again * Repeating... Last month, we lost 3 hours debugging a mysterious CI failure that only happened during deploys. Everything worked perfectly on local machines, but the build kept failing with cryptic module resolution errors. The root cause: A breaking change in an upstream dependency. 3 hours, gone. For something that should have been obvious. That was when we decided to automate the entire process. We built a GitHub Actions agent that now handles these failures for us automatically: * Detects when a GitHub Actions build fails * Fetches the job logs automatically * Prompts Claude Code with relevant errors in headless mode to generate a potential fix * Opens a pull request with the proposed change for human review ✋ The agent doesn’t merge anything on its own. 👀 A human still reviews every PR before it’s merged. 😄 But nobody has to dig through logs manually anymore. Last week alone, it fixed 14 deploys automatically. We think it will eventually debug 90%+ of our build failures and at least get us started on the rest. Want to build a GitHub Actions agent to automate build failures for your team? Comment “build” and I’ll send you a step-by-step guide along with the repo.

Our growth engineer, Michael Peterson, just built a GitHub Actions agent to automate investigation and remediation of failed builds. Here’s how it works: * Detects when a GitHub Actions build fails * Fetches the job logs automatically * Prompts Claude Code with relevant errors in headless mode to generate a potential fix * Opens a pull request with the proposed change for human review Last month, we lost three hours debugging a mysterious CI failure that only happened during deploys. Everything worked perfectly on our local machines, but the build kept failing with cryptic module resolution errors. We eventually discovered a breaking change in an upstream dependency. That was the moment Michael decided to automate this process. The agent is not doing YOLO merges, a human still reviews every PR before it is merged. But nobody has to dig through logs manually. Last week alone, the agent fixed 14 deploys for us automatically. Time will tell, but we’re pretty confident we can get this to successfully debug 90%+ of our build failures. It’ll at least get us started on debugging the rest. We wrote a step-by-step guide and open sourced the repo so you can launch your own GitHub Actions build failure agent. Both links are in the first comment. ❓ What have you done to counter failed builds in your pipeline?