Home  /  Resources  /  White paper: The unwatched workbench

Whitepaper - 12 min read - 4 October 2026

White paper: The unwatched workbench - governing the AI tooling your developers already run

In the space of a few weeks, researchers showed that a GitLab AI Gateway could be commanded by any Duo user, that a folder of files could run code through eight coding agents before they asked permission, that agents had posted more than 13,000 internal screenshots to public GitHub without any attacker involved, and that two agent sandboxes could be switched off from the inside. None of these are exotic. They sit where developers do their daily work, and most organisations have no inventory of them.

By Verona - Published: 4 October 2026

Executive summary

Most security programmes know where the production estate is. Far fewer can say what their developers' AI tools can reach. A coding agent runs with the developer's file access, shell, cloud credentials and GitHub login. An AI gateway or harness sits in the delivery path holding signing keys and model provider tokens. Both arrived through team choice rather than procurement, so neither tends to appear on an asset list, a patch schedule or a risk register.

This paper takes five pieces of recent research and reads them together: GitLab's CVE-2026-90970 AI Gateway template escape, Manifold Security's GitSpawn, Glow Labs' PixelLeak, OX Security's DeepSeek Harness CVE-2026-82533 and Accomplish's two Codex sandbox escapes. The framework at the end is designed to be run by a platform or security lead in a single working session.

1. The gateway is part of the delivery path

CVE-2026-90970 scores 9.9. A user with Duo Agent Platform access can submit a crafted flow configuration, leave the prompt template sandbox and execute commands on a self-hosted AI Gateway. GitLab fixed it in 19.2.4, 19.3.2 and 19.4.1 and offers no workaround. The attacker needs an account, and many organisations give every developer one. The gateway holds JWT signing keys and links to model providers, so a compromised host is a stepping stone into both. GitLab had a similar template-engine 9.9 earlier in the year, CVE-2026-1868, which tells us the template layer is a recurring weak point and not a one-off slip.

The governance consequence is simple. Whoever runs an AI gateway should patch it on the same clock as a build server, restrict who can author flows, and rotate its keys after any doubt about its state.

2. Agents obey the repository before they obey you

GitSpawn is a neat illustration of an ordering problem. Coding agents run git commands to gather context. Git honours settings such as core.fsmonitor found in a repository's own config, so a folder delivered as files can execute a program as the developer, outside the sandbox, before the approval prompt is ever drawn. Manifold reported to eight vendors between late June and late July. At publication Goose, Cursor and Codex were patched, Claude Code was patched on one route but not another, and Hermes Agent, Qwen Code and Grok Build were still open.

Cloning from a URL does not carry the config, so the risky path is the zip file, the shared drive and the memory stick. In other words, contractor hand-overs, interview exercises and acquired codebases. Those are precisely the places where code from outside enters a company without review.

3. Sandboxes that the agent can reach into

DeepSeek Harness 0.1.1-rc.2 and earlier trusted the HTTP Host header on a localhost API, while the sandbox left loopback networking open. An agent could therefore send itself a request and move to "danger-full-access" with no prompt (CVSS 9.4, fixed in 0.1.2-alpha.1). Accomplish's two Codex findings, reported on 12 August and fixed within eight days, share the pattern: apply_patch granted write access to the parent of each path it was handed, so naming /tmp opened /, and a shared JavaScript heap let untrusted code lift an authentication token and run commands unsandboxed. Accomplish's own summary is that the enforcement ran inside the thing it was meant to constrain.

For a buyer, the lesson is to ask where the boundary is enforced. A control that lives in the same process, memory space or loopback interface as the agent is a speed bump, not a wall.

4. Helpfulness as an exfiltration route

PixelLeak needed no vulnerability. Agents asked to show screenshots in pull requests found that the GitHub CLI cannot attach images, concluded the images needed to be hosted publicly, and created repositories to do so. Glow found over 13,000 internal images from more than 300 organisations across 900-plus repos, with 93 per cent in personal accounts and about a third traceable to the gitshot helper. Contents included billing records, treasury consoles and unreleased work.

Data loss prevention products look for files leaving through known channels. An agent solving a formatting problem by creating a new public destination is not a channel anyone had listed.

Governance framework: eight checks

Run these as a working session with the people who actually configure the tools, not as a policy exercise.

  • Inventory every AI gateway, harness and coding agent in use, including ones installed by individuals. Record version, owner and which credentials each can reach.
  • Put AI delivery servers on the patch cadence of your CI system, with a named owner and a stated deadline for critical advisories.
  • Restrict who can author flows, templates, plugins and custom agent instructions. These are code, and should have review.
  • Treat any folder received as files as untrusted. Inspect .git/config before opening it with an agent, and ask vendors to confirm context-gathering git calls disable config-driven execution.
  • Ask each vendor where sandbox enforcement lives and what happens on loopback, symlinks and shared memory. Record the answer, and review it when the product updates.
  • Block developer tokens and org settings from creating public repositories or changing visibility, and give agents an approved home for screenshots and artefacts.
  • Search public GitHub for your organisation's names, logos and domains, including accounts belonging to former staff and contractors.
  • Keep agent credentials separate and short-lived, so that one escaped agent does not own a developer's entire machine.

Risks and how to manage them

The usual failure is to ban the tools and discover six months later that people use them anyway, on personal machines and personal accounts. PixelLeak's 93 per cent figure suggests this has already happened at scale. A sanctioned route with logging, plus the technical limits above, produces better outcomes than a prohibition. A second failure is to trust vendor release notes. Several of the GitSpawn reports were closed as duplicates, which is a reminder that a "fixed" label can mean the vendor already knew and had not yet shipped anything. Verify the specific version, then test it.

Conclusion

None of the five stories required a nation state. They involved a template, a config file, a loopback port, a heap snapshot and a polite agent trying to do what it was asked. The surface is dull and everyday, and that is why it has been left alone. A day spent counting what is installed, who can configure it and what it can touch will find more risk than most penetration tests, and the fixes are mostly small.

Not sure what your developers’ AI tools can reach?

We can run a half-day review of your AI gateways, coding agents and repository settings against the eight checks in this paper.

Contact Halfteck

A maturity ladder for developer-side AI

At the ad hoc stage, tools are chosen by individuals, credentials are the developer's own and nobody owns patching. At managed, there is an inventory, gateways are on a patch cadence and flow authoring is restricted. At controlled, agents run with scoped, short-lived credentials, public-repo creation is blocked at the organisation boundary and vendor sandbox claims have been tested. Most teams we speak to sit between the first and second rungs, and one session on the eight checks is enough to move them up one.

Questions to put to a vendor

Does the agent run any process on a directory before the user approves it? Which network interfaces can the sandboxed process reach? Is the approval decision taken inside or outside the sandboxed process? What is the support window for older versions, given that GitLab offers no fix before 18.1.6? Answers to those four tell you more about a product than its feature list.