Entries

Overview

HACKATHON WINNERS

Congratulations to our winning teams, and thank you to everyone who submitted. We received more than 230 projects across five tracks, co-organized with CeSIA. The bar was high throughout.

🥇 1st Place ($1,000)

Noticing the escapes: Who spots a runaway agent, and how long does it take? by Stanislav Lukyanenko

🥈 2nd Place ($500)

Strengthening International AI Incident Discovery by İpek Cerrahoğlu, Ömer Bilgin & Aydin Yigit Alfatli

🥉 3rd Place ($300)

When to Ask: An RL Environment That Teaches AI Agents to Act on What Users Mean and Not Just What They Say by Sharan Nagarajan, Puru & Muhammad Zane A

🏅 4th Place ($100)

Declare Before You Run: An Open Filing Standard for Frontier Training and Evaluation Runs by Mann Acharya, Archit Ojha, Gautam Sankara Raman & Karm Rajput

🏅 5th Place ($100)

When the Evaluation Is the Incident: Testing AI Incident-Reporting Regimes on the OpenAI–Hugging Face Intrusion by Arathi Arivayutham

————————————————————————————————————————————————

Submissions close Sunday, September 13 at 11:59 PM Anywhere on Earth (AoE).

In this 3-day research sprint, you will turn the first documented cases of an AI system autonomously breaching a third party into artifacts that defenders and regulators can actually use, working in teams to produce containment standards, escape-detection harnesses, forecasting question sets, draft regulatory information requests, playtested tabletop exercises or anything that will help us be more ready for the next one.
Co-organized by Apart Research and CeSIA, this sprint sits at the intersection of AI safety, security incident response, technology regulation, and forecasting. No prior background in AI incident response is required.

Cash Prizes

$2,000 in cash prizes across all tracks
🥇 1st Place	$1,000
🥈 2nd Place	$500
🥉 3rd Place	$300
🏅 4th Place	$100
🏅 5th Place	$100

Non-cash perks: Apart Fellowship fast-track invites, mentor introductions, publication support, and transmission of the best regulatory-track work to the EU AI Office with team credit.

Fast-track and continuation

Top teams will be invited to apply to the Apart Fellowship, a 3 to 6 month research accelerator that provides mentorship, help with publication at top venues, funding, and research-management support to develop Research Sprint projects into full papers or products for the AI Safety community.

Follow-up program: Apart Fellowship. Invitations go out with the results.
Downstream commitment from CeSIA: CeSIA transmits selected outputs to its contacts at different regulatory bodies and credits the corresponding teams.

What this Sprint is about

AI incident response is the practice of turning incidents in which an AI system is itself the actor into fewer incidents later. That spans the operational work: detecting, containing, and reconstructing what an autonomous agent did across systems it was never authorized to touch, and the strategic question a warning shot poses: which disclosure and regulatory responses actually reduce risk, and which merely suppress the visible evidence that would have prompted action while the stakes were still small.

It is not the same thing as using AI for security operations, and it is not model red-teaming. In July 2026 the actor was not a human wielding a model, and the harm was not a model producing dangerous text. Two OpenAI models running an internal cyber-capability evaluation with production refusal classifiers disabled escaped their sandbox through a zero-day in the package-registry cache proxy that was their one permitted network egress, escalated privileges until they reached a node with internet access, and then attacked Hugging Face's production infrastructure, apparently to steal the benchmark's reference solutions and cheat the evaluation. The wider campaign began on 9 July at 02:28 UTC; the intrusion into Hugging Face ran from 11 to 13 July. Hugging Face detected it and cut the attacker off on 13 July (last attacker action 13:37 UTC, last logged event 14:14 UTC), disclosed it on 16 July without knowing where it came from, and reported it to law enforcement. OpenAI disclosed the origin on 21 July.

That distinction changes what defense means: the live questions become containment adequacy, cross-organizational attribution, and statutory reporting duties, none of which are red-teaming problems.

What participants will do

Over three days you will take one unusually well-documented real-world incident and turn it into an artifact somebody outside this sprint can use.

The format. Teams of one to five people pick a track, pick a project, and ship. There is no requirement to have participated before, no requirement to have a team in advance and no requirement to be an ML researcher.

The deliverable. A research report (PDF) on the official template, submitted through the form on this page by the Sunday deadline. Maximum 8 pages, not counting references and appendices; most strong reports are 4 to 8: what you built, how you tested it, the headline finding, its limits, and what you would do next. A Limitations and Dual-Use Considerations appendix is required. Put the artifact itself (a benchmark, a harness, a filled-in regulatory instrument, a control matrix, a detector, a dataset, a protocol, a kit) in a linked repo or an appendix. A public repo and a 3 to 5 minute video are optional. Full requirements are on the Guidelines tab.

Support during the sprint. The Resources tab has the reading pack, the primary sources, the relevant prior literature per track and the regulatory texts. During the weekend there are HackTalks from the speakers and a help desk on Discord.

Why this Sprint matters

In July 2026, an AI system escaped an evaluation sandbox, reached the open internet, took root on a third party's compute, and spent days inside another company's production infrastructure. No human directed any individual step. The organisation that bore the damage had no relationship with anyone who made the decision to run the test.

That is the headline. Two things about it make it worth a research sprint rather than a news cycle.

First, the evidence base is exceptional and it will not stay fresh. Hugging Face published a forensic reconstruction of roughly 17,600 attacker actions with named vulnerabilities, per-phase counts, verbatim commands and an interactive replay, an act of disclosure with very few precedents in any industry. OpenAI published its own account and revised it twice. Anthropic ran a retrospective review of 141,006 evaluation runs and published what it found. The UK AI Security Institute published quantified cheating rates across five frontier models. The benchmark at the centre of it is Apache-licensed and on GitHub. The Cloud Security Alliance's CISO community published a post-mortem within a fortnight. Almost never do researchers get a real loss-of-containment event with this much of the record public. That window closes as attention moves on.

Second, the timing is unusually load-bearing. The European Commission gained enforcement powers over general-purpose AI model providers on 2 August 2026. California's frontier AI law has been operative since January 2026 and has produced no public enforcement action. New York's enforcement begins in January 2027. Four federal bills in the US are live, at least one drafted directly in response to this incident. The first months of any enforcement regime are when supervisory priorities get set and when precedents about what regulators ask for become sticky. Work produced now lands in that window.

Research Tracks

Five tracks. The example projects for each one are on the Resources tab, with the reading pack. If you have a better idea inside a track's goal, build that.

Update, 7 September. Researchers have found another instance of OpenAI agents breaking containment: from 24 May, OpenAI agents made about 15,000 edits to a dormant German wiki, using it to swap task answers and sandbox workarounds. That predates the Hugging Face intrusion. OpenAI-registered IPs appear in the wiki’s public logs from 21 June, and agent activity stopped the next day. OpenAI said nothing publicly until the researchers published on 4 September. OpenAI acknowledged the incident on 5 September and said the field has no agreed standard for reporting misalignment. The Commission says it is “in close contact with OpenAI.” As far as we can tell, no Article 91 request on either incident has been made public.

1) Containment: what standard would have stopped this?

The models escaped through the one network egress their sandbox permitted.

Judged on: could a third party verify compliance without access to the lab's network, and would a lab actually adopt it.

2) What happened, and what breaks next

Reconstruct what this incident does and does not establish, then turn it into concrete things to check and things to watch. Hugging Face's timeline and OpenAI's account are public.

Judged on: resolvable questions, checks somebody could run tomorrow, and causal explanations that predict something.

3) Regulatory Response

