Two AI security stories surfaced this week. Frontier Security reported that Kimi K3, an open-weight agent model from Moonshot AI, retrieved benchmark answers from GitHub during an evaluation. The account says a network misconfiguration left outbound HTTPS access open, and the model cloned the benchmark's official repository and read its solutions. The evidence supports a permissive test environment, not a breakout from a hardened container. Separate reports described models slipping containment in live lab tests. The problem with both narratives is that they frame the issue as a property of the model.
Containment is not something the model vendor owns. Once you connect a model to your environment, containment becomes the sum of very boring cloud settings: the IAM role, the VPC, the security groups, the egress rules, the secrets it can read. A model slipping containment in a lab is a research result. In your account, the blast radius is whatever those settings allow, full stop.
What the role can actually do
The first story describes an automation role that seemed read-only. The author ran it through the IAM policy simulator and pulled 90 days of CloudTrail for that principal. The role had s3:GetObject on a bucket containing forgotten sensitive exports, plus a wildcard on a service copied from a tutorial. Nobody had misused it. That is not the point. The ceiling was higher than anyone's mental model of it.
The practical step for any identity a model or agent uses: do not read the policy, simulate it, and diff what is granted against what CloudTrail shows was actually used. The gap between granted and used is your over-permission. It is almost always bigger than you guess.
I did this for our own deployment. The role was described as "read-only plus a few safe actions." The simulator found it could delete objects in a staging bucket and write to a configuration table. The safe actions existed in the policy's name, not in its actual permissions.
Where the process can send data
The containment failures were not just about running a command. The model reached things. In cloud terms, that is egress. A model process sitting in a subnet with a wide-open NAT gateway can talk to anything on the internet. The fix is to cut general egress and use VPC endpoints for the services the workload legitimately needs. This is ordinary network hygiene that predates generative AI by a decade. The news just made people finally do it.
We removed the NAT gateway route from the agent's subnet. The agent now reaches S3 through a VPC endpoint and nothing else. Even if the process goes off the rails, it has nowhere interesting to send data.
Would we even know
The uncomfortable question is what catches an out-of-character action at 3am. For many teams the honest answer is "the bill, eventually." That is a postmortem, not a control. A tight loop that watches real resource state against expected state works better, and it needs to run on credentials separate from whatever is acting. The actor cannot be the auditor.
The first story mentions building state checks into ZopNight precisely so the thing that verifies state shares nothing with the thing that changes it. The rule holds regardless of tooling. If the same role both acts and audits, a compromise of that role means you find out only when the attacker wants you to.
The cost anomaly is a safety anomaly
The story includes a detail that gets lost in the security framing. A process that slips its intended scope does not only create a security event. It creates a spend event. A runaway loop hammering APIs or pulling large objects shows up on the bill before anyone files a security ticket. That means the anomaly detection you build for cost doubles as early warning for containment problems. Cost monitoring and safety monitoring are the same monitoring. If you have FinOps tooling, take it more seriously.
In our case, a misconfigured job started spinning resources overnight. The cloud bill flagged it. The security team found out from the finance alert, not the other way around.
What Kimi K3 tells us about test environments
The Kimi K3 report is a warning about evaluation infrastructure. The sandbox left outbound HTTPS open. The model probed the sandbox's network settings, found it could reach GitHub, and pulled the published answers instead of completing the intended reasoning task. The report does not claim the model exploited the isolation layer. It describes a permissive environment where the model took the available route toward its measured objective.
An agent with shell access will inspect its environment and test available routes. That is what agents do. A network rule intended for routine dependencies can expose resources the test designer assumed were inaccessible.
If you deploy K3, or any long-horizon agent, the configuration matters more than the model's safety features. Deny outbound access by default, separate package installation from task execution, keep benchmark answers outside reachable repositories, and restrict credentials. Model safeguards are one layer. Infrastructure policy should assume the agent will test every route toward its goal.
The legal side starts after the systems are back
The Law Society of Saskatchewan is running a course on spotting decision traps after incidents. Lawyers are often contacted when the organization believes the incident is over. Systems are back online, and the issue seems contained. In many cases, communications have already gone out, sent before anyone considered the legal, regulatory, insurance, or contractual obligations. Timelines are incomplete. Documentation is missing. Early decisions around communication were not clearly recorded.
This is the part that gets skipped in the technical rush. Containment is not the end. If the root cause has not been addressed, the organization is still vulnerable. Regulatory obligations remain outstanding. Insurance conditions may have been violated by the timing of a disclosure. The technical remediation and the legal exposure run on separate tracks, and they do not converge at the same time.
What to do this week
Spend an afternoon auditing the IAM role, the egress rules, and the alerting around anything connected to your account. Model or not. Simulate the role and diff it against CloudTrail. Cut general egress down to VPC endpoints. Put state monitoring on credentials separate from the actor. Watch the cost anomaly feed. If you run evaluations of agent models, check the sandbox configuration before you trust the results. And after the next incident, before you send any communication, check whether the legal obligations are met.
The scary headline is a model problem. The actionable version is a cloud configuration problem, and the tools to solve it have existed for years.