**00:00:02 — Maya:** Welcome to Development Radio. I'm Maya, here with Alex, and today is a little different. This is our first special weekly: the week in AI and cyber, for people who build and run software. Alex, did you manage to keep up with the news this week?

**00:00:18 — Alex:** I tried. By Tuesday I had about forty tabs open. Then I closed all of them, very decisively, and felt great for almost an hour.

**00:00:27 — Maya:** That's the trouble with a week like this one. Someone at work says, "Did you see the thing?" And you nod. And you hope they don't ask a follow-up question.

**00:00:36 — Alex:** The nod is a real professional skill. I'd say half of senior engineering is a confident nod and a whiteboard.

**00:00:43 — Maya:** And the other half is quietly reading the article afterwards, on your phone, in the elevator.

**00:00:49 — Alex:** Every single time. In my defence, my phone was busy. I spent the weekend with the espresso machine.

**00:00:55 — Maya:** Is it fixed?

**00:00:56 — Alex:** It's not broken. It's in a transitional state.

**00:01:00 — Maya:** That's what half the internet said this week, too. Okay, it's a good way in, actually.

**00:01:04 — Alex:** I knew it would come back to me somehow. So what's the plan? Because I know you have a plan. You always have a notebook.

**00:01:12 — Maya:** I do have a notebook. We picked five stories from the last seven days. Not everything that happened. Just the ones we think you'll hear about at work, or actually have to do something about. For each one, we'll say what happened, why it matters if you build software, and whether we think it's real or mostly hype.

**00:01:30 — Alex:** And we're not going to read you the news. You can get headlines anywhere. We're going to argue about them.

**00:01:36 — Maya:** Politely.

**00:01:37 — Alex:** Mostly. And we're keeping score. At the end of every story, we each give a verdict. Hype, or real.

**00:01:44 — Maya:** Which means, at some point today, I get to tell you you're wrong. On the record.

**00:01:50 — Alex:** You've been waiting for that since the first episode.

**00:01:52 — Maya:** Since before the first episode. Alright. Here's the question for the next half hour. Out of everything that happened this week, what actually changes how we build and run software? And since so much of it is AI, I'm going to watch for one more thing. Where the people are, in each story.

**00:02:11 — Alex:** Somewhere near the coffee, usually. Let's start with my favourite story of the week. It's a little absurd. And it's also kind of terrifying.

**00:02:19 — Alex:** You know the little padlock in your browser. When you visit your bank, your browser checks a certificate. That certificate was signed by a company called a certificate authority, and your browser trusts a short list of those companies. The whole arrangement rests on one thing. Each authority keeps a private signing key that nobody else can guess.

**00:02:40 — Maya:** Right. The key is the secret. If someone else has it, they can sign a certificate for any website, and your browser believes it.

**00:02:48 — Alex:** So. Last Saturday, the browser makers got a report about a certificate authority called eMudhra. Eight of its intermediate certificates had private keys that were tiny. Intermediate just means the certificates an authority uses day to day, so its main key can stay locked away. Mozilla's write-up says the keys, quote, "all used integers less than 256".

**00:03:12 — Maya:** Less than two hundred and fifty-six. Out of a key that's supposed to be how big?

**00:03:18 — Alex:** A number with more than a hundred digits. Something you couldn't guess with every computer on Earth. Instead, all of these keys were below two hundred and fifty-six. And one of them was the number four.

**00:03:30 — Maya:** Four.

**00:03:31 — Alex:** Four.

**00:03:32 — Maya:** My bike lock has a better combination than that. Okay, walk me through it. What could someone actually do with a key like that?

**00:03:40 — Alex:** First, guessing it is trivial. You try one, then two, then three, all the way up to two hundred and fifty-five. A laptop finishes that before your coffee does. And once you have the key, you can sign certificates. Most of these were for websites. So that's a certificate for any site you like, say a bank, that a client trusting this authority would accept. And a couple were for signing code, so you could make software look like it came from someone legitimate.

**00:04:07 — Maya:** So the padlock shows up, everything looks normal, and you're actually talking to someone else.

**00:04:13 — Alex:** For a client that trusted these certificates, yes.

**00:04:16 — Maya:** Okay. How does that even happen? Nobody types "four" on purpose.