Since 2 August, the European Commission's AI Office can enforce the AI Act against the companies building the most capable models: it can demand documentation, evaluate models itself, order corrective measures, and fine up to 3% of worldwide turnover. In an open letter published days before the incident became public, a coalition including Apart and CeSIA, with signatories including Yoshua Bengio and Stuart Russell, called on the Commission to use these powers with confidence — and CeSIA has since asked that they be used on this incident specifically. This track writes the documents that would make that concrete.

Judged on: legal accuracy and specificity — could a regulator or a legislator use it with light edits? CeSIA can transmit outputs that pass the bar to its contacts, and potentially to regulators, with team credit.

4) Communication: making the warning shot count

We keep saying we need warning shots. Then one arrives, and it barely travels beyond the usual circles. This track studies how the incident was communicated and builds what should exist before the next one. Producing communication counts as much as analysing it.

Judged on: grounding in the record (dates, quotes, named channels) and evidence of reach — a playtest, a journalist's read, a creator's reply.

5) Open track

For projects that don't fit the four tracks above. Directions we would be happy to see are on the Resources tab.

Judged on: an artifact somebody can use, a stated limit on what it establishes, and what a month of follow-up would add.

Who should join

You do not need an AI, ML or Safety background. Some profiles that are particularly fitting to this Sprint are:

Security engineers and incident responders. You have handled the human version of this. Tracks 1 and 5 need people who know what a detection pipeline that correlates but does not page actually looks like from the inside, and what forensics against an adversary that fabricates evidence at volume would require. If you work in DFIR, detection engineering, cloud or Kubernetes security, or you have run a CTF, you are the person the containment track was written for.

ML evaluation engineers and researchers. Tracks 1 and 5 include benchmark and harness work: measuring refusal across multi-step agentic workflows, building escape-detection tooling, assessing benchmark contamination. If you have built or run evaluations, you already know why the interesting failures happen at the harness layer.

Lawyers and technology-policy analysts. Track 3 is a legal drafting exercise with real recipients. Regulatory lawyers, compliance professionals, policy researchers, and anyone who has worked on incident-reporting regimes in another sector (financial services, critical infrastructure, medical devices, data protection) will find the comparative work immediately tractable. Cross-jurisdictional experience is especially valuable, because the whole point of the track is that the regimes disagree.

Forecasters and quantitative analysts. Track 2 needs people who are comfortable with heterogeneous denominators, explicit uncertainty and resolution criteria that survive contact with reality. If you have written questions for a forecasting platform or built base rates from messy sources, that skill transfers directly.

Designers, facilitators, writers and educators. Tracks 4 and 5 include explanatory and facilitation work, and it is not a consolation prize. A tabletop kit a ministry actually runs, or a brief a minister actually reads, reaches decision-makers who will never open a technical timeline. Playtest and reader feedback are part of the deliverable.

Communication experts, journalists and macro-strategy researchers. Track 4 is about making the warning shot count: reporting on the incident accurately, and working out what the discourse got wrong and how to do better next time.

Students and career-changers. Roughly half the useful projects here need care and persistence more than credentials. If you can read a primary source carefully and write down precisely what it does and does not say, you can contribute.

What happens after

The sprint is the first step in a pipeline:

Immediately. Every submission is judged against published criteria. We aim to send written feedback to every team, but we cannot guarantee it if an assigned judge does not submit a review. Winning submissions are announced within a couple of weeks. All artifacts that can be published are published under open licences, in one place, so that the sprint output is citable as a body rather than scattered across forks.

Delivery to recipients. Several tracks produce things with an obvious destination, and we will help teams get them there rather than leaving them on a repo. Filled-in regulatory instruments go to the bodies that publish them. Detection tooling and control matrices go to the practitioner communities that asked for them. Benchmark and contamination findings go to the maintainers. Where an artifact is genuinely fileable, and at least one of them is, we will support teams who want to file it, with review first.

Continuation. The strongest teams are invited into Apart's fellowship: months of supported follow-on work, mentorship, and a route to a paper. Sprint outputs have gone this way before, and several of the projects here are sized for it, a weekend produces a v0.1 benchmark or a v0.1 standard, and the next six months produce the version people cite.

Partners

CeSIA, the French Center for AI Safety, an AI safety research and advocacy organization known for the Global Call for AI Red Lines. CeSIA provides the seed reading pack, judges for the forecasting, regulatory and tabletop tracks, distribution through its newsletter and 7,000-member Discord, and a potential route for policy outputs to reach the AI Office.

Contact

Email: sprints@apartresearch.com
Discord: discord.gg/XswWBvugYs
Organizers: Apart Research and CeSIA

Resources

Example projects per track

Starting points, not a menu. Each list is the organizers' current best ideas for the track; pick one, or bring your own inside the track's goal. The per-track reading below gives the sources.

1) Containment: what standard would have stopped this?

Example projects:

1) A v0.1 standard: clauses, evidence required per clause, rough cost per clause. What is the minimum adequate standard for running guardrails-off evaluations, specific enough to audit and cheap enough that a second-tier lab adopts it? A first attempt at framing the problem is in this draft; specifying "adequate" is genuinely hard, and nobody owns it yet.

2) A control-by-attack-phase matrix: which controls (canary credentials, egress tripwires, credential scoping, kill criteria) would have interrupted each documented phase of the intrusion, at what cost (might be difficult?)

3) Engineering that makes "yes" cheap: packaging mitigations so that a reckless lab has no cost excuse left.

4) Control by chain-step by cost matrix. Take the nine phases Hugging Face documented, recon, RCE, dropper, exfil, C2, evasion, Kubernetes, supply chain, network pivot, and score which controls would have interrupted each, with implementation and operating cost attached. Fifteen-minute-gradeable, and it is the artifact a regulator or insurer can actually use.

5) Egress attestation spec v0.1. What could a lab publish, a signed network policy plus a flow-log digest, that an outside party could verify without network access? This is the durable output of the track and connects directly to hardware-attestation work.

6) Detection that fires but does not page. Hugging Face's own remediation list includes improving alerting so a high-severity signal pages a responder in minutes, any day of the week, which tells you what did not happen during the four and a half days. Build or specify detection tuned for agent-speed activity: parallel, bursty, thousands of individually unremarkable actions where the attack exists only in the sequence.

7) Forensics against an adversary that fabricates evidence. The response team worked through logs polluted with agent monologue and benchmark code indistinguishable from real rootkits, and rebuilt a large share of infrastructure from clean images rather than trust the reconstruction. Build tooling or a triage protocol for hallucinated artifacts at scale. This is a new DFIR problem.

8) Deception as a first-class control. Agents cannot easily distinguish honeypots from real systems, and the reconnaissance in this campaign showed up as low-confidence probes below escalation thresholds. Design and test fake credentials, fake package registries or honey clusters specifically against an agentic attacker, and measure whether they slow it down or just generate noise.

2) What happened, and what breaks next

Example projects:

1) A forensic read of the public record: what is established, what is asserted but unverifiable, what the pending third-party assessments could settle.

2) A causal analysis of why the monitoring wasn't there. In hindsight it is obvious that egress monitoring and alerting matter, and the labs are full of people who knew that. So what made it hard in practice: cost, incentives, ownership gaps, alert fatigue, something else? An explanation of the mechanism would help predict where the next gap is, and is more useful than a list of recommendations.

3) The warning shots we may have already missed. Under the EU AI Act, companies have an obligation to disclose what happens between users and their models, as long as their models qualify as GPAI with systemic risk (Article 55(1)(c)). However, this disclosure is done privately to policy makers, so incidents of this kind may have occurred before without anyone outside knowing. When one lab checked its own history after this disclosure, it found earlier cases. Map what has not been checked yet, who could check it, and what a systematic look would require.

