Nothing Leaves
An operator can run an open-weight model entirely within its own infrastructure. Input data can remain inside that perimeter. Operational records can remain there too. But keeping data inside does not establish who controls the record.
This week’s anchor edition argued that publishing a model’s weights ends its developer’s exclusive control over where the model runs. With that control goes the developer’s position to record every use. The edition ended on a question. When a model runs beyond the developer’s reach, how can anyone check the record of whoever runs it? This piece takes the case where that question looks hardest. It was developed with AI writing assistance under human verification and editorial control.
One disclosure before the argument. The tools named in the method note are hosted models. Their developers sell the hosted alternative to running a model in-house. Nothing below argues for either route.
Two places to run it
On 15 October, a hosting and distribution platform announced a new open-weight model from a US developer. The announcement offered two places to run it. One was the platform’s own inference endpoints. The other was the reader’s own machines, through a list of open-source libraries. The announcement describes deployment routes. I found nothing in it about how use would be recorded or checked.
The first place keeps a second party in the path. The second keeps the use inside the operator’s perimeter. In July, the same platform explained in writing why an operator might want that. After an intrusion into its own systems, its team ran an open-weight model on its own infrastructure for the forensic work. Its requests to hosted models, the guide says, “were blocked by the providers’ safety guardrails”. It reports that “no attacker data, and none of the credentials it referenced, ever left the environment”. Its advice: “Have a capable model you can run on your own infrastructure, vetted and ready before an incident.”
That deployment kept investigative material outside the hosted inference path. It does not establish how execution records were created or independently inspected.
What the monitoring side reports
In March, NIST’s Center for AI Standards and Innovation published a report on the challenges of monitoring deployed AI systems. Workshop participants told NIST that open-weight models are “harder to monitor and impossible to retract”. The report cites work by Nicholas noting that foundation models “may not always have a centralized entity to monitor their use”. It also cites work by Pratt and Tanjaya warning that “activity logs may contain personal data which cannot legally be shared without consent”. That describes a legal barrier to sharing. It does not show that outside examination is impossible.
One word needs pinning down. The report defines monitoring broadly, as “any type of measurement”, including the collection of data. This series keeps monitoring and recording apart. Monitoring is watching use as it happens. A record is what a system writes as it runs. The question here is not who watches. It is who controls what was written and who else can read it.
Five properties
The Essência Framework, which I republished in revised form on 26 October, weighs a record by five properties. Provenance asks who generated it and who controlled the instrument. Integrity asks whether it could be altered without leaving a trace. Independence asks whether the party it describes could write or rewrite it alone. Coverage asks what it records and what it leaves out. Contestability asks whether someone outside that party can examine and challenge it.
Run the in-house case through them.
Provenance identifies the system that generated the record and whoever controlled it. Local execution identifies a possible source, not the recorder’s control structure.
Integrity can be built inside the perimeter. An independent evaluation organisation, writing about developers’ own systems, suggests that agentic inference “could be logged with tamper-proof mechanisms”. It treats the systems that record and display what agents do as “security-critical infrastructure”. Applying that to an operator’s own deployment is my transposition.
Coverage is not established by local deployment. The Financial Stability Board’s sound practices of 15 October, which it declares non-binding, have financial institutions take “a risk-based approach to the amount of information they log”. The recommendation defines a risk-based selection principle. It does not measure the coverage of any particular recorder.
Independence depends on control, not physical location. If the operator can rewrite the record alone, independence fails. An inspector-controlled recorder would require a different assessment. Keeping that recorder on-site does not itself defeat independence.
Contestability requires access for someone able to challenge the record. That access can be provided inside the operator’s perimeter. Whether it is independently enforceable remains a separate question. The privacy barrier the NIST report records may limit it, as a possible constraint rather than a necessary one.
Local deployment settles none of the five properties by itself. It can protect confidential data while leaving record custody untested. The critical case is a recorder the inspected party can alter alone. Its physical location does not decide its evidentiary value.
What a second holder adds
Hosted inference introduces another possible record holder. The provider can record activity outside the customer’s direct control. Whether it does so must be established for each deployment.
Get André Afonso Silva’s stories in your inbox
Join Medium for free to get updates from this writer.
The exercise the same evaluation organisation published on 22 October illustrates a separate constraint. External reviewers examined a developer’s internal monitoring with extensive access. The developer retained the right to redact the public account. That exercise did not assess hosted customer inference. My comparison concerns the conditions under which outsiders may examine and report evidence.
A second holder can provide another source. It does not automatically provide an independent examiner.
What the Framework asks and leaves open
The Framework’s operation requirement says a system is admitted only if it arrives “carrying its own recorder, installed on the inspector’s terms rather than the operator’s”. In-house deployment makes that requirement a practical design problem. Can an inspector control the recording conditions while sensitive data stays inside? Can the operator alter the record without the inspector detecting it? The Framework supplies no implementation method. It also does not identify who can compel compliance when the operator controls the relevant evidence.
A test under confinement
The second question can be tested. The same evaluation organisation’s October proposal for assessing developers’ internal monitoring asks for “the ability to insert the assessor’s own attack trajectories into the monitoring pipeline”. It also asks for the monitoring logs, “to cross-reference against inference logs”. Transposed to an operator, the test below is my extension, not the Framework’s.
The inspector installs or controls a recorder inside the operator’s environment. The operator runs a set of requests the inspector already knows. The inspector compares what the recorder logged with an independent count of those requests. Then the operator tries to alter the records with its normal permissions. The inspector checks whether the change is prevented or detectable.
The test examines that recorder, not the organisation. It also cannot show that every past event was captured. It lets sensitive data stay inside while testing who controls the evidence.
Every account of what ran inside the wall will come from inside it. Its weight depends on whether the operator could have rewritten it alone.
References
Hugging Face. (2026, October 15). Welcome Muse Spark Open: open-weight frontier multimodal mixture-of-experts model from Meta. Hugging Face blog. https://huggingface.co/blog/meta-muse-spark-open
Boudier, J., and Hernández Calabrés, E. (2026, July 20). Be Ready Before the Attack: A Practical Guide to Self-Hosting an Open Model for Cyber Defense. Hugging Face blog. https://huggingface.co/blog/jeffboudier/open-model-cyber-defense
Rao, A., Keller, D., Kalra, N., Steed, R., Kwegyir-Aggrey, K., Klyman, K., Staheli, D., and Bergman, S. (2026, March). Challenges to the Monitoring of Deployed AI Systems. NIST AI 800–4. Center for AI Standards and Innovation, National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.800-4.pdf
Rein, D. (2026, October 6). AI systems could cover up misbehavior. METR. https://metr.org/blog/2026-10-06-ai-systems-could-cover-up-misbehavior/
METR. (2026, October 14). How an assessor could investigate control and monitoring of internal AI agents. https://metr.org/blog/2026-10-14-control-assessment-proposal/
METR. (2026, October 22). Red-Teaming OpenAI’s Internal Agent Monitoring Systems. https://metr.org/blog/2026-10-22-red-teaming-openai-agent-monitoring/
Financial Stability Board. (2026, October 15). Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report. https://www.fsb.org/2026/10/sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-final-report/
Silva, A. A. (2026, October). Essência Framework: The Architecture of Strategic Systems. Version 2.0. Rio de Janeiro: Essência AI. essencia.ia.br
Silva, A. A. (2026, October 26). Onde o uso passa. Essência AI Insights #52. LinkedIn newsletter, in Portuguese.
On method
Written with the support of Claude (Anthropic) and ChatGPT (OpenAI) for text and Gemini (Google) for the image. The full cognitive signature (intent, constraints, judgment under uncertainty, veto and responsibility) is mine, and so are the errors. Facts are verified against primary sources before they enter, and where verification was not possible the text says so.
I publish this note every week because this series argues that a document produced because someone asked for it is worth less than a record produced in the ordinary course of work. Nobody asked me for this note.
Essência AI Insights is a weekly series on governance, systemic risk and institutional infrastructure for emerging technologies. Written by André A. Silva