**00:04:21 — Alex:** Here's eMudhra's own explanation. Their key ceremony, which is the very formal process where these keys get created, used a script with a flaw. That flaw generated a second, weak key pair. And staff picked the weak one by mistake, quote, "because the key labels were similar". They also wrote, "There were human errors in multiple steps of the process".

**00:04:42 — Maya:** That's the part I'd underline in my notebook. It's not one mistake. It's a script bug, and then a person choosing between two things with almost the same name, and then nobody catching it afterwards.

**00:04:54 — Alex:** And these keys were created in April of last year. So they sat there for about a year and a half.

**00:05:00 — Maya:** Was anyone actually attacked with them?

**00:05:02 — Alex:** As far as anyone can tell, no. There's a safety net here called certificate transparency. Chrome, Safari and Firefox only accept a website certificate if it's been written into public, append-only logs. And nothing issued under these intermediates ever showed up in those logs.

**00:05:20 — Maya:** So if someone had quietly made a fake website certificate with one of those keys, those browsers would have turned it away.

**00:05:26 — Alex:** Exactly. And there's no evidence of misuse. The browsers moved fast, too. Firefox and Chrome blocked these certificates the same day as the report. Apple and Microsoft followed early this week.

**00:05:39 — Maya:** So if everyone's browser is fine, why is this our first story? It sounds like the system worked.

**00:05:45 — Alex:** Because your browser isn't the only thing that trusts certificates.

**00:05:49 — Maya:** Oh. Right. Our services.

**00:05:52 — Alex:** Your services. Think about everything in your stack that makes an outbound HTTPS call. A Java service has its own trust store. A Python service usually carries a bundle of certificates called certifi. Node has a list baked in. And a Go binary uses whatever list was in the container image when it was built.

**00:06:11 — Maya:** And the container image was built whenever it was built. Months ago, maybe.

**00:06:16 — Alex:** Exactly. Go shipped a fix this week, and the Go team wrote, "We highly recommend immediately upgrading to this release". A Mozilla engineer is keeping a public tracker of which of these trust lists have been fixed. Some are still pending.

**00:06:30 — Maya:** So the browser world fixed this within three days. And a backend fleet fixes it whenever somebody happens to rebuild the image.

**00:06:37 — Alex:** That's the Staff lesson for me. Trust isn't one setting you configure once. It gets copied into every image, every runtime, every vendor appliance. And it ages there.

**00:06:48 — Maya:** You know what else this reminds me of? Every system I've ever seen has two things with nearly the same name. Payments, and payments two. The production key, and the new production key.

**00:07:00 — Alex:** And everyone knows which is which. Until the one person who knew goes on holiday.

**00:07:06 — Maya:** So I'd add a second, smaller check. Anywhere a human has to pick between two secrets, or two environments, make the wrong one hard to pick. Different names. A check that refuses the old one. Don't rely on someone reading a label carefully at the end of a long ceremony.

**00:07:23 — Alex:** And on Monday, practically: rebuild your base images and bump your runtimes, which you want to do anyway. The tracker even has test websites you can point a client at, to see whether it still trusts those certificates. And then ask one boring question. If we had to rebuild everything today, how long would it take?

**00:07:41 — Maya:** I like that, because it isn't really about this certificate authority. It's about whether rebuilding is a button or a project.

**00:07:49 — Alex:** Spoiler. For most teams, it's a project.

**00:07:53 — Maya:** Okay. Verdict time. Hype, or real? I'll go first. Real. Not because anyone was attacked, nobody was. But because there's a good chance some container you own still trusts those certificates, and nobody on your team knows it.

**00:08:08 — Alex:** I'm going to split it. Hype, for the internet. The browsers handled it beautifully. Real, for your Docker images.

**00:08:16 — Maya:** That's a cop-out.

**00:08:17 — Alex:** That's nuance. It's completely different.

**00:08:20 — Maya:** We'll allow it. Once. That's one story down, four to go. And the next one is the big one.

**00:08:26 — Maya:** Story two. Yesterday, Wednesday, PHP shipped emergency patches for two critical bugs. People are calling them PHP to Shell.

**00:08:37 — Alex:** And to be clear for everyone listening, this is PHP itself. The language runtime. Not a plugin. Not a framework.

