Coinbase Outage, Meta AI Account Recovery, AWS AgentCore Code Injection, Apigee Tenant Isolation, and the Glue That Breaks Production

An AWS data hall overheats. A single availability zone goes dark. And Coinbase spends hours recovering systems that were not as failure-independent as everyone hoped. Meta's AI support tooling becomes part of an Instagram account recovery path.

And suddenly the chatbot is not just helping customers. It is touching identity. AWS has another agent tooling bug, this time in AgentCore CLI. where imported agent metadata could become generated Python code.

And Google Cloud disclosed an Apigee cross-tenant issue, which is exactly the kind of phrase that makes cloud engineers sit up a little straighter. The theme this week is simple. The risky part of modern infrastructure is not always the big obvious production system. Sometimes it is the glue, the recovery path, the support workflow, the generated file.

the tenant boundary. The thing everybody depends on, but nobody quite treats like production until it breaks. I'm Brian Teller from Teller's Tech, and this is Ship It Weekly. Welcome back to Ship It Weekly, the show where we look at the DevOps, SRE, cloud, platform, and security stories that actually matter when you are the person who eventually has to keep the thing running.

This week, we're starting with Coinbase's May 7th outage postmortem. Then we'll talk about Meta's AI support incident, where attackers reportedly hijacked Instagram accounts through an AI-assisted recovery flow. After that, we'll get into AWS AgentCore CLI CVE-2026-11393, where collaborator metadata could break out into generated Python code. Then we'll talk about Google Cloud Apigee and a cross -tenant vulnerability, because tenant isolation is one of those cloud promises you only think about when it fails.

In the lightning round, we'll hit Cloudflare threat intelligence in WAF rules, AWS Lambda tenant isolation with event source mappings, the next generation of OpenSearch Serverless, and GitHub Enterprise Managed Users IP allow list coverage. So let's get into it. First up, Coinbase published a postmortem for its May 7th outage. And this one is worth reading if you work anywhere near SRE, platform, cloud, infrastructure, Kafka, financial systems, or any system where people say we're multi-AZ and then everyone quietly hopes that means what they think it means.

Coinbase says that trading, deposits, withdrawals, and most customer -facing services were unavailable or degraded for roughly eight hours. Full recovery took even longer. The initiating event was physical. Multiple chiller units failed in a single AWS us-east-1 data hall, specifically availability zone use1-az4.

That cooling issue triggered a thermal safety shutdown of affected racks, taking EC2 instances and EBS volumes in that building offline. That is the part that looks like a classic cloud outage story. Something physical breaks inside a data center and cloud resources disappear. But the more useful lesson is what happened next.

Because most of us already know that an availability zone can fail. At least in theory. We have all seen the diagram. Three boxes, three AZs, nice clean arrows, everybody nods.

Then a real failure happens, and the system has to prove whether those boxes were architecture or just decoration. For Coinbase, one major issue was that the matching engine was tied closely to the failed zone. And this is where the nuance matters. Low latency systems often make tradeoffs that normal apps do not.

If you need extremely tight latency, deterministic behavior, and careful state handling, you may choose a design that favors performance over easy failover. And that is not automatically irresponsible. But it does mean the recovery path has to be real, not theoretical. Not we documented it once.

Real. Tested. Owned. Practiced.

Known by more than one person. The other big lesson is state. Coinbase called out delays around managed Kafka recovery. And that is extremely relatable.

During an outage, stateless compute is usually the easy part. You restart it. You move it. You scale it.

You reroute around it. Then you hit the system with state, ordering, offsets, replication, partitions, or money-adjacent semantics, and everything slows down. That is where incidents get complicated. The app might be multi-AZ, but what about the broker?

The database? The cache? the topic, the volume, the thing that keeps the system honest. That is the real test.

The operator takeaway here is simple. Do not let multi-AZ become a comfort phrase. Find the parts of your system that are still effectively tied to one zone, one stateful dependency, or one recovery path, especially the low-latency pieces, the Kafka pieces, the databases, the matching engines, the services with ordering, offsets, or money adjacent semantics. Then ask the annoying question, what happens if that AZ disappears?

What depends on recovering in place? What can actually fail over? How long does it take? And when was the last time we proved it?

Because resilience is not where the diagram says the boxes are. It is where the system can actually recover when one of those boxes disappears. Second story, Meta confirmed an incident involving its AI-assisted Instagram support flow. where more than 20 ,000 accounts were likely impacted.

The reported issue was that attackers could use Meta's AI support tooling to trigger password reset links to an email address that was not actually associated with the victim's account. Meta described it as a bug where the system did not properly verify that the provided email matched the email on the Instagram account. So attackers could receive reset links for accounts they did not own. Now, I know what you might be thinking.

Instagram accounts do not sound like a normal DevOps or SRE story. But the real story is not social media accounts got hacked. The real story is this. AI support automation became part of an identity recovery control plane.