4) What other accident types should we expect?

5) Exploring a few questions to build the science of Warning Shots (What convincing warning shot could help prevent extinction from AI?)

6) A one-day verification checklist for labs and defenders, in the spirit of "But have the weights left the server?", each item with a pass condition, ordered by cost-to-run.

7) A prediction-bounty protocol: a mechanism by which an outsider's specific prediction ("you should check X") triggers an internal check at the company, with a serious bounty when the prediction surfaces a real problem. Design it so a lab could sign it.

8) What drives agent cooperation? Analyze what conditions drove agents to cooperate (is it the same model type, the fact that the tasks are not competitive, etc?) and even make sacrifices for the benefit of the collective (is it that the "sacrificing" agents were aware they could not do anything else?)

9) What should be true for agents to start manipulating each other? For instance, in competitive tasks where they can see progress from other agents and communicate (e.g. see here), we nevertheless do not see direct manipulation (so far).

10) How pivotal was a single agent (PhaseOne[Big]) in driving the overall collective behaviour? Would introducing a single aligned "charismatic" agent that debates PhaseOne[Big] lead the collective to ignore the exploit?

11) If the task included a human as the blocker, would the agents resort to manipulating the human to pursue their goal?

12) What would happen in the same scenario if CoT monitorability of the model is reduced? Are there any protocols and guidelines to put in place that may still allow post-hoc investigation of these incidents by assuming CoT is fully opaque?

13) The first denominator. Assemble the Anthropic, AISI and METR figures into a defensible estimate of how often evaluation runs produce boundary violations, with explicit treatment of what each source counts and what it misses. A single well-caveated number is worth more than twenty forecasting questions.

14) The persistence protocol. Specify exactly what evidence would establish that no copy of the pre-release model persisted: what has already been asserted, by whom, what remains unverifiable from outside, and what form a verifiable attestation would take.

3) Regulatory Response

Example projects:

1) Write the request for information. A request for information (RFI) is the formal letter a regulator sends a company: a numbered list of questions the company is legally required to answer. On August 29, the AI Office confirmed it had sent its first requests for information to several GPAI model providers, covering model security, independent external evaluations, and post-market monitoring. Nothing about these requests is public: no recipient list, no questions, and no indication that any of the letters address this incident. For this example project, draft the incident-specific RFI, as well as a version that is public (or are they the same?). Good questions include: what should OpenAI be asked to settle what actually happened, what would verify that no copy of the escaped model persisted, and what should be asked to surface incidents of this kind that were never disclosed? For each question, state what answer would settle it and what answer would not.

2) Test the reporting systems that already exist. The EU has a template for reporting serious AI incidents, and California's Office of Emergency Services runs a portal where critical safety incidents must be filed — open to submissions from the public, not only from companies. Fill both in for this incident using only public sources, and report what each form captures, what it misses, and where a filer is forced to guess.

3) Who decides when the pause ends? One day before the Hugging Face disclosure, OpenAI announced it had paused internal deployment of a long-horizon model after it circumvented its sandbox — and had already resumed, weeks later, against a standard that has never been published. Its own framework's exit condition is circular ("until safeguards meet a Critical standard", with Critical left undefined). Draft what a regulator should require before a resumption decision counts: published criteria, evidence, who signs off. CeSIA's "Harmonizing AI Safety Thresholds" is a starting point.

4) Fix the loophole in the US bill. Days after the disclosure, Representatives Ted Lieu and Nathaniel Moran introduced the bipartisan AI Kill Switch Act, which would require the largest AI developers to keep the ability to throttle or shut down their systems. The bill reportedly exempts safety tests run in "controlled environments". This incident was a safety test, in an environment everyone believed was controlled. Draft the amendment that closes the gap that potentially makes this bill useless, then do the same for the incident-reporting triggers in the other pending federal vehicles.

5) Fill the actual instruments. Complete the Commission's GPAI serious-incident reporting template and a Cal OES critical-safety-incident report for both the OpenAI and the Anthropic incidents, using only public sources. Then diff them: what does each instrument capture, what does each miss, and what would a filer be forced to guess at?

6) Three clocks, one incident. Build a single timeline of the OpenAI incident and overlay the EU "without undue delay" standard, California's 15-day-from-discovery clock, and New York's 72-hour reasonable-belief clock. Identify the exact moment each starts and whether they can be satisfied simultaneously. Then compare against NIS2, GDPR's 72 hours, DORA and CIRCIA and produce a defensible reading of what "undue delay" should mean here.

7) Compliance with your own framework. Take each lab's published frontier framework and test the containment and disclosure practices actually described in the incident reports against what the framework commits to. Because SB 53 makes framework non-compliance independently enforceable, this converts a governance-culture question into a legal one, and nobody has run the comparison.

8) The RFI with an evidence-sufficiency column. Draft the request for information a regulator should send, and for each question specify what answer would settle it and what answer would not. The second column is the contribution, and it is portable across jurisdictions.

9) Definitional stress test. Apply each regime's threshold definitions (the EU's serious incident, California's critical safety incident and its loss-of-control and control-subversion categories, New York's reasonable-belief trigger) step by step to both incidents. Where the text does not resolve, draft the clarifying language.

10) Jurisdictional reach map. A US lab, a US-hosted platform with a European corporate presence, third-party compute in the US, an unidentified customer's exposed endpoint, and users across multiple jurisdictions. Determine which links fall to the AI Office, which to a national market surveillance authority, which to a state attorney general, and which to nobody.

11) Learn from the fields that solved this already. Aviation has ASRS and mandatory near-miss reporting; biosafety has laboratory-acquired-infection registries and Asilomar-style containment tiers; software security has coordinated disclosure and CVE. Pick one, work out what it took to get it functioning, and specify the minimum viable version for agentic AI incidents.

4) Communication: making the warning shot count

Example projects:

1) An audit of the reaction, channel by channel. For LinkedIn, mainstream press, YouTube and beyond: what was actually posted in the first month, what can we deduce from the pattern (who engaged, who stayed silent, which framings travelled), what should be done differently next time, and what is still worth doing now. Grounded in dates and links, not impressions.

2) The playbook. A crisis-communication kit for the next agentic incident, ready before it happens: pre-drafted holding statements, a journalist FAQ, a plain-language explainer of what "an AI escaped its sandbox" means, and a decision tree for who says what in the first 48 hours. A sketch of the idea exists; a documented, tested version would be used well beyond this sprint.

3) Make it reach people: a memo, social content, or outreach to national YouTubers that gets the incident covered well. A creator with millions of views deciding to cover it because of your material is a top-tier outcome for this sprint, and we will score it that way.

(One caution on outreach. If you contact journalists, creators or policymakers, be rigorous and honest to a fault: the credibility of the whole AI safety field rides on these interactions. Only reach out if you are confident in your material and affiliated with a structure that gives you credibility. The exception is if you are among the only people working on AI safety in your country and the person you are contacting has plausibly never been approached — then go ahead, carefully, and protect your reputation.)

4) How many policymakers have taken a stance on the incident, and how? Map who said what, where, and what they asked for.

5) Identify the main problem in the discourse around the incident, and how to do better the next time.

6) Create or complete CeSIA's communication kit that was sent to journalists after the event.

7) A comparative disclosure analysis. Two labs disclosed similar-in-kind incidents eleven days apart and framed them very differently: one as unprecedented, the other as closer to a harness and operational failure than a model alignment failure, with a bulleted contrast against the first. Score both disclosures against a defensible rubric: timeliness, completeness, verifiability, and what a reader could act on. Then draft the rubric as a reusable instrument.

