Pacing the Frontier: What 1,178 Frontier AI Employees Say Is Missing

In late July 2026, more than 1,100 employees of the world's leading AI companies signed a public statement called Pacing the Frontier; the letter site listed 1,178 signatories at the time of writing [1]. The signatories include Jakub Pachocki and Mark Chen of OpenAI, Jared Kaplan and Chris Olah of Anthropic, Shengjia Zhao and Dawn Song of Meta, Anca Dragan of Google, and John Schulman of Thinking Machines [1][2]. The letter was published by employees in their personal capacity, with organisational support from Guidelight AI Standards and Encode AI [1]. People working at competing frontier AI companies signed the same statement. The detail that matters for enterprise operators is the tooling gap they describe.

The load-bearing sentence

The letter makes exactly one request: that the U.S. government support an international effort to develop the technical and governance tools needed to deliberately pace the frontier of automated AI development [1]. The sentence that carries the argument comes just before it. Each company and each country is under intense competitive pressure not to unilaterally slow down, and, in the letter's words, the world lacks the technical and governance tools to deliberately pace frontier-wide progress.

Today, the world lacks the technical and governance tools to deliberately pace frontier-wide progress.

The letter does not call for a moratorium. It asks for an international effort to develop tools that would make deliberate pacing possible. Our reading is that this is partly an engineering problem: a pacing arrangement would need observable boundaries, accountable decisions, and evidence that participants could verify rather than simply trust.

Two frontiers wearing one word

There is a capability frontier, which is where model capability is produced, inside a small number of labs. That is the one the letter addresses. There is also a deployment frontier, which is where that capability is put to work, inside every bank, hospital, insurer, and government agency wiring agents into production systems. The capability frontier moves through model research and releases. The deployment frontier moves every time an organisation gives an AI system a credential, connects it to an API, or allows an agent to use a tool.

The letter's concern is that capability may outrun society's ability to understand or control the resulting systems. The enterprise version is more immediate: authority can outrun the record. An agent may retain access beyond its original purpose, while logs show individual calls but not who delegated the work, what scope was approved, or whether the action remained inside it. International pacing requires coordination among companies and states. Deployment governance is the part each organisation can address in its own environment.

What deployment governance has to do

The letter does not prescribe an architecture. At the enterprise deployment layer, we reduce the related control problem to four operational properties.

Attribution supplies the unit of accountability. Interruption has to be graduated, because observe, alert, require approval, and block are different operating choices. Dual control separates policy authorship from approval for higher-consequence changes. Independent verification lets another party test the evidence without depending on the system that produced it.

HDP carries human authority into agent execution

Helixar publishes the Human Delegation Provenance protocol (HDP) as an open draft. An HDP token records the authorising principal, the intended task, permitted tools and resources, constraints, and each subsequent delegation hop. The root and hop records are cryptographically signed, so a downstream system or later reviewer can verify how authority travelled from a person through an agent chain [9][10].

HDP is additive. It does not replace identity, secure transport, access control, or application-level enforcement. It provides the missing relationship between them: who authorised the agent, for what scope, and through which chain of delegation. The specification is published under Apache 2.0, is available as an individual Internet-Draft, and has been demonstrated in the official Google Gemma cookbook [9][10][11]. Its draft status matters: it is open work, not an IETF-endorsed standard.

Why independent verification matters

Evidence-collection tools record what a system chooses to tell them. Model-level safeguards belong to the model vendor and are not always configurable or testable by the organisation carrying the regulatory obligation. The Hugging Face investigation made that concrete in an unusually clear way. When the team tried to use commercial frontier-model APIs for forensic analysis, provider safety controls blocked the requests, because the payloads contained attack commands and command-and-control artefacts [3]. The safeguards worked as designed and obstructed the defenders. The team ran an open-weight model on its own infrastructure instead.

The lesson is not that model safeguards are unnecessary. It is that organisations also need controls they can configure, test, and evidence for their own operating context.

One signatory compares competitive frontier development to a runaway nuclear chain reaction [1]. The analogy is imperfect, but it points to the same operational requirement: coordination is stronger when participants can check whether agreed controls operated.

How Helixar matters at the deployment layer

The open letter and Helixar address different layers. The letter is about international coordination at the capability frontier. Helixar is built from the ground up as a defence, governance, and compliance platform for AI activity inside an organisation's deployment environment. It provides a control point between people and agents, the AI providers they use, and the tools and systems those agents can reach.

Helixar governs four agentic surfaces: WebAI, Endpoint, API, and Agents.

On governed traffic, Helixar can observe, alert, require approval, block, or contain according to configured policy. Behavioural anomaly detection can be enabled per deployment to examine activity across requests, while the signed trail supports incident reconstruction and forensic export. These are defence capabilities within the control plane's coverage, not a claim of universal visibility or guaranteed prevention.

Compliance is built into the same event path. Every governed interaction is recorded as an Ed25519-signed event in a hash-chained, append-only trail. Delegated agent actions can carry HDP provenance bound to the workload. Policy changes can require maker-checker approval, and the resulting policy decision, approval, action, and evidence remain connected rather than being assembled later from unrelated logs.

Evidence packs are mapped to the obligations organisations already carry. SOC 2 Type II and ISO/IEC 27001:2022 packs are available today. ISO/IEC 42001 [7], EU DORA, PCI DSS v4, APRA CPS 234, RBNZ BS-11 and the NZ Privacy Act 2020 are mapped and delivered as part of implementation, configured to each customer's control environment. NIST describes the AI RMF as a voluntary framework for managing AI risk [6], while ISO/IEC 42001 specifies an organisational AI management system [7]. Helixar's evidence mapping supports those programmes; it does not itself confer certification or guarantee compliance.

Coverage and limits

None of this paces automated AI research, slows a training run, constrains a frontier lab, or substitutes for the international coordination the letter requests. Helixar also does not replace network security, identity and access management, endpoint protection, cloud controls, provider safeguards, or incident response. It integrates with those disciplines around AI-specific activity.

Visibility depends on deployment coverage. WebAI, endpoint, API, and agent activity has to pass through an integrated endpoint or control-plane path to be observed, governed, or recorded. Activity outside that coverage is outside the record. Detection and enforcement outcomes also depend on policy, telemetry, configuration, and the surrounding controls in each customer environment.

Five questions worth answering first

Most organisations will not be asked to pace the global capability frontier. They will be asked what AI systems acted in their environment, under whose authority, and with what evidence. Five questions make that discussion concrete.

1. Which WebAI, endpoint, API, and agent surfaces are inside the control boundary, and which remain outside it?
2. Which policy applied at the moment of the action?
3. Which identity acted, and under whose delegated authority?
4. Who approved it, where approval was required?
5. Where is the record, and can anyone outside your organisation verify it?

Pacing the Frontier identifies a real coordination and tooling problem at the international level. At the enterprise level, the practical work is to make AI activity visible, connect actions to human authority, apply policy while activity is occurring, support defence where behaviour departs from expected patterns, and retain evidence that can be independently checked. That is the deployment problem Helixar is designed to address.