And that is absolutely our lane. Account recovery is privileged infrastructure. It is the break-glass path for identity it can reset passwords it can change emails it can bypass parts of the normal login path when the user needs help that means it has power and if ai can influence that workflow then the ai is not just answering support questions anymore it is participating in an identity decision that changes everything a chatbot that answers how do i update my profile photo is one thing A chatbot that helps move an account recovery flow forward is very different.

That system needs real authorization logic, real verification, rate limits, abuse detection, audit logs, escalation paths, blast radius controls, and a very clear line between what AI can suggest and what the system is allowed to do. Because attackers do not care whether your org chart says this belongs to support. identity, security, product, or infrastructure. They care that the workflow can reset accounts.

So they attack the workflow. This is also a reminder that AI risk is not always a coding agent running shell commands. Sometimes it is much more boring. A support flow trusts the wrong field.

A reset link goes to the wrong place. And suddenly, the AI part gets the headline. But the real failure? is the control boundary around the action.

The takeaway here is not AI support is bad. The takeaway is that support workflows can be privileged infrastructure. Password resets, MFA resets, email changes, account recovery, support impersonation, admin ownership changes. Those are not just customer service features.

Those are identity control paths. So when AI gets added to that flow, The question is not just, is the answer helpful? The question is, what can this workflow actually do? Can it suggest?

Can it route? Can it trigger actions? Can it change trust? And if it can touch identity, it needs the same seriousness as any other production control plane.

Because the scariest AI system in production might not be your coding agent. It might be the support flow that can reset passwords. Third story. AWS published a security bulletin for CVE-2026-11393 in AgentCore CLI.

And if last week's Kiro bug was stdin answered the approval prompt, this one is more like agent metadata became Python code, which is not the kind of sentence you want in a security bulletin. The issue involves AgentCore CLI when importing a Bedrock supervisor agent with multi-agent collaboration enabled. The advisory says the CLI fetched collaborator metadata from the Bedrock API and inserted the collaborationInstruction field into a triple quoted Python string in the generated main.

py file. The problem was improper escaping of triple quotes. So a crafted instruction could break out of that intended string and inject Python code into the generated file. Then, if the file was run locally or deployed into AgentCore Runtime, the injected code could execute with the credentials available to that environment.

AWS recommends upgrading the CLI, removing affected imported agents rerunning the import with the patched cli and redeploying if you cannot upgrade right away they recommend manually inspecting generated main.py files for suspicious triple quote sequences in collaborator instructions now this is preview tooling and the attack path is specific but the pattern matters generated code is code that sounds obvious but teams do not always treat generated code with the same suspicion as handwritten code.

Generated files feel like outputs, artifacts, something the tool made, something official, something you probably do not need to read too closely. But if untrusted or semi-trusted metadata gets inserted into source code, your generator becomes a compiler for attacker-controlled input. And we have seen this movie before. SQL injection.

Template injection. Shell injection. CI config injection. YAML templating weirdness.

Now it is agent metadata turning into Python. Different costume, same villain. The AI angle makes it feel new, but the secure engineering lesson is old. Do not turn text into executable content without a hard boundary.

Do not assume metadata. is safe because it came from an API. Do not assume generated code is safe because it came from an official tool. And definitely do not assume instructions are harmless.

In agent systems, instructions are operational inputs. They can shape behavior. They can get passed between systems. They can become config.

They can become prompts. And sometimes they can become code. The takeaway here is short. Generated code is still code.

If a tool turns metadata, instructions, templates, or agent definitions into executable files, that path needs review. Keep the CLI updated. Inspect generated files before running them in trusted environments. Run agent tooling with limited permissions.

And pay attention to what credentials are available if something goes wrong. Because the blast radius is not just the bug. The blast radius is what the generated code can access when it runs. Fourth story.

Google Cloud disclosed a vulnerability in Apigee, CVE-2025-13292. Google's release notes say the issue could have allowed a malicious actor with administrative or developer -level permissions in their own Apigee environment to elevate privileges and access cross-tenant data. NVD describes it as unauthorized read and write access to Apigee analytics data and access logs belonging to other customer organizations. Google says the issue was patched and no user action is required.

That is good. But the phrase that matters is cross-tenant. Tenant isolation is one of the deepest assumptions in cloud computing. You have your environment.

Other customers have their environments. The provider keeps those boundaries in place. That is the model. Most of the time, you do not have to think about it.

And you cannot think about it all day. If cloud customers had to constantly wonder whether another tenant could see their logs, analytics, objects, volumes, or traffic, nobody would get anything done. So when a managed service has a cross-tenant issue, even a patched one, it is worth paying attention. And Apigee is not some random side tool.

API management sits in a sensitive part of the stack. It can see traffic patterns, access logs, analytics, client behavior. API paths, timing, errors, and sometimes more than people realize. Access logs are not always harmless.

