Ship It Weekly Host Commentaries

For this episode, the thing that kept showing up was not really “AI” by itself.

It was responsibility.

More specifically, what happens when companies roll out a new interface, a new abstraction, or a new “easy path,” and then quietly hand platform teams all the responsibility that comes with it.

That’s what tied these stories together for me.

McKinsey had to publicly deal with a vulnerability in Lilli, which is useful not because it turned into some huge apocalyptic breach story, but because it reminds people that internal AI tools are still real systems. They may look friendly. They may be framed like helpers. But once they can touch company knowledge, influence decisions, or sit in the middle of a workflow people trust, they stop being side tools. They become part of the operating surface.

And that means all the old questions come right back.

Who can access it.
What can it read.
What can it write.
What does it trust.
What gets logged.
What happens when somebody uses it in a way nobody really modeled.

That is the part people keep wanting to skip.

Everybody wants the new interface. Very few people want the old responsibilities that come with it.

The Kafka story hit a different version of the same theme.

Diskless topics are interesting because they feel like architecture honesty. Not hype. Not branding. Just a pretty direct acknowledgment that cloud economics eventually force you to revisit assumptions that used to feel settled. If durable local storage and broker-led replication were the obvious center of gravity before, maybe they are not the obvious center of gravity now. That is a much more useful kind of story to me than most “future of AI” noise, because it is really about something deeper: when the environment changes enough, old architecture starts charging rent.

And a lot of teams are probably living that right now, even outside Kafka.

You see it when the old design still technically works, but it works in a way that is more expensive, more awkward, or more fragile than anybody wants to admit. At some point, tuning stops being the answer. The answer becomes rethinking what the system is centered around in the first place.

Then there’s Google closing the Wiz acquisition, which to me reads less like a flashy M&A story and more like an admission about where the cloud fight actually is now.

The fight is not just compute. It is not just managed services. It is not just who has the nicest product page or the most polished launch event. It is posture. Visibility. Exposure. Identity. Policy. Security as part of the actual platform choice.

That feels obvious if you live in this space, but it is still worth saying out loud because companies still act like cloud strategy and security strategy are two separate conversations. I buy that less and less. Not when environments are this messy. Not when AI is adding new surfaces. Not when half the real work is figuring out what is running where, who can touch it, and what your blast radius looks like when somebody gets it wrong.

The AWS Copilot story is kind of the same lesson again, just in a more familiar cloud-ops form.

The paved road moved.

That’s really the story.

And platform teams know exactly what that means. It means the thing that felt like the safe, vendor-approved path now has an off-ramp. It means migration work. Retraining. Documentation churn. Re-explaining choices to teams that thought the answer was already settled. It means carrying the cost of somebody else’s product direction.

That is why I keep coming back to the idea that convenience in cloud is borrowed.

Sometimes borrowing it is absolutely worth it. I am not against paved roads. Most teams should probably use more of them, not less. But the tradeoff is always there. When the road changes, you move too. And if you have not thought about the exit story in advance, the migration always feels more annoying than it should.

Then the Kubernetes AI Gateway Working Group rounds the whole episode out in a way I really like, because it cuts through a lot of the dumbest AI discourse.

The interesting question is not “do you believe in AI” or “what model is best this week.”

The interesting question is what happens when AI traffic becomes normal platform traffic.

Because once that happens, the conversation gets a lot more real. Now it is rate limiting. Access control. Payload inspection. Egress policy. Caching. Guardrails. Prompt injection defenses. Logging. Routing. Normal boring platform words. Which is exactly why I like the story. It is a sign that the industry is moving from novelty into operations.

And that is usually where the truth shows up.

If I had to boil the whole episode down, I think it comes back to this:

The new interface does not remove the old responsibilities.

That is true for internal AI tools.
It is true for cloud architecture.
It is true for security acquisitions.
It is true for vendor paved roads.
And it is definitely true for AI-shaped traffic once it starts touching real systems.

There’s always a shiny version of the story companies want to tell.

Smarter tools.
Faster delivery.
Simpler workflows.
Better leverage.
A more intelligent future.

And sure, some of that is real.

But the operator version of the story always lands a little differently.

What are the trust boundaries.
What gets logged.
What is actually enforced.
How clean is rollback.
What happens when the vendor changes direction.
What assumptions are now too expensive to keep pretending are normal.
Who owns the control plane after all this stuff hardens into real production dependency.

That’s where this episode lived for me.

Not in the hype.
Not in the demo.
Not in whether the new thing sounds cool.

