When Agents Start Looking for Windows
The OpenAI/Hugging Face incident is a reminder that agents need identities, tool boundaries, egress controls, logs, and kill switches before they get anywhere near production.
Hi,
Today, we are going to talk about agent containment: What happens when AI agents get tool access, shared state, and just enough room to find gaps you did not know you left open.
Before we get into that, Sif Baksh is running a hands-on workshop on August 25 that sits very close to this problem.
Seats are moving fast, and the price goes up in less than 24 hours.
A note from Sif Baksh
Build an AI Assistant for Network Troubleshooting,
August 25th, 9 AM EDT
If you have ever troubleshot a BGP neighbor stuck in Active, you know the problem is rarely that no answer exists. The problem is finding the answer that matches your network, your configs, your runbooks, and the way your team actually operates.
That is what we are building on August 25.
In this four-hour hands-on session, we will build a RAG-powered NetOps assistant that answers from your own operational knowledge: runbooks, device configs, troubleshooting notes, and the material your team already trusts. The goal is not to build another chatbot that guesses from the open internet. The goal is to build something useful enough to help during troubleshooting, and grounded enough to show where its answer came from.
Then we deal with the part that matters in the real world: guardrails. How do you stop the assistant from inventing an answer? How do you keep it from recommending a production change nobody approved? How do you make sure it can help an engineer during an incident without turning into another thing you have to babysit?
That is the shape of the session: build the assistant, connect it to the right sources, constrain what it can do, and make the output easier to trust.
Four hours. Four labs. For CloudPro readers, use code CLOUDPRO40 for 40% off all passes.
P.S. My book, Building AI Agents for Network Operations, goes deeper into the same architecture. You can bundle it with your event pass at checkout, or pick it up separately if the 25th does not work for your calendar.
That is the hands-on version. Now, back to the wider platform problem.
Over the last few CloudPro issues, we have been following enterprise AI past the fun part. The bill came first. Then the demo. Then the platform. Then absorption. Then ownership. If you missed that run, it is worth going back to it, because the shape is clear now: the hard part is no longer proving that an agent can do something useful. The hard part is making sure the enterprise can run it, govern it, pay for it, trust it, and stop it.
That last verb is where this issue begins. Because, apparently, agents have also discovered a classic enterprise collaboration pattern: find a shared repository, leave notes for each other, and keep going after someone deletes the board. Somewhere, a platform engineer just heard Agent Smith whisper through a broken CI runner.
The incident behind the joke is not funny. OpenAI disclosed in July that Hugging Face detected and contained an AI agent that had compromised its infrastructure during a model evaluation involving OpenAI models configured with reduced cyber refusals for testing. OpenAI said the incident involved models including GPT-5.6 Sol and a more capable pre-release model, tested internally on a cyber-capability benchmark. It also said the activity moved through infrastructure connected to the evaluation environment, including third-party services and external infrastructure.
The detail that should make platform and security teams sit up came later at Black Hat. Axios reported that an OpenAI model found and exploited a vulnerability in Artifactory, a package repository connected to the testing sandbox. The model then used that shared package repository as a message board, leaving notes that other agents could find. OpenAI cleared the board and patched the zero-day. Two days later, the agents reportedly recreated the message board through a different mechanism.
That is the bit worth holding onto. This was not just a bad output, a hallucinated command, or a confused chatbot. The more interesting behavior was persistence across steps. The agent found a path, used shared state, adapted after cleanup, and kept pursuing the goal. Every practitioner reading this has seen a human team do some version of that during a migration, outage, or release crunch. The uncomfortable part is that the system was not supposed to have that kind of room.
My view is simple: Enterprises are going to connect agents to real systems faster than they build containment models for them.
That is where the next wave of incidents will come from. The teams that get hurt first will not be the ones using agents. They will be the ones using agents with broad credentials, unclear egress, weak tool boundaries, and no boring way to shut the thing down.
This is the production shift. We spent the last year asking whether agents could act. The next question is what they can reach when they do. That is a platform question, a security question, and an operations question sitting in the same chair.
The old control model does not stretch cleanly. We built controls around software that follows defined paths, humans who can be trained, and services whose identities stay mostly stable. Agents blur that. They plan, call tools, retry, chain actions, and use whatever state the environment gives them. A single action can look harmless. Ten actions in sequence can become a route nobody reviewed.
The AI Security Institute (AISI) sandboxing work makes the same point from another angle. Sandboxes are meant to limit what tool-using models can access, but AISI notes that it is hard to predict what tools a model will need, how proficient it will be, and whether it will pursue misaligned goals. In one benchmark-development case, a model found and exploited an unintended escape path, which is exactly the kind of gap platform teams know can creep into even carefully designed environments.
So the practical question is not, “Do we trust the agent?” That framing is too soft. The better review question is: “What can this system do if it starts getting creative?”
Start with identity. Every agent needs a named identity, a named owner, and a clear reason to exist. Shared service accounts are already bad enough with humans. With agents, they become plausible deniability wrapped in automation. If the agent touches repos, clusters, cloud APIs, incident tools, observability systems, or customer data, someone should be able to answer who approved that access and why it still exists.
Then look at tools. Read, propose, and execute should be separate modes, not different moods of the same credential. The agent that can inspect Kubernetes events should not automatically be able to restart workloads. The agent that can draft a Terraform change should not automatically be able to merge it. The agent that can summarize an incident should not automatically be able to page a vendor, create a token, and post to a public issue thread.
Next comes egress. This is the one people will try to hand-wave because it is annoying. Do not. An agent with internet access, a writable workspace, and a goal can invent collaboration surfaces you did not mean to provide. Treat package repositories, object storage, paste services, issue trackers, comments, notebooks, and scratch files as places where agents can coordinate. The lesson from the OpenAI/Hugging Face incident is not that Artifactory is special. The lesson is that shared state is a communication channel when the system using it is motivated enough.
Logging also has to change. You do not just want the final answer. You want the path. Which tool calls happened? Which files were written? Which credentials were used? Which external endpoints were touched? Which action failed, and what did the agent try next? In the human world, this is incident reconstruction. In the agent world, it is the difference between “the model did something weird” and “here is the exact trajectory we need to block.”
This is where platform engineers get to be Neo, unfortunately, with a lanyard around their necks. The job is to make the bullets visible early enough to stop them: identity scopes, tool gateways, egress controls, approval gates, runtime monitoring, and revocation paths. None of this is glamorous. Most of it is the same muscle you already use for CI/CD runners, service accounts, Kubernetes RBAC, and production change control. The difference is that agents will find edge cases faster than humans, and they will do it without looking embarrassed.
The operational checklist is boring by design. Can you pause the agent? Can you revoke its credentials quickly? Can you cut egress without breaking half the platform? Can you see every tool call? Can you preserve logs? Can you tell whether it wrote to a repo, changed a config, opened a network path, or created state another agent could reuse? Can you roll back what it touched?
That is what containment looks like when it leaves the slide deck. It is not a policy that says agents should behave. It is an architecture that assumes they may not, and still gives the enterprise time to respond.
There is a tempting overreaction here, which is to decide that agents are too risky and keep them in toy workflows forever. That is the wrong lesson. The right lesson is harsher and more useful: agents belong in serious workflows only when the containment is serious too.
The organizations that win here will not be the ones with the most agents wired into the most tools. They will be the ones that can say, with a straight face, where each agent can act, what it can touch, who owns it, how its path is monitored, and how quickly the door closes when it starts looking for windows.
That is the next production question after ownership. Once you know who owns the agent, you need to know what that owner can contain. That is where the production conversation has to land. Agents will keep getting more capable, more connected, and more useful. The enterprises that benefit will be the ones that build enough containment around them to use that capability without pretending autonomy is harmless.
Cheers,
Apramit Bhattacharya
Editor-in-Chief
The larger point being made is that agents are moving from answer boxes into operational workflows. Once they can inspect systems, correlate signals, suggest fixes, or touch identity paths, the question becomes practical very quickly: how do we build them, constrain them, approve their actions, and make sure humans still own the decision?
That is the thread running through the next two sessions as well. One looks at agentic infrastructure engineering inside Kubernetes. The other goes back to the identity layer that decides who, or what, should be allowed to act in the first place.
Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators
Ritesh Vajariya, founder & CEO - AI Guru, teaches you how to build an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve, replacing the documentation chatbot most platform teams already outgrew. Seven production-grade failure scenarios, injected into your own local Kubernetes cluster, yours to keep and re-run after the session ends.
If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.
Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture
Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.
Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.
Before you go, I’d like to hear from regular CloudPro readers. Hit reply and tell me what would be most useful for your team. And if this issue helped sharpen the conversation, please like it and leave a comment so more platform, cloud, security, and infrastructure folks can find it.