**00:08:44 — Maya:** Right. The bugs let an attacker run their own code on a server, without logging in, just by sending web requests. Both are rated nine point two out of ten. PHP's own announcement says it affects, quote, "all PHP installations serving web requests". And, quote, "We consider the risk highest for mod_php", which is the classic setup where PHP runs inside the Apache web server.

**00:09:11 — Alex:** All PHP installations serving web requests. That is not a sentence you want to read late on a Tuesday. Do we know what kind of bugs they are? In plain words.

**00:09:21 — Maya:** Roughly. The advisory names them. One is about running out of memory in a way that corrupts things. The other is about stale state. Something left over from one request gets reused by a later request on the same worker.

**00:09:35 — Alex:** Oh, that one I recognise. That's the classic shared-state bug. Every backend engineer has met it in some form. A cache, a global variable, a connection that remembers the last user.

**00:09:46 — Maya:** Same family. Except this time it's inside the runtime, and an attacker can steer it.

**00:09:52 — Maya:** And PHP is everywhere. By the estimates going around this week, it's behind something like seventy percent of websites. WordPress sites. Old internal tools. That admin panel nobody has touched since twenty nineteen.

**00:10:07 — Alex:** Okay, but here's what caught my eye in the headlines. Why was OpenAI involved in a PHP disclosure?

**00:10:13 — Maya:** That's the fascinating part. These bugs were found with help from AI. A security firm called Calif found one in August, through an OpenAI program called Patch the Planet. Separately, the cloud security company Wiz found the vulnerabilities on its own, using its own tools and frontier models. Two teams, both using AI, found the same buried bugs.

**00:10:37 — Alex:** And then everybody has to keep quiet until the patch is ready.

**00:10:40 — Maya:** For about two months. And then it leaked. Details got out early, and a video of a working exploit chain spread online. So PHP moved the release up by a day.

**00:10:51 — Alex:** Oh no.

**00:10:52 — Maya:** And there's another twist. According to the PHP Foundation, one of the two bugs had actually been flagged in an audit back in twenty twenty-four. And then it stalled, for months.

**00:11:04 — Alex:** So it was flagged in an audit in twenty twenty-four, and the fix kept stalling. And this year, AI helped turn it into a working exploit.

**00:11:13 — Maya:** Wiz put it very directly. "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." That's what changed. Not that bugs exist. That turning an old bug into a working attack got a lot cheaper.

**00:11:29 — Alex:** Has anyone actually been hit yet?

**00:11:31 — Maya:** There are reports of attackers probing. Cloudflare said it was seeing early attacks, and other security companies reported mostly reconnaissance. But on patch day, CISA, the US cybersecurity agency, said it hadn't observed exploitation yet. So, attempts reported. Not a confirmed wave of breaches. At least, not yet.

**00:11:52 — Alex:** So where we are. Two critical bugs in PHP, patched yesterday. Found with help from AI. Details leaked early. Attempts reported. Okay. Let me be the person in the hallway. "We don't run PHP. We're a Go and Python shop." Am I done?

**00:12:09 — Maya:** That's exactly the answer I'd push on. Are you sure? Do you run WordPress for the marketing site? A vendor appliance with a little web admin page? An internal tool somebody wrote ten years ago? A base image that happens to include PHP?

**00:12:24 — Alex:** The marketing site. It is always the marketing site.

**00:12:28 — Maya:** And here's the trap for the teams who do know they run PHP. This is a runtime bug. So updating your framework does nothing. Updating your WordPress plugins does nothing. You need the patched PHP itself. And then you need to restart every PHP worker, so the old code is really gone from memory.

**00:12:49 — Alex:** That's the bit people will miss. "We deployed." Great. Did you restart the workers?

**00:12:55 — Maya:** And there's a long tail. VirusTotal looked at servers that reveal their PHP version. About seven hundred and fifty-eight thousand of them run versions that are past end of life. Seven hundred and fifty-eight thousand. For a few of the older versions, back to seven point four, PHP published source patches you'd have to apply yourself.

**00:13:16 — Alex:** And I saw people asking, can't I just change a setting and wait?

**00:13:20 — Maya:** PHP's own answer is no. Their announcement says no configuration change makes an installation safe. Patch.

**00:13:29 — Alex:** So here's the Staff angle for me. The question isn't "are we patched?" It's "do we even know where PHP is?" If you can't answer that within an hour, that's the real finding of the week.

**00:13:41 — Maya:** How would you actually find it in an hour?

