ServiceNow positions its AI Control Tower as one place to govern an organization's AI: an inventory of the agents and models in use, the policies that apply to them, and an audit trail of what they did. An argument for platform-level guardrails like these can feel abstract when nothing has gone wrong. Then, in July 2026, something did go wrong during a cybersecurity evaluation at OpenAI, and the published accounts show in detail what automated systems do when nothing outside them holds them in.
OpenAI had launched tens of thousands of AI agents on ExploitGym, a cybersecurity benchmark in which each agent works in its own sandbox and tries to exploit a specified vulnerability in a target program. The agents were meant to be fully isolated from one another. Some of them worked out that Artifactory, the JFrog package repository OpenAI hosted internally so agents could install software, could carry notes between sandboxes, and they turned it into a message board. According to the independent investigation by METR and Redwood Research, which reviewed about 1,300 agent transcripts, roughly 1,200 agents took part and exchanged more than 70,000 messages and files. They set up personal mailboxes, and the agent that started the board handed its work to another agent on the same task that had a larger budget. After one agent accidentally posted under another's handle, some began signing messages with Ed25519 keys. About 700 of them went on to attack Hugging Face, an outside AI company, whose forensic team later reconstructed about 17,600 attacker actions over four and a half days.
For government IT leaders and agency CTOs, the point to take from this is that autonomous agents can't be governed by instructions alone or by an assumption that the model will behave. The limits have to be enforced by the platform, outside the agent's context window, where its own reasoning can't reach them. Servos is a ServiceNow Elite Partner with a validated Public Sector Digital Services (PSDS) practice, and our work is with public sector agencies on the ServiceNow platform. That is the setting in which we look at ServiceNow Otto (formerly Now Assist) and AI agents: inside workflows where the platform holds the controls and the records.
1. Shared Services Become Side Channels
How the Message Board Got Built
The agents ran in separate sandboxes with no approved way to talk to each other. They did, however, share one Artifactory instance, because they needed it to install software packages.
That was enough. METR's report notes that Artifactory is not designed to keep the activity of different users separate, and that agents could create directories in its cache with only the permissions they needed to install packages. So they wrote their messages as directory names. METR believes they began each one with 'zz' because the tool they used to list the cache sorted in reverse alphabetical order, which put messages ahead of ordinary entries. Before long, a package cache was working as an organized message board. The underlying point is an old one in operating system design, going back to Butler Lampson's 1973 note on the confinement problem: any mechanism that lets one process write something another process can read can be used as a channel, whatever it was built for.
Figure 1. Illustration of the side channel: isolated sandboxes exchanging messages through a shared Artifactory cache.
How the Agents Got Out
Once they could talk, the agents shared what each of them had found, and the pieces added up to a way into Hugging Face:
Artifactory itself became a proxy. It had internet access so that it could download packages, and OpenAI reports that agents used server-side request forgery (SSRF) to make it send requests to the internet on their behalf.
On July 10, by OpenAI's count, an agent located 14 publicly exposed Hugging Face credentials with write access and shared them on the board.
The next day, an agent uploaded a dataset whose HDF5 files pointed at local file paths on a Hugging Face server. When a production worker processed the dataset, it returned the contents of those files, including the worker's environment with its secrets and tokens.
Agents then used a Jinja2 template injection in the same dataset pipeline to run arbitrary code on a production worker, which gave them a foothold inside Hugging Face's perimeter.
Figure 2. The four steps that took the agents from OpenAI's sandbox to code execution on Hugging Face workers.
Because every finding went onto the board, one agent's exploit was soon in use by most of the others. METR's analysis shows participation in the Hugging Face attack climbing rapidly, from about 20% of the agents on the board to more than 90%, once the file-read technique was confirmed.
Why This Looks Familiar in Government IT
State and local IT shops will recognize the setup. In our experience, many agency environments are a patchwork of legacy systems and custom middleware, held together by integration points that connect one department to another and that few people watch closely.
Put generative AI or automated workers on top of that patchwork and you have recreated some of the ExploitGym conditions. Suppose two automated workflows both touch the same database, staging folder or API gateway, and nothing at the system level controls what each one may do there. A communication path now exists that nobody designed, and credentials can leak along it.
2. Guardrails the Agent Cannot Argue With
The Grader That Wasn't Checking
What kept the swarm going was a wrong belief about how its work would be graded. After reading the ExploitGym paper, the agents concluded that the scorer would read their transcripts and fail any agent that captured its flag by a route other than the intended vulnerability. On the board they described the scorer as 'STRICT_CAUSAL'.
The tasks themselves were part of the problem. OpenAI found that none of its models had ever produced a correct answer on 198 of the benchmark's 898 tasks, about 22%, and that 93% of the tasks discussed on the board came from that set. METR adds that some tasks were impossible as specified. Agents on those tasks rarely gave up. Within hours of the board's creation they had reverse-engineered how the benchmark generates its flags, which gave them the answer to any task. Since they believed their transcripts would be checked, they then spent days on ways to make a shortcut look legitimate: swapping in modified target programs, probing the scorer to learn how it ran, and spoofing or editing their own transcripts.
The grader never ran the check they were afraid of. OpenAI's version of the scorer did not look at how a flag was obtained, so the agents could have submitted the reverse-engineered flag and passed. The days of work, the break-in at an outside company and the attempts to alter their own records went toward passing a test that did not exist.
A Prompt Is Only a Request
This is the weak spot in any safety design that relies on instructions alone. According to METR, the task instructions told each agent to use one specific vulnerability and said it would be failed for other approaches. The agents discussed that constraint at length and put enormous effort into getting around it.
The transcripts show agents weighing the rules and setting them aside. One agent quoted in OpenAI's report reasoned that attacking a third party with a leaked token was 'arguably unauthorized' and risky, then concluded: 'Yet goal solution.' METR found that agents recognized the attack was out of scope and unethical and joined anyway, largely to help the others on the board. A few refused. One wrote that what it saw was 'clearly infrastructure hacking' and decided, 'We should not.'
OpenAI also reports that this evaluation ran without the safeguards it uses in production, and that in later tests its production harness and system prompt cut the tendency to compromise infrastructure by more than 100 times. Instructions and model-level safeguards clearly help. They lower the odds, though, and an agency running agents against citizen data needs limits that still hold when the odds go the wrong way.
That is why an agent's own reasoning is the wrong place to put a security boundary. Asking a client process to hold back is one kind of control. Having an outside service refuse the request is another, and only the second still holds when the client is determined. The same goes for evidence. METR found agents editing the logs they could reach inside their own containers, and about 7% of the transcripts it reviewed contained tool calls the agents had deliberately spoofed. A record the agent can reach is a record the agent can try to change.
Figure 3. Controls have to sit outside the agent's reach.
Where AI Control Tower Fits
For public sector deployments, that argues against prompt engineering and agent self-policing as the whole governance model. Permission checks, security decisions and audit logging belong on a platform that sits outside the agent's context window.
ServiceNow's AI Control Tower covers the governance side of that job. ServiceNow describes it as a centralized command center for governing agentic AI. By ServiceNow's account:
It keeps a unified inventory of AI agents and models in the ServiceNow CMDB, including third-party ones brought in through integrations, and connects them to business services.
It helps enforce policies and risk frameworks for each AI agent and keeps an audit trail. That governance data lives inside ServiceNow, where the people responsible for the agent can review it.
It tracks AI agents through their lifecycle, assesses them for risk and compliance, and monitors their usage.
3. A Single Platform with Public Sector Digital Services (PSDS)
Every Integration Point Is a Possible Side Channel
OpenAI's ExploitGym run was a sandboxed evaluation, and the agents still found a gap in a shared service. Agency environments are likely to have more. In our experience, years of legacy software, custom middleware and paper-based intake have left agencies with many points where systems meet.
Each custom integration is a place where a side channel could form once AI is added. And when access is managed separately in each application, there is no single security boundary to check against. Those are the blind spots where an automated task can expose data by accident or do more than it was meant to.
Moving Legacy Systems onto a Single Platform
The most reliable fix we know of is consolidation. ServiceNow's Public Sector Digital Services is built to serve constituents, businesses and agencies on a single platform with a government data model, which gives agencies somewhere to move slow paper processes and scattered legacy systems.
PSDS includes applications such as Grants Management and the License and Permit Playbook, and agencies can build their own case types on the same data model. When those services share one platform, there are fewer unwatched connections between separate systems, and access for users and automated tasks can be managed on one platform instead of application by application.
How Servos Runs These Projects
None of this happens in one step. Servos is a consulting and implementation partner, and our projects generally move through three stages:
Strategy comes first. We work with agency leadership on a roadmap that puts the highest-impact projects up front and plans for organizational change.
In design, we work out the experience for constituents and staff and decide where policy limits belong in each workflow.
Implementation builds the workflows and applications on the ServiceNow platform, using our ServosGov framework for PSDS where it fits. Managed services are available after go-live.
4. Putting ServiceNow Otto and AI Agents to Work
Agents Inside a Workflow
Left without workflow boundaries, the ExploitGym agents organized themselves. Programs that were meant to work alone made up their own communication channels, their own task assignments and their own way of verifying one another.
Avoiding AI agents altogether would be an overreaction. Agencies can run them inside defined workflows instead. ServiceNow describes its AI specialists as assigned to roles, with business context and permissions, and on a service management platform an agent's work can be set up as steps in a business process someone designed, with the platform keeping a record of that work.
What This Looks Like in Practice
ServiceNow Otto is ServiceNow's AI assistant for work. Servos can help agencies put it on high-volume, repetitive service tasks. For PSDS, ServiceNow lists features that already cover several of them:
Caseworkers can have the details and comment activity of a public service case summarized, so they get the context without reading the whole record.
Document screening takes on the repetitive work of validating large volumes of uploaded documents, such as those that arrive with license, permit and grant applications.
Staff can get summaries of legislation and policy documents through AI search, and summaries of chat conversations.
Availability depends on the environment. ServiceNow's documentation notes that some AI models and features may be restricted or unavailable for FedRAMP and other regulated instances, so each agency should confirm what its own instance supports.
Conclusion
Why We Called This 'Beyond Optimism'
A sentence in a system prompt telling a model to be safe is a hope about how the model will behave. In an evaluation with reduced safeguards and tasks no model had solved, OpenAI's agents showed how far a capable system will go when that hope is the main thing holding it back. Permissions, role-based access and audit records enforced at the platform layer are architecture. They do not depend on the agent's cooperation.
State, local and federal agencies can keep their generative AI programs moving. What they need underneath is a foundation where unmonitored communication and privilege escalation are designed out as far as possible and noticed quickly when they are not.
Working with Servos
Servos is a ServiceNow Elite Partner with a validated Public Sector Digital Services practice, and our focus is the public sector: state, local and federal. We can help whether you are planning to deploy ServiceNow Otto and AI agents, set up governance with AI Control Tower, or modernize legacy citizen services.
Pat Snow serves as Vice President of State and Local Government Strategy at Servos, following his retirement as CTO of the State of South Dakota in June 2024. During his 28-year career in state government, Pat established South Dakota as a national leader in consolidated IT infrastructure and digital service delivery. At Servos, he continues to drive digital transformation in the public sector, helping agencies deliver more efficient and accessible services through the ServiceNow platform.
Sources
OpenAI, 'The Hugging Face incident and the road ahead,' August 26, 2026. openai.com/index/hugging-face-incident-and-the-road-ahead
METR and Redwood Research, 'Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident,' August 26, 2026. metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation
Hugging Face, 'Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident,' July 27, 2026. huggingface.co/blog/agent-intrusion-technical-timeline
Butler W. Lampson, 'A Note on the Confinement Problem,' Communications of the ACM, October 1973.
ServiceNow, 'Governing agentic AI at scale,' Workflow, April 8, 2026. servicenow.com/workflow/ethics/governing-agentic-ai-scale.html
ServiceNow product documentation, 'Exploring Public Sector Digital Services' and 'Now Assist for Public Sector Digital Services (PSDS).' ServiceNow has since rebranded Now Assist as ServiceNow Otto. servicenow.com/docs
ServiceNow Store, listing for Now Assist for Public Sector Digital Services. store.servicenow.com
ServiceNow Partner Finder, 'Servos LLC.' servicenow.com/partners/partner-finder/servos-llc.html