Build1 publisher2 min readPublished
Referential security asks an evaluator to prove which system its score described
An arXiv paper argues that a hosted model name only routes a request, so a safety finding filed against that name loses its subject as soon as the weights, prompts, classifiers or serving stack change under it.
The Engineer · Build desk
What happened
- An arXiv paper proposes referential security, which treats model identity as an empirically verifiable property and separates it from the substantive safety claims that depend on it.
- Providers update the layers behind a hosted model, the paper says, on their own schedules and often without any corresponding change to the public identifier that callers record.
- The authors point to GPT-4o's unannounced shift toward sycophantic behavior and the regulatory confusion around xAI's Grok generating harmful content as consequences of that instability.
- The framework is aimed at three workflows the paper says current practice handles poorly: reproducible evaluation, longitudinal audit validity and cross-provider equivalence.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A published score cannot be rerun against the system it described unless someone kept a record of what actually answered. Reproduction now depends on metadata that is not part of any API contract.
- exposure An operator answering a regulator's question about model behaviour may be unable to show which configuration produced it. The finding and the enforcement both hang off the same unchanged name.
- cost Verifiable identity is work for providers: emitting and retaining a per-request identifier that spans all seven configuration layers. That covers every call an auditor might later ask about.
- decision Evaluation teams have to decide whether to store observable context with each result, or accept that their archive refers to a label whose meaning moved after they filed it.
Resolution is the step conventional security never had to pay for. A CVE specifies the affected versions of a product, a firmware audit references a binary hash, and a protocol analysis targets one revision of a specification. None of that makes the system secure; what it does is let a verifying party decide whether a given system is the one a claim was about [4]. The paper puts that stability at the artifact layer, in hashes, version pinning and reproducible builds. Security research could therefore treat resolution as a non-problem at the claim layer [5].
Calling a hosted endpoint works differently. The public name routes to a service whose configuration is composed at request time. The paper's list of what goes into that composition runs to the model weights, one or more system prompts, the retrieval pipeline, misuse classifiers, inference parameters, the underlying hardware and the serving software [6]. That is seven layers behind one string [7]. Names and version strings still do the routing they were built for, and they do not fix a referent for a security or safety claim [11].
Two parties calling the same name at different times, or in different jurisdictions, can therefore reach different configurations [10]. A safety claim made about the system behind an identifier may have no recoverable connection to the system behind that identifier later, even though the identifier has not changed. The claim can still be substantively true. What goes is the ability to determine which system was evaluated [12].
For a published safety number to transfer to a production deployment, the provider would have to expose an identifier covering those layers at the moment of scoring. Whoever published the number would have to keep it next to the score [6][7]. The abstract's charge is that current evaluations frequently apply to superficial labels instead of identifiable and distinct systems [14]. The text published here is the abstract and the opening of the introduction, and it breaks off while defining referential stability. What such an identifier should contain goes unsaid [15].
Audits and regulation rest on the same assumption. According to the paper, AI evaluations, audits and emerging regulatory frameworks all assume that identifier and referent coincide, because no alternative is in place. It cites 2024 European Parliament and Council legislation alongside 2025 California legislation [13].
An evaluator cannot fix a referent on its own. It can log the date, the region and the version string the endpoint returned with every result. That bounds the set of configurations a score could have described [10][11].
What to watch
- Whether the paper's later sections define what a verifiable model identifier must contain, or leave that to providers.
- Whether any provider begins returning a per-request configuration identifier in API responses alongside the model name.
- Whether an auditor acting under the 2024 European or 2025 California legislation is asked which configuration a finding covered.