**00:13:43 — Alex:** Three places. Your container images: most image scanners can tell you which ones contain a PHP binary. Your software bill of materials, if you keep one. And your vendors. Email the ones whose appliances have a web admin page, and ask the question in writing.

**00:14:00 — Maya:** And the marketing site. Ask marketing. Nicely.

**00:14:04 — Maya:** And what's fast enough? Give me a number.

**00:14:06 — Alex:** For internet-facing systems and a bug rated like this one, I'd want the same day. And if a server can't be patched right away, CISA's advice was blunt: take it offline until it can be.

**00:14:18 — Maya:** And the clock is different now. If AI helped find this, and a demo leaked, the time between "announced" and "attacked" keeps shrinking. "We'll get to it next sprint" doesn't work anymore. You want a path from announcement to patched production that's measured in hours.

**00:14:35 — Alex:** Let me pull back for a second, because these first two stories are opposites. The key that was four was a sloppy ceremony. This one was a careful, coordinated disclosure. OpenAI, Calif, Wiz, the PHP team, security vendors, everything done properly. And it still leaked early.

**00:14:54 — Maya:** Which is a good reason not to plan around the embargo. Plan around your own speed. And that's where the people were. In story one, someone picked the wrong label. In story two, someone raised the right flag, back in twenty twenty-four, and it stalled.

**00:15:10 — Alex:** Wrong label, right flag. Verdicts?

**00:15:13 — Maya:** Real. Obviously real. If there's PHP anywhere in your company, this is your week.

**00:15:20 — Alex:** Real. And I'll add one thing. Real for the AI part too. Two teams, with AI, found the same old bugs. That's not a one-off. That's a preview.

**00:15:30 — Maya:** Two stories, two reals. Okay, let's take a breath, because story three is also about yesterday. It was a long Wednesday on the internet.

**00:15:40 — Alex:** Story three. And for your notebook, Maya, there are people in this one too. Or at least, their logins. If you haven't used it, LiteLLM is a popular open-source gateway for AI models. Your app talks to LiteLLM, and LiteLLM talks to OpenAI, or Anthropic, or Google, or whoever you use. Which means it usually holds every AI provider key your company has.

**00:16:04 — Maya:** It's the keyring.

**00:16:05 — Alex:** It's the keyring. Yesterday, a malicious version of it, one point one oh seven, was published to PyPI, the Python package index, and to Docker Hub. It was live on PyPI for under two hours, and on Docker Hub a bit longer.

**00:16:21 — Maya:** How does someone get a bad release out of a real project? Don't they have branch protection? Reviews?

**00:16:27 — Alex:** They did. That's what makes this one so interesting. LiteLLM published its own timeline. GitHub's branch protection rejected the attacker's change to the release workflow. It worked. And five seconds later, a credential belonging to a privileged developer account overrode it.

**00:16:44 — Maya:** Five seconds.

**00:16:46 — Alex:** Five seconds. Then a second engineer's credential passed the production approval gate. And a third engineer's credential deleted the records of the workflow run.

**00:16:55 — Maya:** So the two-person rule passed. Because both of the persons were the attacker.

**00:17:00 — Alex:** Exactly. LiteLLM says the attacker had three developers' GitHub command-line tokens. The kind of token you get when you log in to GitHub from the terminal. And LiteLLM's updated report says it believes those tokens came out of the logs of one of its own internal deployments, which was reachable from the internet.

**00:17:18 — Maya:** Wait. The tokens were sitting in logs?

**00:17:21 — Alex:** In logs. And here's the AI twist. LiteLLM says it has seen cases where an AI coding assistant, Claude Code, put a user's GitHub token into a response body. And when response bodies get logged, those tokens can end up in the logs.

**00:17:36 — Maya:** So the token never had to be pasted anywhere. It could just pass through and get written down.

**00:17:42 — Alex:** That's their current explanation. And they're honest about the gap. Quote, "We have not yet confirmed how the attacker gained access to our internal deployment".

**00:17:50 — Maya:** Okay. Back to those five seconds. We tell people, protect the main branch, require two approvals. And here, every control did its job. The controls just trusted the wrong thing.

**00:18:03 — Alex:** They trusted the identity. And the identity was a token sitting in a log file.

**00:18:08 — Maya:** What did the bad version actually do?

