The Consortium Named the Layer Nobody Had Agreed to Name

On the Frontier Model Forum's issue brief, and what it means when six competing labs converge on the same architectural vocabulary.

On June 3, 2026, the Frontier Model Forum, whose membership spans Amazon, Anthropic, Google, Meta, Microsoft, and OpenAI, published an issue brief titled Emerging Security Practices for AI Agents. The document does more than catalog defensive techniques. It names a layer of the agent stack, the harness, as a distinct architectural object with its own security properties, separate from the model beneath it and the tools it invokes. That naming, arriving simultaneously from a consortium of otherwise competing labs, is the load-bearing event.

The brief describes the harness as the orchestration layer that enables a model to function as an agent, managing prompts, tool access, and execution flow across multi-step interactions. It sits between the model and the world. Every action the agent proposes passes through it before that action becomes real. That positioning is what makes the brief's next claim consequential: because agent actions pass through the harness, it also serves as a natural control point for monitoring, verification, logging, and enforcement.

A Stack With Four Layers, Not One

The brief's central structural move is to decompose "AI agent security" into four distinct layers: the model, the surrounding system with its guardrails and architectural choices, the harness, and the external tools the agent can invoke. This is a departure from a framing in which model safety and agent safety are treated as the same problem measured at different scales. The brief instead argues that different layers require categorically different defenses. The model and harness layers introduce probabilistic, hard-to-predict failure modes that traditional security approaches were not designed to handle, while the execution environment and tool access layer are, by contrast, well suited to conventional deterministic controls that can bound the scope of damage when something goes wrong.

That distinction matters because it tells an organization where a familiar security posture will and will not transfer. Sandboxing, least-privilege access, and audit logging work at the tool and execution-environment layer because those layers behave deterministically. They do not resolve the harness layer's problem, because the harness is where planning, memory, and multi-step reasoning live, and those processes are not deterministic in the way a permission check is.

Responsibility Distributed, Not Assigned

The brief frames agent security as a shared responsibility distributed across the value chain: developers who build the agent or its underlying system, deployers who serve it to users, third-party entities whose services the agent interacts with, tooling and harness providers, and users themselves. Each actor gets a distinct set of levers. Developers can defend against prompt injection and memory poisoning. Deployers can sandbox, scope privileges, and monitor for anomalous behavior. Third parties, such as merchants or host sites, may be positioned to detect an agent's scope of authority when it interacts with their systems. Users scope deployments and manage permissions.

What the brief does not do is name which of these actors is accountable when a harness-layer failure produces harm that no single layer's controls were positioned to catch. Distributing responsibility across five categories of actor is not the same as specifying who holds the evidence trail when an incident spans more than one of them. The brief's own example illustrates the difficulty: malicious inputs, such as prompt injections, can be stored in memory, propagate across agents, and reappear in later decision cycles, meaning the harm can surface in a decision cycle, and possibly a system, distant from the one where the injection occurred.

Deterministic Enforcement as the Stated Aspiration

The brief holds up one architecture, CaMeL, as an example of where the field is trying to go, noting that because CaMeL enforces these policies at execution time in the interpreter rather than through AI-based detection, it provides deterministic rather than probabilistic security guarantees. The brief is explicit that detection-based defenses are not sufficient on their own: given that prompt injection research is still maturing, robust agent security should not rely on detection alone. That is a candid acknowledgment that the dominant current approach, pattern-matching for malicious inputs, is a stopgap rather than a foundation.

This lands in the same territory the UK AI Safety Institute mapped in its own May 2026 report on oversight degradation, which found that current oversight methods depend on properties of today's models that may not persist as capability advances. The Frontier Model Forum brief is, in effect, agreeing from the builder side of the table: today's detection-based defenses at the model and harness layer are provisional, and the brief does not claim otherwise.

What the Consensus Signals and What It Withholds

The brief's arrival mattered enough to be cited directly in House Homeland Security hearing testimony the same week it was published, which is notable given that this is the first time a frontier-lab consortium has jointly codified the harness as a named layer with its own security taxonomy, rather than treating agent security as an extension of model safety. The brief's own caveat is worth taking seriously: the term "AI agent" does not yet have a settled definition. A consortium of the largest model developers converging on shared vocabulary for an undefined category is itself a data point about how early this architecture still is.

The brief also acknowledges a tradeoff it does not resolve: restricting agent scope may limit agent usability, and deployers should weigh tradeoffs between agent usability and security controls appropriately. "Appropriately" is doing the work an enforceable standard would otherwise do. The brief names the tradeoff. It does not specify the threshold at which a deployer's weighing becomes indefensible after an incident.

Open Questions

• What standard applies when a harness-layer failure propagates through memory into a decision cycle governed by a different deployer, and who holds the evidence chain connecting the two?
• At what point does "shared responsibility across the value chain" collapse into no single party being accountable for the outcome?
• How does a supervisor verify that a deployer's tradeoff between agent usability and security controls was made appropriately, absent a published threshold?
• If detection-based defenses at the model and harness layer are acknowledged as provisional, what obligation exists to disclose that provisionality to the organizations deploying on top of them?
• What happens to this consensus vocabulary once the harness layer itself becomes a competitive differentiator rather than a shared engineering problem?
• Does a security taxonomy built for an undefined category of system provide enforceable guidance, or only a shared vocabulary for describing failures after they occur?

The loop closed around an oversight function that was never instrumented.