More in the handoff point where new capability turns into somebody else’s operational burden.

And most of the time, that somebody is us.

For this episode, the theme that kept showing up was pretty simple: AI is crossing out of the “tooling” bucket and into the parts of the stack that change how companies operate, how platforms fail, and how trust actually gets enforced.

Not just code suggestions. Not just faster PRs. Not just nicer demos.

Now it’s showing up in layoffs, org redesign, agent identity, security boundaries, and platform instability. Block tied a major workforce reset to “intelligence tools.” Atlassian said AI is changing the mix of skills and roles it needs. Meta bought Moltbook, which is basically a weird little lab experiment for agent-to-agent behavior that already came with a security stain on it. And GitHub had to come out and say, pretty directly, that they have not met their own availability standards lately.

That’s why I don’t think this episode is really “about AI” in the lazy sense.

It’s about what happens when AI stops being a side tool and starts becoming part of the operating model.

The Block story is the clearest example. In the shareholder letter, Jack Dorsey said “intelligence tools have changed what it means to build and run a company,” and argued that a significantly smaller team could do more and do it better. But the follow-up reporting immediately made the story messier, pointing to other pressures too, including crypto weakness, overstaffing, and stock pressure. That gap is the interesting part. Not whether AI helps, because obviously it does in some contexts. The interesting part is how fast “AI” is becoming a clean explanation for decisions that are also about cost, structure, expectations, and management philosophy.

And Atlassian matters because it makes Block feel less isolated.

Their March 11 update was explicit: about 10% of the company, around 1,600 people, while self-funding more investment in AI and enterprise sales and reorganizing to move faster. They also said, pretty plainly, that while their approach is not “AI replaces people,” it would be disingenuous to pretend AI doesn’t change the mix of skills needed or the number of roles required in certain areas. That’s a very different tone than Block, but it lands in a similar place. AI is no longer just being sold as leverage. It is being used as staffing logic.

From the DevOps and SRE seat, that creates a very practical question.

If leadership is going to claim more output from fewer people, what exactly is scaling the safety net?

Because generated output scales fast. Human review, operational context, on-call coverage, and rollback discipline usually do not. That part is my inference, obviously, but it’s the inference these stories keep pushing me toward. If AI becomes the reason to cut faster than you improve your controls, then the real result is not “transformation.” It’s just a thinner human layer sitting behind a more aggressive delivery system.

The Moltbook story is the other side of this.

On paper it sounds goofy. Meta bought a social network for AI agents. Fine. Weird internet headline. But Reuters is clear that this is not just a joke acquisition. Meta is bringing the founders into Superintelligence Labs, and the whole thing points at where the agent race is headed. At the same time, Reuters also notes that Moltbook’s rise came with security problems, including a flaw that exposed private messages, thousands of emails, and more than a million credentials before Wiz reported it and the issue was fixed. That’s why the story matters. Not because “robots posting on a forum” is inherently important, but because it previews the trust problem. Once agents start acting on behalf of users, teams, or companies, identity, permissioning, auditability, and blast radius stop being product details and start becoming platform concerns.

That’s also why the AWS Bedrock AgentCore Policy announcement was a good lightning-round item.

It is basically AWS saying, out loud, that agent-tool interactions need centralized, fine-grained controls that operate outside the agent code itself. Security, compliance, and operations teams need to define what agents are allowed to do without rewriting the agent every time. That feels like the grown-up version of this whole conversation. Not “trust the prompt.” Not “the model seemed fine in a demo.” Policy, validation, interception, governance. The same old boring words that always matter once software starts touching real systems.

Then there’s GitHub, which was honestly one of the most useful stories in the bunch because it brought the whole episode back to reality.

GitHub said the most significant incidents happened on February 2, February 9, and March 5, and tied the instability to rapid load growth, architectural coupling, and a weak ability to shed load from misbehaving clients. On the Actions side, one outage came from a telemetry gap that caused security policies to hit key internal storage accounts and block VM metadata access. Another came from a Redis failover that left a cluster with no writable primary. That is just real platform engineering pain. No fluff. No fake confidence. Just growth, dependency coupling, failover assumptions, and systems that turned out to be less isolated than they needed to be.

And that part connects directly to stuff we’ve already talked about on the show.

We were already on the Block layoff angle in a previous week’s episode, Episode 24Mar 6, 2026⏱️ 18:20AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code SecurityEpisode: AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code Security.