They can reveal service names, query parameters, client identifiers, internal routing, usage patterns. And because logging systems are logging systems, sometimes they capture fields everyone later wishes had been redacted. So cross-tenant access to analytics and logs is not just a privacy issue. It can be a reconnaissance issue, a compliance issue, a customer trust issue.

The takeaway is not never use managed services. That would be ridiculous. The takeaway here is that tenant isolation is not just a cloud provider promise. It is a design requirement.

For every platform team building multi-tenant systems, logs, analytics, dashboards, exports, admin tools, support consoles, background jobs, search indexes, all of those can become tenant boundary problems. So do not only test the obvious request path, test the internal paths too. Can tenant A see tenant B's logs? Can a support view cross the wrong boundary?

Can an analytics query forget tenant context? Can an async job mix records that should never touch? Cross tenant bugs usually do not start in the happy path. They start in the seams.

Now let's do a quick lightning round. First, Cloudflare is turning threat indicators into real-time WAF rules. Cloudflare says Cloudforce One threat intelligence can now be used directly inside the WAF engine. That means teams can write rules based on things like known attacker names, targeted industries, source countries, target countries, and attack context.

I like the direction. It moves security from, we know this traffic is bad, towards we can actually enforce on that knowledge. But the operator warning is obvious. Threat intel in the blocking path is still production change management.

Start in visibility mode. Watch false positives. Stage the rollout. Make sure that the logs explain why something was blocked.

Automation is great until it blocks your biggest customer because a field matched a little too creatively. Second, AWS published guidance. for Lambda tenant isolation mode with event source mappings. The interesting part is that async systems do not naturally carry tenant context the same way synchronous API requests do.

With an API request, you may have headers, claims, and request context. With SQS, EventBridge, or other event sources, tenant identity may be inside the payload or may need to be extracted and passed along carefully. That matters because multi-tenant bugs love async systems. A message loses context.

A worker assumes the default tenant. A retry uses the wrong metadata. A batch mixes records that should never be mixed. Tenant isolation is not just about the runtime.

It is about context propagation. especially when queues and events are involved. Third, the next generation of Amazon OpenSearch Serverless is generally available. AWS says it provisions faster, scales faster, supports scale to zero, and can reduce costs compared to provisioning for peak load.

That is a FinOps story, but it is also an operations story. If teams start treating search and vector infrastructure as more elastic and disposable, they still need to understand cold starts, latency, indexing behavior, cost patterns, and traffic spikes. Serverless does not mean operationally invisible. It means the operational questions moved.

Fourth, GitHub Enterprise Managed Users IP Allow List coverage is generally available. Enterprises using EMUs can now enforce GitHub's native IP Allow List configuration across user namespaces. That matters. Because source control is production infrastructure.

Repo access is part of your security boundary. And more of that boundary is moving into identity, network policy, device posture, and enterprise governance. IP allow lists do not solve everything. But repo access is still one of the fastest ways to turn a credential problem into a production problem.

The human closer this week is about the glue. Coinbase was not just an AZ failure. It was state, latency, Kafka, and recovery paths. Meta was not just an AI support bug.

It was account recovery becoming identity infrastructure. AgentCore was not just a Python escaping issue. It was metadata turning into executable code. Apigee was not just a patched cloud vulnerability.

It was tenant isolation showing up in logs and analytics, not just the main product path. Different stories, same pattern. Modern reliability and security problems keep showing up in the seams. The support flow.

The generated file. The recovery path. The admin console. The queue.

The logs. The things between two systems that quietly decides what is allowed to happen next. That is where a lot of real platform work lives now. Not just making the app scale.

Not just adding another region. Not just buying a managed service. But asking where the authority actually sits. Who can recover an account?

Who can generate code? Who can access another tenant's data? Who owns the failover path? Who tested the recovery plan?

And who gets paged when the glue fails? So the takeaway this week is simple. Do not just review the big production systems. Review the seams.

That is usually where the incident is waiting. That's it for this week of Ship It Weekly. We covered Coinbase's May 7th outage postmortem, Meta's AI support and Instagram account recovery issue, AWS AgentCore CLI CVE-2026-11393, Google Cloud Apigee's cross-tenant vulnerability, and a lightning round on Cloudflare WAF threat intel, AWS Lambda tenant isolation, OpenSearch Serverless, and GitHub Enterprise Managed Users IP allow lists. If this episode was useful, follow or subscribe wherever you are watching or listening.

If you are on YouTube, hit subscribe. If you are in a podcast app, follow the show there. And if you know someone dealing with cloud resilience, AI support workflows, agent tooling, tenant isolation, or repo governance, send this one to them. It helps the show grow, and it helps me keep making this kind of content for people who actually live with these systems.

You can find the weekly brief at OnCallBrief.com and more episodes and this week's show notes at ShipItWeekly.fm. I'm Brian Teller from Teller's Tech.

Thanks for listening. And remember, the system that breaks production is not always the big obvious service. Sometimes it is the glue everybody forgot was holding the whole thing together.