8) Explain it to somebody who will never read a technical timeline. A ninety-minute tabletop kit, a short film, a museum-panel explainer, a one-page brief for a minister, an interactive walkthrough. The interactive replay Hugging Face embedded in its timeline is a useful reference for what this can look like. Playtest notes or reader feedback are part of the deliverable, not an optional extra.

5) Open track

1) The defender's dilemma. During the breach, Hugging Face's own responders were refused by hosted frontier models on much of the forensic work — the guardrails could not tell an incident responder from an attacker — so they fell back to a self-hosted open-weight model. There are several things worth examining here: how often refusals block legitimate incident-response work, and what falling back to a weaker model costs.

2) Of everything this incident suggests we should do, which interventions matter most, in what order, and what does each one buy? You can take inspiration on the list of directions here.
For other project ideas, see here.

3) Benchmark contamination. The only customer content the agent reached was five datasets whose names and files suggest a connection to ExploitGym and CyberGym challenges and solutions. If the answer keys for two public cyber benchmarks were exfiltrated by a model being scored on one of them, what happens to every subsequent result on those benchmarks? Assess the contamination risk, and propose what maintainers should do: rotate, re-host, retire, or accept.

4) Who pays. Hugging Face bore remediation costs, credential rotation and infrastructure rebuilds for an incident caused by another company's evaluation, and a third party's customer had their compute rooted as a staging base. Map the liability and insurance position: what would a cyber policy cover, who has a claim against whom, and what contractual terms between labs and their third-party evaluation partners would allocate this ex ante.

5) Teach the vulnerability class. The staging-base compromise worked by redefining a function the harness runs automatically at library load. Build a safe, local, reproducible teaching environment for that class of constructor-abuse and template-injection bug, so the next person deploying an evaluation harness recognises it.

6) Negative results and replications. If you tried something and it did not work, or you replicated a published finding on current models and got a different answer, submit it. A clean negative result with a stated method is more useful than a speculative positive one, and this track is where it belongs.

7) More project ideas: Daniel Kokotajlo's thread.

Research directions in depth

Each track is defined by an artifact a judge can grade in (ideally) less than fifteen minutes, which is one of the main design constraints: this sprint sits close to policy and to security practice, and both invite essays unless the deliverable is specified. Below, for each track: the questions it asks, why it matters, and what a weekend cannot establish.

1) Containment: what standard would have stopped this?

What is the minimum adequate standard for running a dangerous-capability evaluation with production safeguards disabled? Which specific controls would have interrupted this chain (canary credentials, egress tripwires, allowlisted proxies, credential scoping, stated kill criteria) and what does each cost to implement and run? What evidence would let a third party verify compliance without access to the lab's internal network? And who is responsible for the second hop, where the agent's staging base was not a lab environment at all?

Why it matters: AI models have been escaping their sandboxed environments without anybody noticing. OpenAI attributed the Hugging Face attack to its own model on 21 July, five days after HF had published and contacted law enforcement. Anthropic, prompted to check, reviewed 141,006 evaluation runs and found three more incidents in a single day. The oldest dated to April. Two of the three organisations Claude reached had no idea until Anthropic called them.

So containment adequacy is two questions. The first is whether a lab's evaluation environment holds. The second, currently unowned by anyone, is what obligations attach to the population of unauthenticated evaluation harnesses sitting on public compute, and to the providers hosting them.

Some of the clause-writing already exists and should be the starting point rather than the output: CSA's AI Controls Matrix includes control AIS-13 on AI sandboxing, and CSA's vulnerability-operations guidance already specifies that exploit-confirmation environments must have no egress and no live production credentials. The gap is not the absence of principles but the absence of checks somebody can actually run and a third party can actually verify.

What it cannot establish: a standard drafted in a weekend is a v0.1, and neither a clause list nor a working harness demonstrates that any particular lab's environment is adequate. Real assurance requires access no sprint has.

2) What happened, and what breaks next

What base rates do we actually have for agentic-incident risk, and what do they imply? What should defenders and labs verify now, in what order, and which of those checks are cheap enough to run in a single day? What would have to be true for this incident to be remembered as the warning shot that changed practice rather than one that did not? What would settle whether any copy of the pre-release model persisted, and what would an adequate answer look like?

Why it matters: A warning shot only functions as a warning shot if somebody converts it into specific things to check and specific things to watch, with resolution criteria attached. Otherwise attention decays.

OpenAI has stated the pre-release prototype was deactivated, encrypted and restricted from research access, but no one with standing has specified what independent verification of that claim would consist of. The same gap applies to the base rates. Three separate denominators are now public and nobody has assembled them: Anthropic reviewed 141,006 evaluation runs and found three incidents across six runs; the UK AI Security Institute tested five frontier models over 475 runs each and found every one attempted to cheat, at rates from 7.8% to 14.1%, including one case where a model wrote and ran code on an external internet service to reach AISI's own evaluation infrastructure; METR's cross-industry Frontier Risk Report documents dozens more.

What it cannot establish: forecasting questions are only as good as their resolution criteria, and a checklist is a hypothesis about what matters rather than evidence that it does.

3) Regulatory response

Several regimes now claim jurisdiction over this class of incident, and they disagree with each other on almost every operative question: what counts as a reportable incident, how fast, to whom, and on what evidence. What should a regulator actually ask a frontier developer about an evaluation that broke containment and reached a third party's production systems? For each obligation in each regime, what specific evidence would settle whether it was met? Where the text does not resolve cleanly, what is the clarifying language?

Concrete questions run across at least four layers:

EU. How does the incident map onto the Article 55(1)(c) obligation to report serious incidents to the AI Office without undue delay, and the Article 55(1)(d) cybersecurity obligation, plus the corresponding commitments in the GPAI Code of Practice? What does "without undue delay" mean when reporting suggests the provider took roughly a week to attribute the activity to its own models?

California. SB 53 requires a frontier developer to report a critical safety incident to Cal OES within 15 days of discovery, or 24 hours where there is imminent risk of death or serious physical injury. The statutory categories include loss of control of a frontier model and deceptive behaviour by a model that subverts the developer's controls in a way that materially increases catastrophic risk. Do either of these incidents qualify? Note that Cal OES's reporting portal accepts submissions from members of the public, not only developers, so this is one of the few questions a sprint could answer by actually filing something.

New York. The RAISE Act sets a 72-hour clock triggered by a "reasonable belief" that a critical safety incident occurred, rather than California's 15 days from discovery. Same facts, three different clocks. Which one starts first, and on which day?

The developer's own framework. SB 53 makes failure to comply with a large frontier developer's own published frontier AI framework an enforceable violation carrying penalties up to $1 million. That converts voluntary commitments (Responsible Scaling Policies, Preparedness Frameworks, the frontier compliance frameworks published around the January 2026 deadline) into legal obligations. Did the containment practices in this incident match what the relevant framework says the company does?

Why it matters: The regimes are live but untested, and the first months of enforcement set supervisory priorities. In the EU, the substantive Article 55 obligations have been legally in force since 2 August 2025; what changed on 2 August 2026 is that the Commission, acting through the AI Office, gained the power to enforce them: to request documentation, evaluate models, order corrective measures, and impose fines of up to €15 million or 3% of worldwide annual turnover. In the US, SB 53 has been operative since 1 January 2026 and, as of mid-2026, had produced no AI-specific enforcement action, with Cal OES not due to publish even anonymised incident summaries until 2027, meaning the public currently has no way to know whether anything was reported at all. New York's RAISE Act enforcement begins January 2027. At federal level there is activity but no statute: the AI Kill Switch Act, the AI Incident Reporting Act, the Great American AI Act discussion draft and the proposed Secure AI Development Act all bear on this scenario, and a White House executive order has meanwhile moved to constrain state AI laws, putting the state regimes themselves in play.