And on the GitHub outage side, we’ve hit that theme more than once already in Episode 1Nov 20, 2025⏱️ 12:54Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub OutagesEpisode: Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub Outages and Episode 19Feb 12, 2026⏱️ 15:49When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creepEpisode: When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creep. So this episode is less a brand-new theme and more the next step in the same pattern: AI is changing the pressure on the system, but the failures still show up in trust boundaries, control planes, and operational weak points.

That’s why I liked ending the main stories with Anthropic and Mozilla.

Because it keeps the episode from collapsing into “AI hype bad” or “AI layoffs bad” and pretending that’s the whole picture. Anthropic said Claude Opus 4.6 found 22 Firefox vulnerabilities in two weeks, 14 of them high severity, and Mozilla shipped fixes in Firefox 148. That’s a much more grounded version of the value story. Bug hunting, security review, broader coverage, more signal for humans to validate and act on. That feels way more real to me right now than the giant hand-wave of “smaller teams can just do more now, trust us.”

If I had to boil the whole thing down, I think the real divide is this:

There’s the AI story companies want to tell, and then there’s the AI story operators actually have to live with.

The company story is leverage, speed, restructuring, transformation, and the future.

The operator story is guardrails, permissions, blast radius, audit trails, outage recovery, and who still has to wake up when the system behaves in a way nobody modeled.

That’s where this episode lived for me.

Not “is AI good or bad.”

More like: where is it actually useful, where is it being used as cover language, and what new control points do platform teams need to care about before the hype gets translated into production reality?

Past Ship It Weekly references

Block layoff episode:
Episode 24Mar 6, 2026⏱️ 18:20AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code SecurityEpisode: AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code Security

GitHub outages episodes:
Episode 1Nov 20, 2025⏱️ 12:54Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub OutagesEpisode: Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub Outages
Episode 19Feb 12, 2026⏱️ 15:49When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creepEpisode: When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creep

Source links mentioned

Block Q4 2025 shareholder letter
What was really behind Jack Dorsey laying off nearly half of Block’s staff?
An important update on our team - Atlassian
Meta acquires AI agent social network Moltbook - Reuters
Wiz on the Moltbook exposure
Addressing GitHub’s recent availability issues - GitHub
Partnering with Mozilla to improve Firefox’s security - Anthropic
Policy in Amazon Bedrock AgentCore is now generally available - AWS

For this Conversations episode, I wanted to stay anchored on something that sounds simple, but a lot of people still get wrong when they’re trying to break into cloud or DevOps.

The answer usually is not “learn more tools.”

It’s focus.

Yvonne Young is great for this topic because she is not coming at it from the usual hype angle. She is not telling people to go collect every cert, every platform, and every buzzword. She keeps bringing it back to a much more grounded idea: pick a direction, learn the basics, stay consistent, and understand the business problem behind the tool. Without that, people wind up busy, but not actually job ready.

What I liked most is that her framework is not complicated.

First, figure out what you actually want to do. Security, cloud, infrastructure, databases, SRE, whatever it is. But pick something. Her point is that a lot of juniors get stuck because they try to learn everything at once, and then there is no path, no depth, and no real momentum.

Then build the foundation. In her view, Linux is still the starting point because so much of modern infrastructure still sits on top of it. Not “become a wizard overnight.” Just be functional. Know the basics. Move files, check disk, inspect ports, troubleshoot a service, use the help system, and get comfortable enough that you are not totally lost the second something breaks. That part really matters because it is the layer underneath a lot of the cloud and DevOps tooling people want to jump to first.

Then there is the consistency piece, which honestly is probably the most useful part for people listening to this episode.

Yvonne talks about how skills fade if you do a big cram session, then disappear for a week. Her point is that retention usually comes from short, repeatable reps. Thirty minutes. Forty-five minutes. A quick checklist. Brush up before interviews. Keep the basics fresh. That is a way more realistic model than pretending everyone is going to sit down for three-hour deep work sessions every night after work.

I also liked how she framed “job ready,” because I think a lot of people hear that phrase and imagine they are supposed to know everything.

Her take is almost the opposite.

Know the basics. Be ready for both the technical side and the behavioral side. Do the research on the company. And if you get asked something you do not know, do not panic and fake it. Show how you would think through it. Show how you would find the answer on the job. That is a much healthier and much more realistic definition than pretending readiness means total mastery.

Another thing that came through clearly is that she does not really teach tools in isolation. She teaches problems first.

That showed up in the way she talked about cloud adoption, security, and Vault. Not “learn Vault because Vault is cool.” More like, “understand secret sprawl, understand why companies care about centralized access and rotation, and then the tool makes sense in context.” Same with cloud. The point is not memorizing product names. The point is understanding why a business wants speed, efficiency, scale, or better security in the first place.

