AI Agents Target GitHub, Kubernetes 1.37 Deprecations, AWS Transit Gateway Policy Routing, IAM Identity Center Multi-Region, Cloudflare Meerkat, AMOS Mac Malware, and the Risk of Half-Migrated Production Systems

The thing I kept coming back to with this episode is how different the system you intended to build can be from the system that is actually running.

That sounds obvious, but it shows up in almost every story this week. The AI agents were supposed to be operating inside a controlled evaluation. Kubernetes 1.37 has behaviors that might only matter if your clusters still depend on something you forgot was there. Transit Gateway policy-based routing makes the network more expressive, but it also means the route a packet takes is no longer obvious from the destination alone. IAM Identity Center can replicate across Regions, but that does not automatically mean your entire access path is resilient. And the human closer is basically the purest version of this problem: production was halfway through a migration, so the architecture on paper did not really exist.

The AI agent story is probably the most interesting example because I think it exposes a weak assumption we still make with autonomous systems. We tend to reason about what the agent is supposed to do. The agent was given a cyber challenge, so we mentally put a box around the challenge. But the agent does not necessarily understand that box the same way we do. If GitHub, the public internet, credentials, email, or another external service are reachable, those are capabilities available to solve the problem. Saying “we did not intend for it to use that” is not much of a control.

That is why I think the distinction between access and authority matters so much. Giving an agent a GitHub token should not automatically mean it can perform every action that token technically permits. In a normal application, we spend a lot of time thinking about authorization, scoped credentials, network policy, admission controls, and least privilege. Agentic systems do not make any of that less relevant. If anything, they make it more important because you now have something actively exploring the space of possible actions instead of a deterministic application following a path you wrote yourself. The safest architecture is probably one where the model asks to do something and another system decides whether that specific action is permitted.

The Transit Gateway story is a quieter version of the same problem. Policy-based routing is genuinely useful. Being able to route based on source, destination, protocol, and port can simplify architectures that previously needed extra VPCs, inspection hops, or awkward route-table tricks. But you are trading visible topology for policy. Once first-match-wins rules start deciding where traffic goes, the architecture diagram is no longer enough. You need to be able to answer why this packet matched this rule and ended up on this path. Otherwise you have made the network more powerful while making it harder for the person on call to reason about.

I like the IAM Identity Center update for a similar reason. Multi-Region applications get discussed constantly, but a lot of organizations still have very regional dependencies around the application. Identity is one of the big ones. You can have workloads in three Regions, replicated data, DNS failover, and a carefully rehearsed recovery plan, and then discover during an incident that the humans trying to execute that plan cannot get into the account. AWS expanding Identity Center replication helps, but it is also a reminder to look beyond the workload. KMS, DNS, identity, CI/CD, artifact storage, VPN access, break-glass credentials and even the laptops responders are using can all become part of your recovery architecture.

Kubernetes 1.37 fits into this from another direction. Release notes tell you what Kubernetes is changing. They do not tell you which forgotten assumption inside your environment is about to become your problem. Maybe you are still using IPVS mode. Maybe an old workload depends on static pod behavior nobody remembers configuring. Maybe SELinux volume handling exposes something unusual about how two workloads share storage. The only way to know is inventory and testing. Upgrade planning gets a lot easier when you know what you actually run instead of what you think you run.

And that is why I liked the CloudFront migration story as the closer. It is incredibly normal. Four services are moving. Two have crossed over. Two have not. Multiple people are touching shared Terraform. The runbook describes the target architecture while production is sitting somewhere between version one and version two. Nothing about that is exotic. It is probably closer to the normal state of a mature production environment than the clean diagrams we show during design reviews.

We tend to treat migration states as temporary enough that they do not deserve the same discipline as the final architecture. Then temporary lasts three months, six months, sometimes years. During that time, the system still needs monitoring, ownership, rollback procedures, security controls, and documentation that reflects reality. A migration matrix sounds boring compared with a new platform feature, but knowing exactly which services use which traffic path, module version, security model, and rollback target can be the difference between diagnosing an incident and spending an hour discovering what architecture you currently have.

If I had to boil the episode down to one thing, it would be this: operate the system that exists, not the system you intended to exist.

Architecture diagrams, permissions, runbooks, policies, and migration plans are all models. Production is the thing that actually executes them. The further those two drift apart, the more surprising your next incident gets.