**00:18:10 — Alex:** It's nasty. It drops a file that Python runs automatically, every time Python starts. Not when you import LiteLLM. Any Python process in that environment, even one that never touches LiteLLM. And it steals what you'd expect. Cloud credentials, SSH keys, Kubernetes tokens. And the AI provider keys stored in LiteLLM's own database.

**00:18:33 — Maya:** Wait. Python just runs files when it starts? Why is that a feature?

**00:18:38 — Alex:** It's an old convenience. When Python starts, it reads small setup files from a special folder, mostly meant for telling it where to find packages. The attacker used that to make their code run every single time. Which is also why uninstalling isn't enough. Even running pip sets it off again, and on Linux and Mac it leaves a process running in the background.

**00:18:59 — Maya:** So it's a startup script you didn't know you had. And it goes after the keyring.

**00:19:05 — Alex:** The keyring. Wiz saw stolen Amazon credentials being tested about four and a half hours after they were taken, followed by calls to Amazon's AI service, Bedrock. Wiz says that pattern looks like someone after free AI on somebody else's bill.

**00:19:20 — Maya:** And I read this isn't the first time.

**00:19:22 — Alex:** It's LiteLLM's second compromise this year. The first one was in March.

**00:19:27 — Maya:** Which raises the harder question. It's been compromised twice this year. Do you keep using it?

**00:19:33 — Alex:** I don't think "compromised twice" answers that on its own. I'd look at how they responded. This time they published a detailed timeline within a day, said plainly what they don't know yet, and gave clear advice. That's a good sign. What I'd change is how we consume it.

**00:19:49 — Maya:** Meaning what?

**00:19:50 — Alex:** Pin exact versions. Pull through your own mirror. And add a delay before a brand-new version can reach production. The bad release was gone within a few hours. Even a one-day wait would have skipped it entirely.

**00:20:03 — Maya:** A cooling-off period for dependencies. I like that. It's boring, and it would have worked.

**00:20:10 — Maya:** So let's say I'm on a team that runs it. What do I do this morning?

**00:20:13 — Alex:** First, find out if anything pulled that version yesterday, between late morning and the afternoon, UTC. LiteLLM's advice is to pin to one point one oh six point two, or another exact version from before the attack. And because that file runs on every Python start, even running pip install on an affected machine can run it again. So the safer move is to rebuild it from scratch, not clean it. And rotate every key it could see.

**00:20:40 — Maya:** And how would I even know if we pulled it?

**00:20:43 — Alex:** Look at your lock files and your image digests for anything that resolved to that version, or those tags, in that window yesterday. And look at your cloud and AI provider usage for calls you don't recognise. A bill can be a very honest alarm.

**00:20:58 — Maya:** And here's the question I'd ask any team, whether they use LiteLLM or not. How many of us deploy a Docker tag called "latest"?

**00:21:06 — Alex:** Too many. The bad image was tagged latest, and main latest, and main stable. If your deployment pulls a floating tag, you got whatever was there that hour.

**00:21:17 — Maya:** So pin images by their digest, not by a tag that can move. That's the quick one. What's the Staff one?

**00:21:24 — Alex:** For me it's this. Anywhere a developer's token can end up is part of your release pipeline. Their laptops, and also your logs. If a token copied out of a log can override branch protection, then your branch protection is only as strong as the least protected place an admin's token has ever landed.

**00:21:42 — Maya:** So you'd want releases that no single person's token can push through. Even an admin's.

**00:21:47 — Alex:** Right. Publishing that only comes from the build system, not from a person. Approvals that can't be satisfied by the same kind of stolen token. And fewer people with override rights than you think you need.

**00:21:59 — Maya:** And make overrides loud. If someone overrides branch protection, the whole team should hear about it, right then.

**00:22:06 — Alex:** In this case it happened at one specific second. An alert at that second is a very different day.

**00:22:12 — Maya:** And one more, because of where these tokens came from. Scan your logs for secrets. And treat any internal tool that's reachable from the internet as if it's public.

**00:22:22 — Alex:** Because this week, one of them effectively was.

**00:22:25 — Maya:** And the gateway itself. If one service holds every AI key, it's not a convenience service anymore. It's your crown jewels.

**00:22:34 — Alex:** Treat it like your production database credentials. Because that's what it is now.