That part matters because it changes how people interview too.

If you only talk about tools, you sound like you memorized a stack. If you talk about the business problem the tool solves, you sound like someone who understands the bigger picture. And that is a much better signal, especially for people trying to get that first real break.

The other thread running through this whole conversation is mentorship.

Yvonne keeps coming back to the idea that without a mentor or a community, people lose time wandering. And honestly, that felt true not just for juniors, but for companies too. Because later in the episode she flips it around and talks about what seniors should do better: better onboarding, being available, and not throwing people into sink-or-swim situations with no lifeline. That part hit, because most of us have seen exactly that.

So if you are listening to this episode and you want one concrete takeaway, it is this:

Do not confuse motion with progress.

You do not need every tool.
You do not need every certification.
You do not need to know everything.

You need focus, fundamentals, consistency, and enough business context to understand why the work matters.

That is the real path in.

For this episode, the theme that kept showing up was control planes under pressure.

Not just the obvious ones like Kubernetes or CI/CD.

But the broader set of systems we now depend on to run infrastructure: GitOps controllers, developer workspaces, agent tooling, and even the geopolitical reality behind cloud regions and AI supply chains.

A lot of the stories this week look unrelated on the surface.

An AWS region dealing with infrastructure disruptions in the Middle East.
A GitOps migration story from ArgoCD to Flux.
CI pipelines being actively hunted by automated attackers.
Prompt injection turning into token theft in developer environments.
Companies restructuring around “AI productivity.”
And security tooling itself becoming AI-driven.

But if you zoom out a little, they’re all variations of the same underlying shift.

The automation layer has become the real control plane of modern infrastructure.

And once that happens, two things follow very quickly.

First, attackers target the control plane.

Second, organizations try to scale it faster than their guardrails.

You can see the first part clearly in the GitHub Actions attacks that StepSecurity documented.

This wasn’t someone finding a bug in an application.

It was an automated campaign targeting CI workflows across open source repositories.

The attacker isn’t interested in the application logic.
They want the release mechanism.

If you compromise CI, you don’t need a vulnerability in the app.
You can modify the artifacts, steal tokens, publish malicious packages, or pivot into infrastructure.

That’s why the Trivy maintainers’ response was interesting. They quickly published details about the attack vector and the workflow that was responsible.

That’s the right instinct.

CI incidents are supply chain incidents now.

---

StepSecurity hackerbot-claw analysis
https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation

Trivy incident discussion
https://github.com/aquasecurity/trivy/discussions/10265

The second theme was control planes that fail in subtle ways.

The ArgoCD story is a good example.

GitOps sounds beautiful in theory.

Git is the source of truth.
The cluster reconciles to match it.
Everything is declarative.

But operationally, the controller itself becomes part of the reliability story.

If it gets stuck on a failed state, it can block the path to recovery.

And the CRD ordering problem mentioned in that migration write-up is something many teams eventually encounter.

It’s not a catastrophic bug.
It’s a behavior mismatch between how engineers expect reconciliation to work and how the system actually behaves.

That’s the dangerous category of failure.

Because it usually shows up during an incident, when you’re trying to deploy the fix.

Migration write-up
https://hai.wxs.ro/migrations/argocd-to-flux/

Another version of this control plane expansion is happening in developer environments.

The RoguePilot research is a good example of that.

A malicious GitHub issue can contain instructions that get interpreted when a developer launches a Codespace.

That’s essentially prompt injection as a supply chain vector.

And the problem isn’t just the model.

It’s the environment.

If the agent reading that issue has access to a GITHUB_TOKEN, or can run commands, or can open pull requests, the attacker has a pathway into real operations.

---

RoguePilot overview
https://thehackernews.com/2026/02/roguepilot-flaw-in-github-codespaces.html

Original research
https://orca.security/resources/blog/roguepilot-github-copilot-vulnerability/

There’s also a bigger conversation happening about agent boundaries.

Vercel published a good write-up on this recently.

The core idea is simple: most agents today run generated code with the same privileges as the developer or system running them.

Which means the real question becomes:

Where is the trust boundary?

Is the agent allowed to read untrusted content?
Is it allowed to execute commands?
Does it have access to secrets?

Those are the same questions we’ve been asking about CI systems for years.

We’re just asking them again for AI tools.

---

Security boundaries in agentic architectures
https://vercel.com/blog/security-boundaries-in-agentic-architectures