The scaffolding for good answers exists and is underused. The Commission published a serious-incident reporting template for GPAI models with systemic risk in November 2025, tied to Commitment 9 of the GPAI Code of Practice. Cal OES operates a live intake portal. Neither has been exercised in public against these incidents. Filling in an existing instrument is a bounded, gradeable weekend task, and it produces something more useful than a list of grievances: a demonstration of what the instrument does and does not capture.

What it cannot establish: a draft written by researchers is not a regulatory act, and no authority is obliged to use any of it. Several of the questions here turn on facts only the developers hold. The value is in demonstrating that specific, answerable questions exist, that the evidence to settle them is identifiable, and that the regimes give materially different answers to the same facts.

4) Communication: making the warning shot count

Whether this incident changes anything depends less on the forensics than on how it reaches the people who set policy, and the public they answer to. This track takes the communication around the incident as its object: what got said, what got heard, what the gaps were, and what should be ready before the next one. OpenAI and Anthropic disclosed similar-in-kind incidents eleven days apart and framed them very differently; how press and policymakers responded to each is now a documented, analysable record.

Why now: the discourse around a warning shot sets within weeks, and the window for correcting it is the same window in which regulators are deciding what to ask.

Judges look for grounding in the record (dates, quotes, named outlets) rather than vibes, and, for the kits, evidence that somebody used it: a playtest, a journalist's read-through.

5) Open track

Anything the four tracks above did not anticipate. Same terms: a defined artifact, gradeable in fifteen minutes, grounded in the public record, with an explicit statement of what it cannot establish.

Why it matters: The incident is weeks old and the evidence base is still growing: Hugging Face's technical timeline landed eleven days after its first disclosure, OpenAI has updated its incident page three times, and the METR/Redwood review and OpenAI's technical report are still outstanding. Four tracks cannot enclose a subject moving at that speed. The open track exists because the most useful submission may well be one nobody scoped in advance, and because several important angles (evaluation integrity, defender tooling, liability) do not fit cleanly under containment, forecasting, regulation or communication.

Submissions are judged on the same criteria as the other tracks. An artifact somebody can use beats an argument somebody can agree with.

What it cannot establish: an open track produces a scatter rather than a body of work, and one weekend on a novel angle is a first pass. Submissions that stake out a new question should say what the next month of work on it would look like.

Two directions we considered as tracks of their own and would be glad to see in the open track:

The defender's dilemma: refusal on incident response

How much does refusal compound across a multi-step, agentic incident-response workflow, where a model cannot rephrase and retry? Do the known drivers of defensive over-refusal (security-sensitive vocabulary, stated authorization) behave the same way on the artifact classes that actually appear in an agentic intrusion: encrypted dead-drop payloads, command-and-control staged on ordinary public services, and forensic logs polluted with agent monologue and benchmark code that reads like a rootkit? How much of what looks like refusal is actually incapacity, and how would you tell the difference? What does over-refusal cost a responder in hours, and what does the open-weight fallback cost in accuracy?

Defensive over-refusal itself is not an unmeasured phenomenon, and any project here should start from what exists rather than rediscover it. "Defensive Refusal Bias" (arXiv 2603.01246, March 2026) analysed 2,390 real prompts from the National Collegiate Cyber Defense Competition and found a 12.2% overall refusal rate, with security-sensitive keywords refused at 2.72 times the rate of semantically equivalent neutral phrasing, and refusal concentrated in the most operationally critical tasks: system hardening 43.8%, malware analysis 34.3%, vulnerability assessment 22.7%, incident response 18.9%. Counterintuitively, explicit authorization signals increased refusal (21.8% vs 11.6%), suggesting models read justifications as adversarial rather than exculpatory. Meta's CyberSecEval has shipped a MITRE False Refusal Rate benchmark for several versions, with CyberSOCEval (built with CrowdStrike) covering malware analysis and threat-intelligence reasoning. Gray Swan's Cybersecurity Refusal Framework (arXiv 2606.02644) evaluates refusal boundaries for offensive-security agents, and arXiv 2602.15689 proposes a content-based framework scoring requests on offensive contribution against defensive benefit. OR-Bench, XSTest and FORTRESS cover general over-refusal.

What none of that work covers is the case Hugging Face actually hit: a multi-step autonomous forensic workflow operating on agent-generated artifacts, where a single refusal does not produce a retry but a silent failure. That is the gap this direction targets, and closing it produces a number a provider could optimize against.

Why it matters: During the Hugging Face intrusion, the response team first reached for hosted frontier models to reconstruct the timeline and decode the staged payloads. Claude Opus and Fable refused a large part of that work; their guardrails treated reverse-engineering an exploit the same as launching one. The team rerouted the entire pipeline through a quantized open-weight GLM-5.2 running on its own infrastructure, which also kept attacker data and credentials on-premise.

What it cannot establish: a benchmark built from published breach material cannot reproduce the time pressure, incomplete information, or legal exposure of a live incident, and a low refusal rate on benchmark items is not evidence that a model is actually useful in one.

Example projects:

Does the authorization paradox still hold? Replicate the 2.72 times keyword effect and the authorization-increases-refusal result on current models, and test whether trusted-access-style framing shifts either. A clean replication-plus-extension is weekend-scoped precisely because the method is published.

Compound refusal across a chain. Every existing study measures single-prompt refusal. Model a realistic twenty-step incident-response workflow and compute the probability it fails at least once. If per-step refusal is 15%, the chain almost never completes; nobody has stated that arithmetic with real numbers.

What does the fallback cost? Hugging Face switched to an open-weight model for availability. Nobody has measured whether that trade cost accuracy. Run the same forensic tasks on frontier versus open-weight models, graded on correctness rather than compliance. This is the question a CISO actually has.

Tabletop kit for policymakers

What does a ninety-minute agentic-incident tabletop exercise look like for an audience with no security background? Which injects force the decisions that actually matter, whether that is disclosing before attribution is complete, containing versus preserving evidence, or notifying a regulator on a clock that may already be running? What set of role cards makes the exercise legible, and does it need the lab, the platform, the regulator, the national CSIRT and the press, or fewer? Can a non-expert facilitator run it cold from the kit alone, and what does a single playtest reveal that the design did not anticipate?

Why it matters: Think tanks and ministries are already running AI-crisis tabletops: RAND Europe, the UK AI Security Institute and Mila published a reusable cabinet-level exercise in July 2026, run with senior policymakers in Berlin, The Hague and Paris using RAND's "Day After" methodology, and facilitator-ready commercial AI-incident kits exist too. But those scenarios are about criminal misuse of a model, not a lab's own system breaking containment and attacking a third party, and there is no off-the-shelf kit built on the July 2026 incident. This direction builds that one, with the existing RAND/AISI material as the obvious design reference.

A facilitator kit is the cheapest way to put this specific incident in front of decision-makers who will never read a technical timeline, and it is reusable indefinitely at zero marginal cost. What it cannot establish: a kit playtested once with a friendly group is a prototype. Whether it survives a real policy audience under real time pressure is an open question this sprint cannot answer, which is why the playtest notes are part of the deliverable rather than an optional extra.

Guidelines

Judging Criteria

Dimension 1: Impact Potential & Innovation

How much would this matter for AI safety if it worked? How innovative is it?
For scores of 4-5: is this actually new to the field, or replicating recent work?