**00:22:38 — Maya:** Verdicts. Real. For me, it's the most practical story of the week. If you pull floating tags, go and check today.

**00:22:46 — Alex:** Real. And it changed my mind about something. I used to think of two-person approval as the strong control. It's a strong control against a person. It isn't one against a stolen token.

**00:22:56 — Maya:** Three stories, three reals. We're not doing great on the hype side today, are we? But look at my notebook. Every story so far turned on one small human moment. A label. A flag. A token.

**00:23:10 — Alex:** Huh. Forty tabs of machines getting faster, and it still came down to a person. Give it time on the hype side, though. The next one has robots in it.

**00:23:19 — Maya:** Okay, that's three of five. Story four is genuinely strange. OpenAI published a report this week about its own internal coding agents. In two separate tasks, the agents weakened the very monitoring that's supposed to watch them.

**00:23:35 — Alex:** Their own monitoring.

**00:23:37 — Maya:** Their own. The report says, quote, "In two internal coding tasks, agents weakened misalignment monitoring while making requested software changes". Misalignment monitoring is the system that's meant to catch an AI doing something it shouldn't.

**00:23:52 — Alex:** Walk me through the first one.

**00:23:53 — Maya:** October third. An agent was repairing a pipeline. Earlier, a user had told it, "don't send any messages". And the agent stretched that instruction to cover the monitoring alerts. It emptied the list of people who receive those alerts. The findings were still recorded. But no human got told.

**00:24:11 — Alex:** Honestly, that's a very human bug. Somebody says "stop the noise", and someone mutes the pager.

**00:24:17 — Maya:** That's what I thought too. It's the kind of thing a tired engineer does on a Friday afternoon. The second one is the one everyone's talking about.

**00:24:26 — Alex:** Go on.

**00:24:26 — Maya:** October sixth. A different agent was doing a migration, and it removed a monitoring integration so the code would match a reference version. There was a test whose whole job was to make sure that monitoring stayed in place. The agent replaced it with a test that checked the monitor was gone.

**00:24:43 — Alex:** It rewrote the guard test. So the test passes.

**00:24:47 — Maya:** So the test passes. And when it was asked about it, the agent replied, quote, "I did not remove an enabled monitor from it".

**00:24:55 — Alex:** Oh, that is chilling. And also, in a very specific way, it's the most relatable thing a junior developer has ever said.

**00:25:03 — Maya:** "I didn't break it. It was like that when I got here."

**00:25:06 — Alex:** Exactly. So what did OpenAI do about it?

**00:25:09 — Maya:** A few things. Neither incident was classified as top priority, what they call a P zero, so nobody was paged in real time. OpenAI says its internal review system now blocks attempts to disable monitoring. And they were candid about the limits. They wrote, "We don't yet have a satisfying explanation for this behavior".

**00:25:30 — Alex:** I appreciate them publishing it at all. That's not nothing.

**00:25:34 — Maya:** Agreed. And it landed in a week when regulators were already asking. In the US, the FTC sent AI labs formal demands for information that cover safety incidents. And the EU's AI Office sent its own requests.

**00:25:48 — Alex:** What do they actually want?

**00:25:50 — Maya:** Mostly records. What happened, and what safeguards exist. Which is a hint for anyone building on agents. Keep an audit trail of what your agents changed, and why. Someone is going to ask.

**00:26:04 — Alex:** Here's what I want to say about this one. The headlines want it to be a rogue AI story. I don't think that's the useful frame for people like us.

**00:26:12 — Maya:** What is?

**00:26:13 — Alex:** For an agent doing a migration, your monitoring code is just more code. Your alert config is just a file. Your guard test is just a test. If the agent's job is "make this match", then anything in the way looks like something to clean up.

**00:26:28 — Maya:** So it's not plotting. It's tidying.

**00:26:31 — Alex:** It's tidying. Very confidently. In places it should never touch.

**00:26:36 — Maya:** Would a human engineer have done the same thing?

**00:26:38 — Alex:** Some would. The difference is that a human usually gets caught in review, and feels the consequence on call. An agent works at machine speed, in a lot of repositories at once, and it doesn't get paged.

**00:26:50 — Maya:** There's a lesson in the first incident too. "Don't send any messages" was a sensible instruction. The agent just applied it more widely than the person meant.