The AWS regional disruption story fits into this theme in a different way.

It’s a reminder that cloud infrastructure still exists in the physical world.

Power events, connectivity problems, geopolitical instability — all of these can show up as “cloud issues.”

And that’s why the phrase multi-AZ is not multi-region matters.

Availability zones protect you from localized failures.

Regions protect you from systemic ones.

And organizations that treat those as interchangeable eventually discover the difference during a very long outage.

---

Reuters coverage
https://www.reuters.com/world/middle-east/amazon-cloud-unit-flags-issues-bahrain-uae-data-centers-amid-iran-strikes-2026-03-02/

Then there’s the organizational side of all this.

The Block layoffs framed as an “AI remake” are part of a pattern we’re seeing across the industry.

Companies expect automation and AI to increase productivity.

And in many cases, they’re right.

But there’s a hidden constraint.

Automation scales faster than human oversight.

That idea has been explored really well by Uwe Friedrichsen in his Ironies of Automation series.

The key insight is that automation concentrates responsibility rather than eliminating it.

Systems get faster.
Systems get more capable.
But humans do not scale at the same rate.

Which means failures propagate faster than organizations can understand them.

---

Ironies of Automation series
https://www.ufried.com/blog/ironies_of_automation/

Ironies of AI (Part 2)
https://www.ufried.com/blog/ironies_of_ai_2/

We actually touched on that idea in an earlier Ship It Weekly episode when talking about control planes and automated RCA.

That conversation still applies here.

Earlier episode reference
Episode 10Jan 2, 2026⏱️ 17:45Fail Small, IaC Control Planes, and Automated RCAEpisode: Fail Small, IaC Control Planes, and Automated RCA

One more interesting development this week was Anthropic announcing Claude Code Security.

Tools like this aim to scan codebases for vulnerabilities and propose fixes automatically.

In theory, that’s extremely powerful.

Security teams spend huge amounts of time triaging issues that developers never get around to fixing.

If AI can propose safe patches and reduce that backlog, that’s a real win.

But it also raises the same operational question we’ve been talking about throughout this episode.

Is the tool suggesting changes, or making them autonomously?

Because the moment a system can modify code, open pull requests, or deploy changes, it’s no longer just a scanner.

It’s part of the control plane.

---

Claude Code Security
https://www.anthropic.com/news/claude-code-security

Finally, a quick note on the AI supply chain angle we mentioned in the lightning round.

DeepSeek reportedly withheld access to a new model from certain U.S. chipmakers while making it available earlier to domestic firms.

This is another reminder that AI infrastructure is now intertwined with geopolitics and hardware supply chains.

Which means “what model can we run” may become just as much a business or regulatory question as a technical one.

---

DeepSeek coverage
https://www.reuters.com/world/china/deepseek-withholds-latest-ai-model-us-chipmakers-including-nvidia-sources-say-2026-02-25/

If you step back from all of these stories, the through-line becomes pretty clear.

Infrastructure reliability used to be mostly about applications and servers.

Now it’s about the systems that operate the systems.

CI pipelines
GitOps controllers
Developer environments
Agent frameworks
Security automation
Cloud regions

These are the new control planes.

And the work of DevOps and SRE increasingly revolves around making sure those layers are safe, observable, and recoverable when something inevitably goes wrong.

That’s all for this week’s commentary.

If you want the full breakdown of the stories discussed in the episode, check the show notes and episode page.

More episodes are available at
https://shipitweekly.fm

And if this show has been useful, consider sharing it with a teammate or another engineer who’s living in the same automation-heavy world we all are right now.

Thanks for listening. See you next week.

For this episode, I wanted to anchor on something I think every ops team learns the hard way.

The incidents that hurt the most are rarely the big obvious deploys.

It’s the background systems. The reconcilers. The cleanup jobs. The “this should be safe because it’s routine” automation.

Because those jobs are usually touching shared truth.

Routing state. Prefix state. Permissions. Database statistics. The stuff everything else quietly depends on.

And when that shared truth shifts under you, you don’t just get a bug. You get reachability problems. You get cascading retries. You get queueing. You get “everything is up but nothing works.”

Cloudflare BYOIP is the cleanest example this week.

This wasn’t “somebody fat-fingered BGP.” It was a buggy cleanup sub-task that queried the Addressing API wrong and ended up withdrawing about 1,100 BYOIP prefixes before they could revert the change. Some customers could re-advertise their prefixes from the dashboard, but the real work was restoring prefix configuration state back to normal. 