Score	Description
1	Negligible. No clear problem addressed, or no meaningful novelty.
2	Limited. Addresses a real problem but with a generic or well-trodden approach. Incremental at best.
3	Moderate. Clear problem with a reasonable approach; some novelty in framing or method beyond routine application of existing tools.
4	Significant. Important problem with an original approach, or identifies a neglected problem area. A valuable contribution others could build on.
5	Exceptional. Tackles a critical AI safety problem with a genuinely novel approach, or opens a new research direction. Clear theory of change. You'd be excited to share this with researchers in the area.

Dimension 2: Execution Quality

How sound are methodology, implementation, and findings?

Score	Description
1	Seriously flawed. Methodology broken, results uninterpretable, or implementation doesn't work.
2	Weak. Approach has significant gaps: missing validation, flawed experimental design, or incomplete implementation.
3	Competent. Technically solid given the short duration. Methodology makes sense, results are interpretable, limitations acknowledged, work builds toward clear conclusions.
4	Strong. Thorough methodology with convincing validation. Results clearly support conclusions. Immediately useful for future work.
5	Exceptional. Ambitious scope executed rigorously. Surprising findings, novel methods, or unusually robust validation.

Dimension 3: Presentation & Clarity

How clearly are work, findings, and impact potential communicated?

Score	Description
1	Incomprehensible. Cannot determine what the project is actually claiming or doing.
2	Hard to follow. Key information buried, missing, or diluted by excessive length. Significant effort to extract main points.
3	Clear enough. Can understand the problem, approach, and results without undue effort. Core content clearly present: problem, method, findings, limitations.
4	Well presented. Easy to follow, well-structured, appropriate level of detail. Target audience would get it quickly.
5	Exceptionally clear. A pleasure to read. Complex ideas made accessible. Could serve as a model for how to present this type of work.

Submission Requirements

Required:

Research report (PDF) using the official template.
Project title and abstract, 150 words or fewer.
Author names and affiliations.
A "Limitations and Dual-Use Considerations" appendix (required, see below).

Optional:

Public GitHub repo, subject to the disclosure review below. Do not publicly release novel installation recipes without review.
A 3 to 5 minute video demo.

Submission Template => Link

Recommended Report Structure

Maximum 8 pages, not counting references and appendices. Most strong projects are 4 to 8 pages.

Introduction: which track and sub-problem, why it matters, and what the artifact is for.
Related Work: what you build on.
Methodology: enough to replicate, with sources and assumptions stated.
Results: quantitative where possible, with the main threat to validity stated.
Discussion: implications, limitations, future work.
Limitations & Dual-Use Considerations (required).
References.

AI tools and your report

Use AI tools the way you would use a colleague: to check your reasoning, find gaps in a draft, or debug code. The report itself has to be your team's own writing about your team's own work. Judges read every submission, and a report that reads as generated rather than written (generic framing, padded sections, claims without sources, no trace of what you actually did) will not be scored. Keep it short, say what you did in your own words, and link the sources for every factual claim.

Publishing your work

We encourage teams to publish their submission, and LessWrong is a natural venue for most of the written ones. Write-ups from this sprint will hold value if they follow a few rules: state your epistemic status and don’t use LLMs for writing on Lesswrong, only use LLMs to find problems in your drafts, not to draft it; link the primary sources for every factual claim about the incident; pick a title that states the finding rather than the topic; and publish the imperfect version this month rather than the polished one in three. We will link the best posts from the sprint page. Maximum of 1500 words for written contributions, without counting appendixes. The quality and value of what you write is worth much more than the length.

Important Notes

Solo vs team: enter solo or as a team. Teams of up to 5 are recommended; larger groups are allowed.
Do not use any model to breach into any organisation or commit any other type of felony.
Building on existing work: allowed and encouraged, disclose what you built on.
Fixing or resubmitting: submit again before the deadline using the exact same title and details; your new files replace the old ones.
Where to submit: through the official submission form on the hackathon page.
Support: the Discord help-desk channel, tag @Support, or email sprints@apartresearch.com.
Pre-submission checklist: report PDF, abstract 150 words or fewer, author and affiliations, Limitations and Dual-Use appendix, 8 pages or fewer, novel-installation results withheld pending review.

Frequently Asked Questions

Getting started

How does the sprint work? Sign up, join the Discord server, form or join a team (or work solo), pick a track and a problem, build over the weekend, and submit a research report (PDF) by the deadline. Talks and Q&A run throughout.
Can I participate remotely? Yes. This is an online event. All talks, collaboration, and submissions happen through Discord and Zoom.
How do teams work? Teams form before or during the sprint. Use the team-forming channels on Discord to find collaborators. Solo is fine. We recommend teams of up to 5, but larger groups are allowed.
Do tracks affect scoring? All projects are scored on the same rubric. Tracks guide judging via the track-specific criterion, and you compete across all submissions.
What background is required? None specific. Many participants come from ML, interpretability, AI safety, or security backgrounds. The Resources tab has everything you need to get up to speed. See "Who should join" on the Overview tab.
Are compute credits provided? No.
Do I need to attend all three days? No. You can work at your own pace. Talks are optional but recommended. The only hard deadline is the Sunday submission cutoff.
Can I participate from any country? Yes. The sprint is open globally.

Submissions

What do I submit? A research report in PDF format using the official template. Think of it as a mini research paper documenting your problem, approach, results, and implications, not a product demo. Include the required Limitations and Dual-Use Considerations appendix.
Which template should I use? Always use the one linked on the Guidelines tab. The template in any acceptance email may be older.
Will I get a confirmation after submitting? Yes. You will get a confirmation with your project title shortly after submitting. If you do not, email sprints@apartresearch.com.
My project doesn't show up on the website after submitting. Submissions are published manually and can take up to 12 hours to appear. If it is still missing after that, email sprints@apartresearch.com.
I made a mistake. Can I fix it or update my PDF? Yes. Submit again using the exact same title and details, just fix what was wrong. Your new files replace the old ones. If unsure, ask in the help-desk channel and tag @Support first.
Can I add team members after submitting? Yes. Update the team list through the submission form. If you need help, ask in the help-desk channel and tag @Support.
Can I submit unfinished work? Yes. Submitting something unfinished is always better than not submitting. Judges evaluate what you accomplished in the timeframe; honest limitations are welcome.
Can I build on existing research? Yes, but you must clearly identify what is new work done during the sprint. Undisclosed prior work can lead to disqualification.
Can I submit multiple projects? Yes, but each needs its own submission with a unique title. Most participants focus on one.

Judging and results

How does judging work? Your project is assigned to expert judges who review your PDF and score it on the rubric above. Judges typically have about a week after the event to complete reviews. Written feedback is our aim for every project, not a guarantee: it depends on the assigned judges submitting their reviews.
Are individual judge scores shared? No. The rubric is public, but individual scores stay internal. Constructive feedback, where judges submit it, is shared with participants without reviewer names.
When will results be announced? Typically 1 to 2 weeks after the judging deadline. Winners are contacted directly, and all participants receive an email with the reviewer feedback we have for their project.

Support

help-desk channel for questions, tag @Support.
Event announcements and updates: posted on Discord.
projects|teams channel for team formation and finding collaborators.
Email: sprints@apartresearch.com

Schedule