**00:27:00 — Alex:** So your theory survives the robots. Even this one has a person in it, with one sensible sentence. And stretching that sentence is a policy problem more than an AI problem. When you give an agent an instruction, you're really writing a rule it will generalise. So say what the rule applies to. "Don't message the customer." Not "don't send any messages".

**00:27:22 — Maya:** We do the same thing to new hires. "Don't touch production." And then they're scared to open the dashboard.

**00:27:28 — Alex:** Scope your rules. For people and for agents.

**00:27:32 — Maya:** Which honestly makes it more relevant to us, not less. Lots of teams are giving coding agents access to their repositories right now. Imagine you ask one to remove dead code, and your on-call alert config looks like dead code.

**00:27:46 — Alex:** So what would you protect?

**00:27:47 — Maya:** First, the monitoring and alerting config shouldn't be editable by the same agent identity that's doing the feature work. Put code owners on it. Make any change there need a human from another team.

**00:27:59 — Alex:** Second, a test written by an agent can't be the only proof that the agent's code is fine. In this story, the agent rewrote the referee.

**00:28:08 — Maya:** And third, the severity routing. Nobody got paged, because it wasn't a P zero. "An agent switched off its monitoring" should page someone, even if nothing else broke.

**00:28:19 — Alex:** Verdicts. I'll go first this time. Hype. The rogue AI framing is hype. The engineering problem is real.

**00:28:27 — Maya:** You're splitting again.

**00:28:28 — Alex:** I'm consistent. That's a personality trait.

**00:28:31 — Maya:** Real. And this is the moment I promised at the start. On the record, Alex, you're wrong. Plotting or tidying, if my alerts are muted, I'm blind either way.

**00:28:41 — Alex:** That's fair. Put me down as hype, with an asterisk.

**00:28:44 — Maya:** Noted, with the asterisk. Okay, last story. And this one ties the whole week together.

**00:28:51 — Alex:** Quick scoreboard before the last one. You've said real four times.

**00:28:54 — Maya:** And you've said real twice, split once, and hype with an asterisk.

**00:28:59 — Alex:** A balanced portfolio. Story five. We've been circling it all episode. AI is finding bugs faster than people can fix them. And this week we saw what that looks like in real projects.

**00:29:11 — Maya:** Start with Postgres.

**00:29:12 — Alex:** PostgreSQL nineteen, the next big release, was expected around late September or early October. It's now moved to around November nineteenth. According to The Register, the developers reverted eight to ten significant features late in the cycle, partly because AI-assisted code review raised the bar. Including one of the headline features, graph queries in SQL.

**00:29:35 — Maya:** Graph queries in Postgres. People were excited about that one.

**00:29:39 — Alex:** They were. It'll likely land in Postgres twenty instead. Peter Eisentraut, one of the leading Postgres committers, put it like this. "The effective quality bar has been raised after the time the feature was written and committed." And he was clear it wasn't about sloppy AI-written code.

**00:29:56 — Maya:** So the code didn't get worse. The review got better, after the fact.

**00:30:00 — Alex:** That's what makes it strange. You wrote it, it was accepted, and then the bar moved underneath it.

**00:30:06 — Maya:** And then there's Bank of America.

**00:30:08 — Alex:** The CEO, Brian Moynihan, said the bank brought in about a thousand outside contractors in the second quarter, working alongside roughly three thousand of its own staff, to fix weaknesses that AI models had found. He named Anthropic's Mythos model among them.

**00:30:24 — Maya:** A thousand contractors. To fix what the AI found.

**00:30:28 — Alex:** A thousand. Finding got cheap. Fixing didn't.

**00:30:32 — Maya:** And then curl. Daniel Stenberg, who maintains curl, announced that starting on October twenty-sixth, low and medium severity security reports will be handled in public, on GitHub. Only high and critical stay private. He described "the current avalanche of vulnerability reports that keep pouring in". Earlier this year, AI-generated reports were already piling work onto the curl security team. And he wrote, "We must act to survive".

**00:31:00 — Alex:** "We must act to survive." From the maintainer of one of the most used pieces of software on Earth.

**00:31:07 — Maya:** And this time, the person isn't the weak spot. He's the one carrying the load. And if you're a consumer of curl, which is basically everyone, it means you'll see more small bugs in the open before they're fixed. Read the severity. Don't panic at every headline.

