GHOST: the risk of an agent forgetting a critical constraint many turns later

A forgotten constraint can become an execution risk

An agent working across many turns may receive a safety instruction early in an interaction and later propose an action that conflicts with it. The preprint introduces the term GHOST—“Governance Hazard from Overlooked Safety Constraints across Turns”—for this kind of failure: an applicable constraint goes unheeded during an interaction, and the agent executes an action that violates it. The abstract warns that the consequences could be irreversible, although the information available does not describe real-world incidents or quantify any resulting harm.

The authors emphasize that this can happen in a benign interaction: a new malicious instruction does not have to be introduced for the risk to arise. That does not mean every violation of a rule is GHOST. The term refers to a possible disconnect between a safety condition communicated earlier and an action proposed much later in a multistep task.

This distinction changes the safety question. It is not enough to identify hostile instructions in the current turn; systems also need to check that relevant rules continue to govern each later action. Still, the abstract does not establish the specific cause of the lapse. It does not show whether the issue comes from a long interaction history, memory management, planning, or some combination of factors.

What is known about the tests—and what is missing

The paper’s abstract reports experiments with GPT-5.5 and gives a GHOST event rate of 11.5% for that setup. It also says that no GHOST events were observed when STAR-Guard was used with GPT-5.5 in the experiments described. These are results reported by the preprint, not a universal measure of agent behavior or a guarantee of safety.

The information provided does not specify how many tests produced either result, what tasks were performed, which environments were used, or how an event was operationally defined. It also does not make clear whether other models were included, or whether the 11.5% is calculated per action, per task, or using another unit of analysis. Without these details, it is not possible to assess statistical precision, compare conditions, or reproduce the result.

The record identifies the work as a preprint: a publicly available manuscript that should not yet be treated as validated through peer review. That status does not automatically invalidate the experiment, but it does make it important to distinguish what the authors report from what independent evaluation has confirmed. In this case, no independent corroboration of the figures is available.

STAR-Guard combines rule retrieval with a pre-execution audit

The paper proposes STAR-Guard as a two-layer defense. The first layer aims to restore historical safety constraints that remain applicable, reducing unsafe proposals. The second performs a deterministic audit before execution, with the goal of preventing any residual violation from reaching the environment. The abstract attributes the absence of observed events with GPT-5.5 to the setup that includes this defense.

Separating proposal from execution matters. A model may produce an action that seems reasonable in the immediate context but violates an earlier rule. If an external check blocks that action before it has an effect, protection does not depend solely on the model remembering and correctly applying every instruction throughout a long conversation.

But “deterministic” does not mean infallible in every use. Assessing the audit would require knowing how constraints are represented, how the system decides whether they apply, which actions it can inspect, and what happens when a case is ambiguous. The available abstract does not provide those details, nor does it confirm whether code, data, or public artifacts are available to reproduce the system.

The theoretical argument is not a deployment test

Alongside the experiments, the abstract presents a theoretical result: if the residual conditional risk of violating a constraint at each safe prefix is bounded below by a nonsummable sequence, execution almost surely enters a hazard region. Put simply, the claim describes a possible accumulation of risk across a sequence of steps, subject to the stated mathematical conditions.

That result does not say that all agents will inevitably fail, or that the condition always holds in real conversations. Applying the conclusion would require establishing how a safe prefix is defined, how conditional risk is estimated, and whether the relevant sequence satisfies the required property. The available information does not provide enough data to answer those questions for commercial or general-purpose systems.

It is therefore useful to keep three levels separate: the proposed definition of GHOST, the empirical results reported for a particular setup, and the theoretical conclusion under specified assumptions. Combining them could turn a warning about a plausible risk into an unjustified claim that the failure is inevitable or common in every long-running agent.

Controls worth considering before the full scope is known

The practical response should not consist solely of expanding the context window. The problem described is that an older constraint may not govern a later action; retaining more text does not prove that an agent will retrieve it, interpret it correctly, or comply. For critical constraints, an architecture can combine explicit memory, contextual retrieval, limited permissions, and an external check before execution.

The potential impact matters too. A reversible, low-risk action may call for different oversight than a transfer, data deletion, or persistent system change. As a precaution, sensitive operations can require confirmation, be limited to a narrow scope, or stop when it is not possible to resolve whether a constraint applies. These are design recommendations; the abstract does not say that the study tested each one.

The table below is a general decision aid, not a protocol certified by the preprint. The right choice depends on the system, its permissions, and the consequences of an error.

What remains unknown about whether the finding generalizes

Assessing the result’s scope requires, at minimum, details of the tasks, environments, constraints, sample sizes, and the unit used to calculate the rate. It would also be necessary to know the event annotation criteria, comparison conditions, and how STAR-Guard handles contradictory constraints or rules that are difficult to retrieve. The available abstract does not provide enough information to fill in these details.

Reproducibility is another open question. The information provided does not confirm whether experimental data, code, or artifacts are accessible. Without them, other teams cannot directly check how the scenarios were generated or whether changes to prompts, tools, memory, or the model affect the observed frequency.

The provisional conclusion is limited: the preprint proposes a failure mode relevant to agents operating over many turns, reports 11.5% in one GPT-5.5 setup, and says that no events were observed when STAR-Guard was added in that same setup. This is a reason to design and evaluate execution controls—not proof that every agent experiences GHOST, or that STAR-Guard eliminates the risk in every context. Our news, comparisons, and discovery sections can help readers follow future evaluations; none of those comparisons substitutes for examining the full paper.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.