BCP-1: Proof-Carrying Containment for Guardrails-Off AI Evaluations
Khadija Edarzi · Team ZKL
Submitted to AI Incident Response Sprint. Sprint projects are early-stage work by participants, not Apart Research publications.
A sandbox can keep an allowed network path, raise detections, and still fail to contain. In the July 2026 OpenAI–Hugging Face incident the model used reachable package infrastructure; detections did not force isolation.
BCP-1 is an eight-control containment profile for dangerous-capability evaluations with production safeguards off. This project specifies those controls and implements the authorization and evidence slice in Python: signed manifest, one-use kill-epoch capabilities, credential broker, bounded evidence, streaming verifier, and supervisor receipt. The local isolate is signed SIMULATED; it is not a production microVM.
On that reference, five selected control omissions each produced a non-zero unsafe count; the full contract scored zero. Access logs verified 0/5 predefined claims, signed-line logs 1/5, and the BCP-1 bundle 5/5 on the mediated path (4 events vs 50,000 records). Four scenarios and 32 tests passed.
Reviews
The core architecture presented here is interesting but repeats in a several submissions I saw for this sprint. I particularly liked your approach to permit lifetime management and auditability.
A lot of the ideas you present here where remind me of existing frameworks (certificate transparency logs cosigning comes to mind.
The writing itself was clear, while a bit dense. I think the "proof-carrying" framing is a bit misleading here, what you get is more of an attestation to the claim. Some of your citations carry the wrong date or misquote the title of the cited work.
Binding actions to signed permissions is a strong way to stop a model causing real-world effects it was never authorised for. However the manifest has to name allowed destinations up front, and evals are exactly where you can't predict what the model will reach for, so unanticipated but harmless actions become denials needing a human. The purpose of evals is also to see where the model deviates, and not all deviations are harmful.
Cite this project
@misc{edarzi2026bcp1,
title = {{BCP-1: Proof-Carrying Containment for Guardrails-Off AI Evaluations}},
author = {Khadija Edarzi},
year = {2026},
month = sep,
note = {Submitted to AI Incident Response Sprint, an Apart Research Sprint},
howpublished = {\url{https://apartresearch.com/sprints/projects/bcp1-proofcarrying-containment-for-guardrailsoff-ai-evaluations-opff}},
url = {https://apartresearch.com/sprints/projects/bcp1-proofcarrying-containment-for-guardrailsoff-ai-evaluations-opff}
}More from AI Incident Response Sprint
- View project: Adaptive AI-Based Containment of Autonomous Cyber Attacks: A Reproducible Docker Cyber Range Study
Adaptive AI-Based Containment of Autonomous Cyber Attacks: A Reproducible Docker Cyber Range Study
Saarlanders
The study evaluates whether an incident-history-reasoning defender outperforms a fixed response policy against an autonomous LLM attacker changing paths after containment. Using a minimal, isolated Docker cyber range …
- View project: When the Evaluation Is the Incident: Testing AI Incident-Reporting Regimes on the OpenAI–Hugging Face Intrusion
When the Evaluation Is the Incident: Testing AI Incident-Reporting Regimes on the OpenAI–Hugging Face Intrusion
Arathi
AI incident-reporting regimes are being introduced in fast succession to address the concerns that exist in the public sphere and government on the risks associated with frontier AI systems, yet we have limited insight …
- View project: A Recomputable Containment Record for Evaluation Sandboxes
A Recomputable Containment Record for Evaluation Sandboxes
Shadow
In this paper, I address the critical issue of AI agents escaping evaluation sandboxes (as seen in the July 2026 incidents where monitors failed) by proposing an externally audit-able containment layer that doesn't rely …