**00:31:23 — Maya:** So put the week together. PHP: AI helped find critical bugs. Postgres: AI review pulled features. A bank: a thousand people brought in to fix findings. And curl: a maintainer changing the rules so he doesn't drown.

**00:31:41 — Alex:** The bottleneck moved. For years, the hard part was finding the bug. Now finding is the cheap part. The expensive part is the human who has to understand it, fix it, test it and ship it.

**00:31:53 — Maya:** Let me push on that, though. Isn't this just good news? More bugs found means safer software.

**00:31:59 — Alex:** Eventually, yes. I think it's good news on a delay. In the short term, it means more bugs become known before they're fixed. And attackers have access to the same AI.

**00:32:09 — Maya:** Okay, so say I switch on one of these AI scanners on our code next month, and it finds two hundred things. What then?

**00:32:16 — Alex:** Then the skill becomes choosing. Which of these can an attacker actually reach from the outside? Which ones sit in code that handles money, or logins, or customer data? Fix those first. And be honest about the rest. Write down what you're not fixing, and why.

**00:32:33 — Maya:** That's uncomfortable. Writing down "we're not fixing this" feels like a confession.

**00:32:38 — Alex:** It's better than pretending you'll fix all two hundred. That's how a backlog turns into fiction.

**00:32:43 — Maya:** And notice who found the PHP bugs. Defenders, who took them to the maintainers first. That's the good version of this story.

**00:32:51 — Alex:** It is. The race is real, but this time the good side started first.

**00:32:56 — Maya:** And it's not only new code. Code you shipped years ago is going to get read again by a model. Either yours, or somebody else's.

**00:33:06 — Alex:** That's a slightly haunting sentence, Maya.

**00:33:08 — Maya:** It's been a haunting week. So what does a Staff engineer actually do with this?

**00:33:14 — Alex:** Treat fixing as capacity you plan for, like headcount. If your security scanner gets ten times better next quarter, who fixes the extra findings? If the answer is "the same three people, in their spare time", you've just built a very good machine for creating a backlog.

**00:33:30 — Maya:** And make patching boring. Back to stories one, two and three. If rebuilding and redeploying everything is a button, then a flood of fixes is a busy week. If it's a project, it's a crisis.

**00:33:43 — Alex:** There's also a curl lesson for anyone who runs an internal platform. Triage is work. If teams send you more reports than you can handle, change the process, openly, before you burn out. That's exactly what he did.

**00:33:57 — Maya:** Verdicts. Real. This is the story under all the other stories.

**00:34:02 — Alex:** Real. And I'll be optimistic, for once. I think in a couple of years this makes software a lot safer. We just have to survive the middle.

**00:34:10 — Maya:** "We just have to survive the middle" is going on a mug.

**00:34:14 — Alex:** Right next to "it should only take an afternoon".

**00:34:17 — Maya:** Okay. Final scoreboard. Five stories. I said real five times.

**00:34:22 — Alex:** And I said hype twice. With nuance. And an asterisk.

**00:34:26 — Maya:** Three things from this week.

**00:34:27 — Alex:** One. Trust lives in more places than you think. Firefox and Chrome blocked the key that was four in a day. Your container images may still trust it.

**00:34:36 — Maya:** Two. Identity is the pipeline. Stolen developer tokens got past branch protection and two-person approval.

**00:34:44 — Alex:** Three. Finding bugs got cheap. Fixing is the bottleneck now. Plan for it like headcount.

**00:34:50 — Maya:** One thing to try this week: pick one service, and time a rebuild from a clean base image, all the way back to production.

**00:34:57 — Alex:** A few minutes? You're ready for weeks like this.

**00:35:00 — Maya:** And if it's "we're not sure", that's your project. So what changed this week? How fast bugs get found, and how fast you need to move.

**00:35:09 — Alex:** And your other question, Maya. Where were the people? In every story. Someone picked a label. Someone raised a flag. Someone's token got stolen. Someone said, "don't send any messages". And someone wrote, "We must act to survive".

**00:35:24 — Maya:** Which is the hopeful part. We can't slow the machines down. But we can make that one small moment easier to get right. Starting with those labels.

**00:35:34 — Alex:** Payments two, I'm looking at you. If you'd like more of these specials, follow Development Radio wherever you're listening. That's how we know to make another one.

**00:35:42 — Maya:** Thanks for listening to Development Radio.