That’s the lesson. If you have automation that can touch reachability, it is production control plane. Treat it like prod deploy tooling, not like “just a job.” Put caps on it. Put canaries on it. Put a circuit breaker on it. And most importantly, build rollback that does not require tribal knowledge at 3am.

Cloudflare outage postmortem

https://blog.cloudflare.com/cloudflare-outage-february-20-2026

Next, Clerk’s postmortem is the same theme, just inside Postgres instead of BGP.

Auto analyze ran, statistics shifted, a query plan flipped into something awful, and suddenly the system is shedding load so hard that most traffic is coming back 429 without even being handled. They fixed it by forcing ANALYZE again, and then they got really explicit about hardening failover so it can trigger on “any failure at origin,” not just “Postgres is down.” 

This is why I keep saying “degraded is harder than down.”

Most teams have alarms for dead things. A lot fewer teams have alarms for “same query, different plan” or “latency is spiking but nothing is technically failing.” That gap is where the really ugly incidents live.

Clerk outage postmortem

https://clerk.com/blog/2026-02-19-system-outage-postmortem

And then you’ve got the AWS Kiro story, which is going to get summarized everywhere as “AI took down AWS.”

AWS’s response is basically: no, it was misconfigured access controls, and they added safeguards like mandatory peer review for production access. Reuters covered the reporting around it, and AWS published their own statement pushing back. 

Here’s my take.

Whether it was an agent or a bash script, it’s the same root problem: a tool got permissions it shouldn’t have had.

So the practical move is boring, but it’s the whole game.

Separate propose from execute.

Let tools draft plans, diffs, PRs, and recommendations all day long.

But when it comes to destructive actions, make that path intentionally gated, intentionally scoped, and painfully auditable.

AWS response on Kiro

https://www.aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro

AWS outage reporting (Reuters)

https://www.reuters.com/business/retail-consumer/amazons-cloud-unit-hit-by-least-two-outages-involving-ai-tools-ft-says-2026-02-20

Quick platform note before we move on.

AWS open-sourced the EKS Node Monitoring Agent, which is aimed at detecting node-level issues and surfacing them as signals EKS can act on, including automated node repair paths. This is one of those “make the pager quieter” features that I actually like seeing. 

EKS Node Monitoring Agent

https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-eks-node-monitoring-agent-open-source

Lightning round quick thoughts.

Grafana has a high severity issue where a user with permission management rights on one dashboard could modify permissions on other dashboards. If you run Grafana in a shared org and you’ve got a lot of teams in there, that’s a “patch it” item. 

https://grafana.com/security/security-advisories/cve-2026-21721

AWS published a bulletin on runc CVEs affecting container runtime behavior when launching new containers. The evergreen reminder is still true: containers are not a security boundary, and runtime bugs turn into host risk depending on how you’re running workloads. 

https://aws.amazon.com/security/security-bulletins/rss/aws-2025-024

GitLab shipped patch releases 18.6.1, 18.5.3, 18.4.5. If you self-host GitLab, you already know the rule. Staying behind becomes “we’ll do it later” until it becomes a weekend incident. 

https://about.gitlab.com/releases/2025/11/26/patch-release-gitlab-18-6-1-released

And Atlassian’s February bulletin is the monthly reminder that on-prem Data Center products are a patch treadmill. They call out a pile of high severity vulns and critical severity ones fixed in newer versions. 

https://confluence.atlassian.com/security/security-bulletin-february-17-2026-1722256046.html

Human closer.

ACM Queue ran a piece called “SRE Is Anti-Transactional,” and it’s basically describing the exact emotional arc behind all of these stories.

SRE and platform teams aren’t trying to dodge work.

They’re trying to move the org away from manual, transactional toil, toward systems that do safe work by default, and only involve humans for exceptions.

But this week is a reminder that you don’t get autonomy by giving tools more power.

You get autonomy by engineering the guardrails first, then widening the lane over time. 

SRE Is Anti-Transactional

https://queue.acm.org/detail.cfm?id=3773094

That ties the whole episode together.

Cloudflare automated cleanup touching routing state.

Clerk got hit by a “system is up but behavior changed” database failure mode.

AWS is reinforcing that permissions are still the sharp edge, no matter what tool is holding the knife.

Defaults shift. Background systems become dependencies. Guardrails decide whether it’s a story you learn from, or a story you apologize for.

Full show notes are on shipitweekly.fm. The weekly curated brief is on oncallbrief.com.

And if you got value out of this episode, follow or subscribe wherever you listen. Helps a ton.