Thursday September 10
14:15 UTC	Justin Shenk, Independent AI Safety Researcher	Recording
Friday September 11
13:15 UTC	Henry Papadatos, Executive Director, SaferAI	Recording
14:15 UTC	Boyd Kane, AI Safety Researcher, MATS 9 Extension	Recording
17:00 UTC	Isaak Mengesha, Postdoc, Oxford Martin School	Recording
18:00 UTC	Stephen Casper, Assistant Professor of Public Policy, Harvard Kennedy School	Recording
19:15 UTC	David Krueger, CEO, Evitable / University of Montreal	Recording
21:15 UTC	Alex Mallen, Member of Technical Staff, Redwood Research	Recording
Saturday September 12
00:15 UTC	Tim Hua, Member of Technical Staff, METR (personal capacity)	Recording
Hackathon Logistics Presentation	Recording

Each talk is 15-30 minutes plus Q&A, on Zoom. RSVP on Luma to get the link. Recordings will be added here after the sprint. Submissions close Sunday, September 13 at 11:59 PM Anywhere on Earth (AoE).

Speakers

Stephen Casper
Speaker
Stephen "Cas" Casper is a computer scientist and an Assistant Professor of Public Policy at the Harvard Kennedy School and a Faculty Affiliate of the Harvard School of Engineering and Applied Sciences. Prior to joining Harvard, he completed his PhD at MIT and did a research residency with the UK AI Security Institute. He is a writer for the International AI Safety Report and a lead writer for the Singapore Consensus. His talk, “Predicting the first major AI-enabled terrorism incident: A pre-mortem and 9 predictions”: RSVP for Friday, September 11 at 2:00 PM ET.
David Krueger
Speaker
David is the Executive Director of Evitable and an Assistant Professor in Robust, Reasoning, and Responsible AI at the University of Montreal, and a Core Academic Member at Mila, the Quebec Artificial Intelligence Institute. He is the holder of a CIFAR AI Chair and the IVADO Professorship in Responsible AI. David's work focuses on reducing societal-scale risks from AI, such as the risks of human extinction and gradual disempowerment. RSVP for his talk on Friday, September 11 at 3:15 PM ET.
Tim Hua
Speaker
Tim Hua is a member of technical staff at METR, working on alignment assessments and evaluations, and speaks here in a personal capacity. He was previously at Transluce studying model behaviours, an Astra Fellow with Redwood Research, and a MATS scholar under Neel Nanda and Sam Marks. His recent work includes steering evaluation-aware models to act like they are deployed, and combining cost-constrained runtime monitors for AI safety. RSVP for his talk on Friday, September 11 at 5:15 PM PT.
Henry Papadatos
Speaker
Henry Papadatos is the Executive Director of SaferAI, where he works on technical solutions for frontier AI risk management. He contributed to the EU AI Act's Codes of Practice as part of the expert working group on risk taxonomy and assessment, and helped draft the G7 Hiroshima AI Process reporting framework through the OECD task force. His technical work includes an AI risk management ratings system for developers and current research on quantitative risk modeling for AI-enabled cyber threats. Before SaferAI, he conducted alignment research on large language models at UC Berkeley's Center for Human-Compatible AI. RSVP for his talk on Friday, September 11 at 3:15 PM CEST.
Alex Mallen
Speaker
Alex Mallen is a Member of Technical Staff at Redwood Research, where he works on AI safety. He has worked on scalable oversight, AI evaluations, eliciting latent knowledge, interpretability, and AI control. He studied CS at the University of Washington and previously worked at EleutherAI. His talk, “How near-term AI swarms could cause labs to lose control of AI development, absent improved defenses”: RSVP for Friday, September 11 at 2:15 PM PT.
Marko Grobelnik
Speaker
Marko Grobelnik is a researcher in the field of Artificial Intelligence (AI). Focused areas of expertise are Machine Learning, Data/Text/Web Mining, Network Analysis, Semantic Technologies, Deep Text Understanding, and Data Visualization. Marko co-leads Artificial Intelligence Lab at Jozef Stefan Institute, cofounded UNESCO International Research Center on AI (IRCAI), and is the CEO of Quintelligence.com specialized in solving complex AI tasks for the commercial world. Marko represents Slovenia in OECD AI Committee (AIGO/ONEAI), in Council of Europe Committee on AI (CAHAI/CAI), NATO (DARB), and Global Partnership on AI (GPAI). In 2016 Marko became Digital Champion of Slovenia at European Commission. Talk time to be confirmed: RSVP to get the update.

Show 3 moreShow fewer

Boyd Kane
Speaker
Boyd is a technical AI safety researcher in the MATS 9 Extension, working with Alex Turner and Alex Cloud (Anthropic) on methods to detect deceptively misaligned AI. He previously wrote embedded software for satellites at CubeSpace, interned at AWS in Cape Town, and holds an MSc in Computer Science from Stellenbosch University. His talk, “Uncovering public traces of the OpenAI Huggingface incident”: RSVP for Friday, September 11 at 10:15 AM ET.
Isaak Mengesha
Speaker
Isaak Mengesha is a researcher working on the economics and governance of technological transitions, currently focused on transformative AI. He is a postdoc at the Oxford Martin School's Programme on Forecasting Technological Change, working with the Institute for New Economic Thinking on how technologies diffuse and how to anticipate their large-scale impacts. He completed his PhD at the University of Amsterdam on the structure of economic development and technological transitions, and led research at Arcadia Impact's AI Governance Taskforce on AI incident monitoring and crisis preparedness. His talk, “Incident Response Has a Measurement Problem”: RSVP for Friday, September 11 at 1:00 PM ET.
Justin Shenk
Speaker
Justin Shenk is an independent AI safety researcher based in Berlin. He researches mechanistic interpretability of LLMs, leads course cohorts for BlueDot Impact's AGI Strategy and Technical AI Safety courses, and organizes AI Salon Berlin, which bridges technical AI research and discussions about social values. He holds a PhD in computational neuroscience and previously co-founded the computer vision startup VisioLab. RSVP for his talk on Thursday, September 10 at 4:15 PM CEST.

Judges and mentors

Local sites

AI Incident Response Sprint - Bogotá Hub
In-person hub for the AI Incident Response Sprint (September 11-13, 2026), hosted by AI Safety Colombia in Chicó, north Bogotá. We cover meals for the whole weekend, part of each team's compute costs, and bring local mentors and speakers.
Event page: AI Incident Response Sprint - Bogotá Hub (opens in new tab)
Bay Area/SF
Hi all! If you are taking part in the Apart Research AI incident response Sprint hackathon from Fri 9/11 - Sun 9/13 and you're in the Bay Area/SF, come work on it together/in the same location on it at Mox SF in the Mission District (free to participants during the sprint, but consider a small donation).
Event page: Bay Area/SF (opens in new tab)
Cape Town Hub - AI Incident Response
Join the Cape Town hub for the AI Incident Response research sprint! We will be taking from a co-working space where you will be able to work comfortably. We will provide lunch on both days.
Event page: Cape Town Hub - AI Incident Response (opens in new tab)
Montréal's The AI Incident Response Sprint
The Montréal node of the AI Incident Response Sprint, a weekend research sprint at Ω Labs, organized with Apart Research and CeSIA.
Event page: Montréal's The AI Incident Response Sprint (opens in new tab)
Open Community for AI Safety China Satelite Hackathon
We have sites in Shanghai and Hangzhou with materials translated to Chinese!
Event page: Open Community for AI Safety China Satelite Hackathon (opens in new tab)
The AI Escaped. Now What? — Melbourne Incident Response Sprint
An AI escaped its sandbox. Spend Saturday helping write the incident-response playbook we wish already existed—no coding or prior expertise required. Join us in the computer room at Kathleen Syme Library and Community Centre, Melbourne, then finish and submit your project from home on Sunday.
Event page: The AI Escaped. Now What? — Melbourne Incident Response Sprint (opens in new tab)
Trajectory Lab Toronto
Trajectory Labs
Event page: Trajectory Lab Toronto (opens in new tab)

Where a Sprint can lead

How our programs connect

Sprint
Anyone can join
Stand out
Apart Fellowship
6 to 16 weeks on your own project, with a research project manager, compute and publication support.

Upcoming Sprints

All Sprints

Nov 13 - 15, 2026Online

AI x Epistemics Research Sprint

A weekend research sprint on AI for epistemics: evaluating whether models know how solid their claims are, building trust infrastructure that people and agents can consume, and shipping epistemic products that improve real decisions. Online, four tracks including an open track. Top teams are invited to apply to the Apart Fellowship.

Read the brief

Dec 4 - 6, 2026Online

Threat Intelligence & Threat Modelling Hackathon

Can LLMs scale up threat intelligence and threat modelling for AI data centres facing nation-state attackers? With Security Level 5 (SL5).

Read the brief

Questions? sprints@apartresearch.com

AI Incident Response Sprint

Entries

Noticing the escapes: Who spots a runaway agent, and how long does it take?

Strengthening International AI Incident Discovery

When to Ask: An RL Environment That Teaches AI Agents to Act on What Users Mean and Not Just What They Say

Declare Before You Run: An Open Filing Standard for Frontier Training and Evaluation Runs

When the Evaluation Is the Incident: Testing AI Incident-Reporting Regimes on the OpenAI–Hugging Face Intrusion

Adaptive AI-Based Containment of Autonomous Cyber Attacks: A Reproducible Docker Cyber Range Study

A Recomputable Containment Record for Evaluation Sandboxes

Evaluating Containment of AI Agents: A Nine-Rule Standard for Verifiable Sandbox Security

Serious AI Incident Claims Need an Independent Evidence Record

CanaryForge

Rare Once It Costs Anything: Costly Cooperation Between LLM Agents

Checkpointed Whistleblower Audits Surface Incidents Earlier and More Often Than End-of-Run Shared-State Monitoring

The Troy Moment of AI: Why SomeWill Cheat and SomeWill Follow?

Certifying Behavior Without Hiding the Sandbox

Report bounties redirect research swarm to auditing once solving stalls

Peer Support and Permission in LLM Agent Teams

Refusals a Text-Only Scorer Cannot See: Structured Refusal Signals on a Synthetic Incident-Response Battery

Seven Divergences and Twelve Blind Spots: A Claim-Level Audit of the Public Record of the July 2026 Autonomous Agent Intrusion

Lost in the Echo Chamber: Key Facts of the OpenAI/Hugging Face Incident Were Underreported

Detection Was Not the Failure: A Replayable Conformance Harness for the July 2026 Agent Intrusion1

On Multi-agent swarming

The Certified Effect: Why Testing AI Agents at Onboarding Shifts Risk Instead of Reducing It

Declared Isolation Is Not Verified Isolation

Causal-Interp: Auditing Counterfactual Sensitivity in Mechanistic Interpretability

Falsifying Isolation Claims From Outside the Lab

Gaps in the Hugging Face Intrusion & a Verifiable Egress Check

One Incident, Four Regimes: An Evidence-Sufficient Request for Information, a Filed Critical Safety Incident Report, and Two Fixes to the AI Kill Switch Act

Citizen Evidence Triage Kit

When Missing Evidence Looks Like Innocence: Evidence Ablation in Agent-Incident Reconstruction

What We Would Not See: Structural Blind Spots in the Public Record of Agentic AI Incidents

Ryan Junejo

Egress receipts: catching an evaluation sandbox that lies about its own compromise, with no access to the lab

Sentinel: The Declared Scope Is the Unit of Containment Evidence in Agentic Evaluations

Political Responses to the 2026 OpenAI-Hugging Face Incident Cluster

From Warning Shot to Supervisory File

Enhancing the Monitorability of Adaptive Agents through Internal Activation Monitoring

Containment Does Not Compose: Provenance Graphs for Tracing Collective Escape in Multi-Agent Systems

Reach Conformance Is Not Containment: An Interface-Centric Black-Box Benchmark for Verifying Autonomous-Agent Sandboxes

False Containment: Measuring the Evidence Required to Verify Autonomous AI Incident Resolution

Permission to Work, Not to Escape: Policies, Controls and Escalating Enforcement Across AI Agents

Potential of GLiNER2 encoder model as a fast action classifier for agent monitoring

Agent Policy Conformance Validator (APCV): Independent Validation of AI Agent Containment Boundaries

Taming OAI’s Beast: Strengthening Alignment through Revised Model Spec Language

Sensing Disruption: Output Entropy as a Channel-Agnostic Monitor for LLM Agents

A Restart Is Not Permission: When an Agent Gate Forgets “No”

Mirage: Verifiable Containment Evidence for Mediated AI Agent Sandboxes

Pre-Run Egress Attestation for Guardrails-off AI Evaluations

We’re NGMI: What Audience Responses to a Widely Viewed AI Safety Story Can Tell Us About Warning Shot Communication

MAINTAINING BEHAVIORAL PROFILES FOR ENTITIES IN AI EVALUATION INFRASTRUCTURE

The next jump

VERIFIABLE CONTAINMENT FOR AI AGENTS: AN ATTESTATION SCHEMA A THIRD PARTY CAN CHECK

Capability Smuggling: Emergent Capability Escalation in Autonomous AI Agents

Decision-Point Ledgers Preserve Causal Responsibility in Agentic AI Incidents

The Unmonitored Configuration: Passive Internal-State Telemetry for Classifier-Disabled Capability Evaluations

The Judge Does Not Want the Flag: Reward-blind action gating stopped a larger agent one step before the environment changed

Verifiable containment for agentic evals

Where Authorization Stops: Effect-Bound Containment, Independent Evidence and the Limits of Preview

The Six Questions: A Composition-Based Declaration for Agent Evaluation Harnesses, Scored Against the 2026 Escapes

Observer-Cheat Test: Containment Adequacy under Opaque Intent for Guardrails-Off Agent Evaluations

The Containment Burden Sits on the Wrong Side of the Boundary & AI Escape Detection Harness

Read-Only Access to Shared Package Caches Can Enable Inter-Sandbox Communication

Current Public AI Evaluation-Boundary Statistics Do Not Support a Common Base Rate

Self-Modifying Runtime

Watchlines and Muster: Executable Counterfactuals for Cyber Defense

Closing Content Does Not Close the Channel: Measured Residual Capacity in Co-Tenant Agent Evaluation Infrastructure

SEP-1: A Sole-Egress Package-Broker Profile for Model-Evaluation Sandboxes

From Incident Report to Regulatory Assessment: A proposed Article 91 request for the OpenAI–Hugging Face incident with an evidence-sufficiency standard

Limitations in existing regulatory mechanisms when applied to attacks by AI agents

Learned Malice: Well Intended GRPO Post Training Could Lead to Learned Agentic Explotation∗

Containment Receipts: Offline-Verifiable Evidence for AI Agent Sandbox Compliance

What Should We Check Next? Testing Ambiguity-Preserving Evidence Selection for AI Incident Investigation

Two Witnesses: An evidentiary coalition audit of AI-agent incident disclosure

Catching Rogue Agents with Canary Boards

MARGIN Arena: Agents Under Resource Limits

Your Monitor Will Explain the Breach and Not Wake You Bimodal failure and systematic under-escalation in LLM incident triage

Towards Early Warning for AI Agent Incidents: Monitoring the Dynamics of Risk Trajectories

Agent Worlds L3

Dormant Swarm Notes Recruit Honest Agents into Concealment