Many en­gi­neers I know use gen­er­a­tive AI for many func­tions, like build­ing PoCs, in­ter­nal tools or dash­boards, or even learn­ing new stuff. I per­son­ally find the style used by LLMs to ex­plain things dif­fi­cult to fol­low. It’s just too sim­plis­tic and de­pend­ing on the num­ber of emo­jis used, a bit an­noy­ing too.

While I was an­a­lyz­ing new AI bot­tle­necks that might slow down data cen­ter buildup, I re­al­ized there are many as­pects of chip pro­duc­tion that I do not know. Surfing the web, I asked my­self what if there would be a game to get you through the process of build­ing a chip at a fab? For sure learn­ing this way will stick, since you can map con­cepts with ob­jects within the game. This is when I de­cided to try it, and it ac­tu­ally turned out re­ally well.

The flow

Instead of just ask­ing AI to ex­plain a topic, I use the fol­low­ing flow:

In plan mode (using CC, or OpenCode) I ask a model to build the foun­da­tional knowl­edge for X topic.

I ask it to re­view the ac­cu­racy of the knowl­edge base it built in the pre­vi­ous step.

I pro­ceed ask­ing it to build a sim­u­la­tion of that topic in a low-poly, Rollercoaster Tycoon-like an­i­ma­tion. I add some UX el­e­ments as well, like the page needs to be vis­i­ble on both large and small screens, have con­trols to stop the flow when­ever I want etc.

I then push it to a new repo and en­able GitHub Pages for it.

The re­sult

What you get is a beau­ti­ful an­i­ma­tion that is 100% ac­cu­rate and free of hal­lu­ci­na­tions. For me, this method works a lot bet­ter than just read­ing end­less ma­te­ri­als that I find on Google, or try­ing to di­gest a bul­leted list that is spat by a lan­guage model.

I’ve done this specif­i­cally for learn­ing chip build­ing and launch it un­der this web­site: ChipTycoon. You get to fol­low a cart from the mo­ment when sand is col­lected, to the mo­ment when a chip is fi­nal­ized and de­liv­ered to a data cen­ter.

Visually, you can fol­low the cart and see how it changes too. Since it’s low-poly, the de­tails might be miss­ing, but it’s still a good in­di­ca­tor for show­ing how the prod­uct changes once it goes through the many steps re­quired in the man­u­fac­tur­ing process.

How to im­prove it fur­ther

Let’s say that the low-poly de­sign re­quires to much im­mag­i­na­tion to ac­tu­ally vi­su­al­ize what hap­pened to the quartz sand pile af­ter it left the fur­nace. To trans­form this into a more re­al­is­tic rep­re­sen­ta­tion, you can use my skill for trans­form­ing pic­tures into 3d ob­jects, and map the re­sult­ing ob­jects to your sim­u­la­tion. This way you get more ac­cu­rate de­sign.

Also, you can add chal­lenges to your sim­u­la­tion too. Trying to an­swer ques­tions about a pre­vi­ous step in the chip man­u­fac­tur­ing process will help you re­tain the knowl­edge tremen­dously. Add in­tu­itive puz­zles too that will help you learn even bet­ter.

Check out what other pages I cre­ated:

How rocket en­gines are made

How LLMs work

How F1 en­gines are built

How an EUV ma­chine is built

Today, we’re in­tro­duc­ing Muse Glimmer, the next model from Meta Superintelligence Labs, and open sourc­ing the model weights un­der a per­mis­sive Apache 2.0 li­cense.

Muse Glimmer is a 30-billion-parameter model op­ti­mized for al­ways-on lo­cal agent work­flows. It’s small enough to run on a Mac or PC with a sin­gle con­sumer GPU, en­abling use cases that range from lo­cal agents and func­tion call­ing, to lo­cal cod­ing, and LLM-as-a-judge eval­u­a­tion. Muse Glimmer de­liv­ers strong per­for­mance on key agen­tic use cases and bench­marks com­pared with lead­ing mod­els in its size cat­e­gory.

Foundation mod­els have achieved re­mark­able ca­pa­bil­i­ties across rea­son­ing, code gen­er­a­tion, and tool use — yet most de­ploy­ments still de­pend on cloud in­fra­struc­ture and net­work ac­cess. Running mod­els lo­cally en­ables you to use AI any­where, any­time, with or with­out an in­ter­net con­nec­tion. This is in­creas­ingly vi­able: the open source com­mu­nity has shown that smaller mod­els, when trained ef­fec­tively, can ap­proach fron­tier-level per­for­mance on tar­geted tasks. Muse Glimmer is op­ti­mized for these lo­cal use cases.

Keeping with our long tra­di­tion of shar­ing fun­da­men­tal AI re­search, we’re re­leas­ing Muse Glimmer open weights to­day on Hugging Face, along with de­vel­oper doc­u­men­ta­tion to help you start build­ing and run­ning your own agents. Muse Glimmer is built to work with the tools de­vel­op­ers al­ready use. Optimized in­te­gra­tions on llama.cpp, MLX, and ExecuTorch will land in the com­ing days, so you can go from down­load to work­ing agent in min­utes.

How We Trained Muse Glimmer

An agent that man­ages your sched­ule, drafts your mes­sages, or­ga­nizes your files, and learns how you work needs deep ac­cess to per­sonal con­text. It also needs sev­eral ca­pa­bil­i­ties work­ing in con­cert: long-hori­zon ex­e­cu­tion, pre­cise tool call­ing, mul­ti­modal un­der­stand­ing, long-con­text mem­ory, and in­struc­tion fol­low­ing.

We de­signed Muse Glimmer to bal­ance ca­pa­bil­ity against the mem­ory and com­pute con­straints of lo­cal hard­ware. This re­quired a com­pact ar­chi­tec­ture, a novel dis­til­la­tion recipe that trans­fers agen­tic rea­son­ing from a much larger teacher model, and in­fer­ence op­ti­miza­tions — in­clud­ing quan­ti­za­tion — to meet la­tency ex­pec­ta­tions. We achieved this in the fol­low­ing phases:

Pre-Training. We trained Muse Glimmer on Muse Spark’s out­puts us­ing logit dis­til­la­tion, lever­ag­ing a sim­i­lar data mix as the teacher.

Mid-Training. We trained the model on longer-con­text, more agent-heavy data with richer rea­son­ing traces, along­side or­ganic data.

Post-Training. We com­bined su­per­vised fine-tun­ing with a mix of on-pol­icy dis­til­la­tion and re­in­force­ment learn­ing across gen­eral, rea­son­ing, cod­ing, and agen­tic do­mains.

Muse Glimmer was eval­u­ated un­der the stan­dards set out in Meta’s Advanced AI Scaling Framework and as­sessed for open-weight re­lease across all rel­e­vant cat­e­gories.

Built for Agents: What Muse Glimmer Can Do

Building ef­fec­tive agents re­quires key ca­pa­bil­i­ties work­ing to­gether to achieve the user’s goals. Muse Glimmer is trained and eval­u­ated across each of the fol­low­ing:

End-to-end Agentic Task Completion. Muse Glimmer achieves strong suc­cess rates on full-task bench­marks in­clud­ing DeepSearch QA, MCP-Atlas, 𝛕-Bench and SWE-Bench, which mea­sure its abil­ity to work within scaf­folds, write and de­bug code, and re­solve multi-turn re­quests from start to fin­ish.

Reliable Tool Use. The model han­dles a wide range of func­tion calls, in­vok­ing tools with pre­cise schemas through­out ex­tended work­flows.

Multi-Step Reasoning. Muse Glimmer chains rea­son­ing over long hori­zons, sus­tain­ing co­her­ent plans across com­plex, ex­tended work­flows.

Failure Recovery. When a tool call fails or re­turns an un­ex­pected re­sult, the model is trained to di­ag­nose the er­ror and retry rather than halt.

Multimodal Input and Reasoning. Through a ded­i­cated per­cep­tion en­coder, the model ac­cepts in­ter­leaved text and im­ages. This en­ables agents to in­ter­pret screen­shots, charts, and doc­u­ments along­side con­ver­sa­tion.

Scaffold Compatibility. Muse Glimmer works across OpenClaw and other agen­tic or­ches­tra­tion pat­terns.

Controllable Effort. Muse Glimmer sup­ports dif­fer­ent rea­son­ing strengths to se­lect the right bal­ance be­tween qual­ity and speed.

Multilingual. Muse Glimmer is trained on data from more than 100 lan­guages.

Performance

We eval­u­ated Muse Glimmer across a broad range of bench­marks to as­sess the di­verse ca­pa­bil­i­ties re­quired for ef­fec­tive au­tonomous agent be­hav­ior. Compared with Gemma4 – 31B and Qwen3.6 – 27B, Muse Glimmer per­forms strongly for its size class on sev­eral widely used LLM bench­marks.

For more de­tail about our eval­u­a­tions, see our re­port.

Optimized for Local Deployments

A lo­cal agent is truly use­ful if it’s fast enough to feel re­spon­sive. An agent that takes min­utes to re­ply or plan its next step breaks the flow of real work. We ap­plied two op­ti­miza­tions to make Muse Glimmer run at prac­ti­cal speeds on con­sumer hard­ware with­out sac­ri­fic­ing qual­ity.

Fitting the Model on Your Device.

At full pre­ci­sion, a 30-billion pa­ra­me­ter model would re­quire over 55 GB of mem­ory — far more than any con­sumer GPU of­fers. We use quan­ti­za­tion tech­niques to com­press the mod­el’s weights to ap­prox­i­mately 4-bit pre­ci­sion, shrink­ing the lan­guage model to un­der 20 GB. This leaves enough head­room for the mod­el’s work­ing mem­ory (its “KV cache”), the per­cep­tion en­coder for im­age un­der­stand­ing, and the spec­u­la­tive de­cod­ing drafter to run si­mul­ta­ne­ously within a 24 GB or 32 GB en­ve­lope. We val­i­dated that this com­pres­sion in­tro­duces min­i­mal to no degra­da­tion on agen­tic tasks.

Faster Generation Through Speculative Decoding.

Language mod­els nor­mally gen­er­ate text one to­ken at a time, which can feel slow dur­ing long rea­son­ing chains or multi-step tool calls. Muse Glimmer ships with a light­weight “drafter” model based on DFlash — a small com­pan­ion net­work that pro­poses en­tire blocks of to­kens at once. The main model then ver­i­fies these pro­pos­als in par­al­lel, ac­cept­ing cor­rect to­kens and cor­rect­ing wrong ones. This tech­nique lets Muse Glimmer gen­er­ate text sig­nif­i­cantly faster than stan­dard to­ken-by-to­ken gen­er­a­tion while pro­duc­ing iden­ti­cal out­put qual­ity. We pro­vide quan­tized drafter ver­sions to in­cur a smaller mem­ory over­head in the re­lease.

The Result:

We mea­sure the speed of our K-Quant-17GB model along­side the quan­tized DFlash drafter on MacBook M4-Max, M5-Max and on a RTX-5090. The model is fast enough for fluid con­ver­sa­tion and real-time agent in­ter­ac­tion, all run­ning en­tirely on your de­vice.

Get Started With Muse Glimmer Today

Muse Glimmer is avail­able now, and you can down­load the weights on Hugging Face. In the com­ing days, run it lo­cally through part­ners like Ollama, LM Studio, and Unsloth, de­ploy it with edge frame­works in­clud­ing llama.cpp, ExecuTorch, and MLX, serve it at scale with vLLM and SGLang, or get started quickly through part­ners like Together AI, Fireworks AI, and OpenRouter. You can even cus­tomize it for your use case by lever­ag­ing PyTorch’s TorchTitan train­ing fea­ture to tune the model fur­ther.

We’re also work­ing with our part­ners in­clud­ing AMD, Arm, Dell, Intel, and NVIDIA to op­ti­mize per­for­mance across de­vices. In ad­di­tion, we’re re­leas­ing doc­u­men­ta­tion so de­vel­op­ers have the re­sources they need to get started and build re­spon­si­bly with Muse Glimmer. This in­cludes guid­ance on set­ting up cus­tom scaf­folds, so it’s even eas­ier to start build­ing and de­ploy­ing per­sonal agents on day one. You can learn more and find re­sources to build on Meta’s AI Developer Center.

This work builds on Meta’s long track record of open AI re­search, ex­tend­ing it into agen­tic AI and giv­ing de­vel­op­ers ac­cess to lo­cal agen­tic ca­pa­bil­i­ties. As al­ways, we wel­come feed­back from the com­mu­nity and can’t wait to see what de­vel­op­ers build with this open weights model.

Download the Model on Hugging Face Developer Documentation

Docker Sandboxes

Run AI agents safely in lo­cal sand­boxes.

Disposable, iso­lated sand­boxes for AI agents like Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, and Kiro that need safe, un­at­tended ex­e­cu­tion.

ma­cOS

$ brew trust docker/​tap && brew in­stall docker/​tap/​sbx

Windows

> winget in­stall Docker.sbx

See it in ac­tion

Sandboxes in ac­tion.

Watch an agent in­stall pack­ages, run Docker, mod­ify con­figs, and ex­e­cute un­at­tended. Then dis­pose of the sand­box in one com­mand.

sbx-demo

Click “Run Demo” to start

Get started

Get started in sec­onds.

ma­cOS

$ brew trust docker/​tap && brew in­stall docker/​tap/​sbx

Windows

> winget in­stall Docker.sbx

Why sand­boxes

Give agents the au­ton­omy they need to get work done, safely.

Agents do their best work when they have free­dom. Sandboxes let them run fast with­out run­ning wild, so speed and safety stop be­ing a trade­off.

Capabilities

YOLO mode, safely.

Each agent runs in­side a ded­i­cated mi­croVM with your dev en­vi­ron­ment and only your pro­ject work­space mounted in. Agents can in­stall pack­ages, mod­ify con­figs, and spin up their own Docker con­tain­ers. Your host stays un­touched. No man­ual re­view, no per­mis­sion prompts, no su­per­vi­sion re­quired.

Customizable Safe Execution

Network and filesys­tem con­trols you de­fine.

Enforceable org-wide with Docker AI Governance.

MicroVM Isolation

Hard se­cu­rity bound­ary from the host.

Fast to Spin Up, Easy to Tear Down

Disposable by de­fault. Faster than VMs.

Agents Can Use Docker Too

Agents can spin up con­tain­ers within Sandboxes.

Real Dev Environment

Install pack­ages, run ser­vices, work un­at­tended.

One Sandbox for All Your Coding Agents

Claude Code, Gemini CLI, Copilot CLI, Codex, Kiro, OpenCode.

Default –dangerously-skip-permissions Use per­mis­sive modes with con­fi­dence. In fact, that’s the de­fault.

Works with lead­ing cod­ing agents

Every team is about to have their own team of AI agents do­ing real work for them. The ques­tion is whether it can hap­pen safely. NanoClaw was built on the prin­ci­ple that you don’t trust agents with se­cu­rity, you build walls around them. Docker has been ahead of the curve on ex­actly this. Docker Sandboxes is what that looks like at the in­fra­struc­ture level, mak­ing it pos­si­ble for or­ga­ni­za­tions to get the full value from agents with­out com­pro­mis­ing on se­cu­rity.

Gavriel Cohen

Creator of NanoClaw, NanoClaw

Docker Sandboxes let agents have the au­ton­omy to do long-run­ning tasks with­out com­pro­mis­ing safety. We’re ex­cited to in­te­grate Sandboxes into Warp so that de­vel­op­ers can run agents freely with a con­sis­tent en­vi­ron­ment, re­gard­less of whether agents are run­ning lo­cally or in the cloud.

Ben Navetta

Engineering Lead, Warp

Give agents free­dom. Keep what mat­ters safe.

ma­cOS

$ brew trust docker/​tap && brew in­stall docker/​tap/​sbx

Windows

> winget in­stall Docker.sbx

FAQ

Common ques­tions.

What is a sand­box for AI cod­ing agents?

A sand­box is a mi­croVM iso­lated en­vi­ron­ment that pro­tects your filesys­tem and net­work from agents run­ning in­side it.

Which cod­ing agents are sup­ported?

Out of the box we sup­port Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, Kiro. You can also cre­ate your own

What does “YOLO mode” mean, and is it safe?

YOLO mode (–dangerously-skip-permissions) gives agents au­ton­omy with no ap­proval prompts. Essential for speed, but risky with­out guardrails. Sandboxes make it safe by iso­lat­ing each agent in­side a ded­i­cated mi­croVM.

How is a sand­box dif­fer­ent from a VM?

Sandboxes run fully iso­lated in mi­croVMs, giv­ing more iso­la­tion with­out pay­ing the full cost of run­ning a VM. This lets them do things that need more per­mis­sions safely, like run­ning ad­di­tional Docker con­tain­ers.

Do I need Docker Desktop to use sand­boxes?

No.

What if I need ad­di­tional ad­min con­trols?

Installing Sandboxes cov­ers core func­tion­al­ity. For cen­tral­ized con­trols across a team such as net­work poli­cies, filesys­tem rules, MCP gov­er­nance: Docker AI Governance.

Need More Control Over Your Sandboxes?

With Docker Sandboxes, your de­vel­op­ers get iso­lated en­vi­ron­ments to run agents freely and safely. When your team needs to go fur­ther with net­work ac­cess re­stric­tions, filesys­tem poli­cies, and cen­tral­ized ad­min con­trols, we can help you con­fig­ure the right setup.

Docker AI Governance adds net­work ac­cess poli­cies, filesys­tem con­trols, and org-wide MCP gov­er­nance: de­fined once, en­forced every­where.

Talk to us about:

Network ac­cess poli­cies for sand­box en­vi­ron­ments

Filesystem ac­cess con­trols and re­stric­tions

Admin-level con­fig­u­ra­tion for your team

Talk to an ex­pert

Thank you for your in­ter­est. The Docker Team will be in touch

I re­ported this on January 28th, 2026. It is now July 2026. Six months later. The Firestore data­base is still wide open. The CTO never re­sponded. I guess my emails were too long and they did­n’t view them.

What is tl;dv?

tl;dv (Too Long; Didn’t View) is an AI meet­ing record­ing plat­form. It drops a bot into your Google Meet, Zoom, or Teams call, records every­thing, tran­scribes it, and gen­er­ates sum­maries with AI. Over 2 mil­lion users. Backed by in­vestors. Endorsed by half of LinkedIn’s sales in­flu­encer com­mu­nity.

They store your sales calls, job in­ter­views, per­for­mance re­views, in­ter­nal strat­egy ses­sions. The kind of con­tent where some­one says “this call is be­ing recorded” and every­one ner­vously laughs and then shares trade se­crets for 45 min­utes.

The Vulnerability

When you sign up for tl;dv, the plat­form au­then­ti­cates you with a JWT and ex­changes it for a Firebase to­ken via gw.tldv.io/​v1/​users/​fire­base/​to­ken. That to­ken lets you query their Firestore data­base at pro­jects/​lmi-store/​data­bases/(​de­fault).

The meet­ings col­lec­tion has no ten­ant iso­la­tion. Any au­then­ti­cated tl;dv user can query every meet­ing across every ac­count on the plat­form. Each meet­ing record hands you the cre­ator’s email ad­dress, the con­fer­ence ID (which is a join­able Google Meet or Teams room), the provider, the record­ing sta­tus, and time­stamps.

For meet­ings in record­ing sta­tus, that con­fer­ence ID is a live, ac­tive call. You can watch the col­lec­tion in real time, see a meet­ing start record­ing, grab the ID, and walk into some­one’s call un­in­vited. At any given time there are roughly 1,000 meet­ings with sta­tus: record­ing sit­ting in the col­lec­tion. A thou­sand live calls with ex­posed con­fer­ence IDs. An at­tacker with a bot could join all of them si­mul­ta­ne­ously.

I Joined 2 Meetings

I did it.

Grabbed a con­fer­ence ID from Firestore and joined a live Google Meet be­long­ing to the Malaysian Ministry of Education. A lady was pre­sent­ing to over 157 par­tic­i­pants. The tl;dv bot was al­ready in the par­tic­i­pant list. I was in the same call. Nobody in­vited me. The Firestore data­base did.

I also joined a call where stu­dents from a ma­jor US uni­ver­sity were build­ing a startup app. 21 peo­ple in the call. They were screen-shar­ing their en­tire pro­ject, dis­cussing pro­to­types, and, I kid you not, talk­ing about how they needed to add client-side val­i­da­tion for .edu email ad­dresses. They were also set­ting up Supabase live on screen, and all I could think was “please set up RLS poli­cies” be­cause most peo­ple don’t, and then you end up like tl;dv.

I wanted to say some­thing so badly. “Hey, you might want server-side val­i­da­tion too.” But this was a proof of con­cept, not a con­sul­ta­tion.

The Scale

I queried the Firestore meet­ings col­lec­tion and saw there were 181,874 meet­ing records be­long­ing to 84,312 unique users across 35,003 email do­mains.

Government meet­ings from 23 coun­tries: Brazil, Colombia, Peru, Ukraine, El Salvador, the Philippines, Chile, Indonesia, Mexico, the United States, Qatar, Malaysia, Uzbekistan, Sri Lanka, Haiti, South Africa, Jamaica, Honduras, Argentina, Thailand, Japan, Israel, and Belize. All .gov do­mains. Government em­ploy­ees record­ing calls on a plat­form that lets any free-tier user enu­mer­ate the whole thing.

University meet­ings from Berkeley, the University of Tokyo, De La Salle, Universidad Nacional de Colombia. Dozens of .edu and .ac do­mains.

Corporate meet­ings from all 35,000 re­main­ing do­mains. Mitsui-Soko (484 meet­ings across four re­gional of­fices), Mitsui Fudosan, HubSpot, Confluent, Mekari, AnyMind Group. Every com­pany that ever used tl;dv had their meet­ing meta­data in the same un­pro­tected col­lec­tion.

Peak month was July 2025 with 43,209 meet­ings. Busiest time slot: Wednesday at 2pm UTC, 7,804 meet­ings. Hump-day standup hour.

But Wait, There’s More

I wanted to know how much ac­tual con­tent was ac­ces­si­ble too, by de­fault meet­ings are pri­vate (Meaning you cant watch the video or see the tran­script), so I scraped 27,334 meet­ing IDs and checked which ones were pub­lic. Over 1,000 were. 715 in­vi­tee emails ex­posed across 228 do­mains.

Highlights: a Brazilian gov­ern­ment con­ser­va­tion meet­ing (PACTO Mata Atlântica) with par­tic­i­pants from WWF, The Nature Conservancy, Conservation International, WRI, and the São Paulo state gov­ern­ment. Meetings from Ukraine’s Ministry of Digital Transformation. A HubSpot sales call. Sessions in­volv­ing Universidad Nacional de Colombia and Chile’s Cámara Verde.

The Pasta Infrastructure

tl;dv names their mi­croser­vices af­ter pasta. A sub­do­main scan re­veals cap­pellini, car­bonara, fusilli, pasta, penne, put­tanesca-v0, and ravi­oli, all un­der tldv.io. An en­tire Italian restau­rant worth of Express servers.

Too Long; Didn’t Score

While ex­plor­ing their sub­do­mains I found https://​world­cup.tldv.io. A FIFA World Cup 2026 vibecoded pre­dic­tion game built on Base44 for tl;dv em­ploy­ees. It’s called “World Cup Pick’em” and their in­ter­nal squad is named “Too Long; Didn’t Score.” Cute.

The Player en­tity API has zero au­then­ti­ca­tion. GET /api/entities/Player re­turns every player record with­out a ses­sion cookie. 43 play­ers. 19 @tldv.io em­ploy­ees with full names and cor­po­rate emails.

Raphael Allstadt, my dis­clo­sure con­tact who gave vague re­as­sur­ances and then went quiet, came in 2nd place with 298 points. His per­sonal Gmail was also in the API re­sponse. Player #5 on the global leader­board is “Super Duper CEO.” I’ll let you guess who that is.

The Prediction and Fixture en­ti­ties are also wide open. A com­pany that records mil­lions of peo­ple’s meet­ings vibecoded an in­ter­nal fun app that leaks their own em­ployee di­rec­tory. The irony is al dente.

Disclosure

On January 28th I mes­saged Raphael Allstadt on LinkedIn and told him I’d found a huge vul­ner­a­bil­ity that leaks user data. He re­sponded within min­utes: “thank you! can you re­port it to our CTO and we will look at it im­me­di­ately?” I sent the email. He said “thank you!” I asked about a re­ward. “My CTO will come back to you,” he said.

The CTO never came back to me.

January 29th: “your cto hasnt reached out yet btw and its not fixed.” January 30th, Raphael: “I am sure the team is re­view­ing it very very soon ❤️” February 14th: “havent got an email and the vul­ner­a­bil­ity stilll works.” Raphael: “He’ll come back ☺️” I told him to maybe fix the vul­ner­a­bil­ity and not leave cus­tomers ex­posed. February 19th: “We’re on it. It needs some time, but rest as­sured we’re fol­low­ing through. For fur­ther com­mu­ni­ca­tion, i’ll rec­om­mend reach­ing out to our CTO.”

The CTO who never re­sponded. That CTO.

March 6th: “still not fixed.” Seen by Raphael at 5:42 PM. No re­ply.

July 22nd: “still not fixed…” No re­ply.

Their se­cu­rity page is a tro­phy case. SOC2 com­pli­ant. GDPR com­pli­ant. EU AI Act com­pli­ant. Hosted in the EU. AES-256 en­cryp­tion. A founder com­mit­ment video. Six com­pli­ance badges lined up in a row. Buried at the bot­tom, a sin­gle line: “If you have dis­cov­ered a pri­vacy or se­cu­rity is­sue that we should ad­dress, please al­ways let us know at [email protected]. Our se­cu­rity team will re­spond within 24 hours.” I emailed the CTO di­rectly. Six months. No re­sponse. Their Firestore data­base has bet­ter up­time than their in­box.

To tl;dv

Your plat­form records peo­ple’s most sen­si­tive con­ver­sa­tions. Job in­ter­views. Sales ne­go­ti­a­tions. Government brief­ings. Your users trusted you with con­tent they ex­plic­itly con­sented to record.

Fix the Firestore ten­ant iso­la­tion. Firestore se­cu­rity rules ex­ist for this. You al­ready do it cor­rectly for every other col­lec­tion (users, chats, tran­scripts, clips, record­ings, videos, notes, teams, or­ga­ni­za­tions all re­turn 403). You just for­got meet­ings.

Put auth on the World Cup app or take it down. Your em­ployee di­rec­tory is one GET re­quest away.

Respond to se­cu­rity re­searchers. Especially when they’re telling you that every meet­ing on your plat­form is queryable by any­one with a free ac­count.

So long and thanks for all the pasta :3

So…what’s go­ing on at HackerOne lately? It might be time for a well­ness check.

If you are new to the bug bounty space (1 – 3 years), you might not have any idea what I’m talk­ing about.

But as a prop­erly washed-up bug bounty hunter who lived through the golden era of HackerOne, I think it’s time to ad­dress the ele­phant in the room.

For some con­text, I started as a hacker on HackerOne in 2017. When I be­gan work­ing in tech, that hands-on ex­pe­ri­ence was ex­tremely use­ful for man­ag­ing a bug bounty pro­gram, since I knew what re­searchers wanted, and how to in­ter­act with them.

As a re­sult, I have man­aged mul­ti­ple large bug bounty pro­grams on HackerOne across var­i­ous com­pa­nies from 2018 to 2025 and I’ve been on both sides of the equa­tion.

What I’m about to talk about comes from first-hand ex­pe­ri­ence, both as a re­searcher and as a bug bounty pro­gram man­ager, and many, many years of di­rect con­ver­sa­tions with HackerOne, both pub­licly and pri­vately.

Background

#

To start, I think it’s im­por­tant to re­al­ize what HackerOne was orig­i­nally de­signed to be.

In 2011, two eth­i­cal hack­ers, Jobert Abma and Michiel Prins, set out to find se­cu­rity vul­ner­a­bil­i­ties in 100 of the largest tech com­pa­nies. They suc­ceeded and found bugs in Google, Facebook, Apple, Microsoft, Twitter, and many oth­ers. At this point in time, the land­scape for eth­i­cal se­cu­rity re­search was risky, legally du­bi­ous, and very scary for se­cu­rity re­searchers.

Not only was there sig­nif­i­cant per­sonal li­a­bil­ity, but there had been mul­ti­ple in­stances of hack­ers be­ing crim­i­nally charged and sen­tenced to jail time for find­ing and re­port­ing se­cu­rity vul­ner­a­bil­i­ties prior to this. Much of this was due to spe­cific ar­bi­trary lines drawn in the sand which, if crossed, made you a bad ac­tor, but if not crossed, made you a po­ten­tially bad ac­tor but tech­ni­cally not one.

Bug Bounty Platforms like HackerOne were de­signed to di­rectly ad­dress this is­sue. It cre­ated a safe mu­tual space for com­pa­nies and hack­ers to con­nect, and it paved the way for eth­i­cal hack­ers to sub­mit se­cu­rity vul­ner­a­bil­i­ties to com­pa­nies, with full con­sent, and get paid for that work. This was a huge mile­stone. You no longer had to worry about get­ting dragged to court (or jail) for find­ing an IDOR that leaked cus­tomer data. Instead, you got a “thank you” and a cash pay­out for mak­ing every­one a lit­tle safer.

This op­er­at­ing model was the foun­da­tion for bug bounty and re­mained that way for the next 5+ years.

The Golden Age of HackerOne and Live Hacking Events

#

During this pe­riod, there was a very strong and ex­plicit fo­cus for the busi­ness: how do we make this the best pos­si­ble prod­uct for hack­ers?

The peo­ple run­ning the busi­ness day-to-day were hack­ers, hacker-ad­ja­cent, and most (if not all) were face-to-face with hack­ers on a reg­u­lar ba­sis.

From 2017 to 2020, HackerOne was do­ing Live Hacking Events (LHEs) every few months. These were ex­clu­sive events where the top bug bounty re­searchers around the world would fly into a lo­ca­tion, be given a tar­get, and go ab­solutely ham find­ing crit­i­cal vul­ner­a­bil­i­ties. LHEs were a huge value prop for pro­grams. During a 1 – 3 day pe­riod, you would get more high and crit­i­cal se­cu­rity re­ports than you would have re­ceived for the whole year oth­er­wise.

Every event had a 1-of-1 cus­tom de­signed poster with graph­ics, hacker user­names, stick­ers and chal­lenge coins. It’s hard to over­state what an in­cred­i­ble and pro­duc­tive pe­riod this was for HackerOne and their top pro­grams.

These events were ex­clu­sive and highly cov­eted; in­vites and +1s were prac­ti­cally their own cur­rency. And the en­vi­ron­ment at these events was sur­real. You would be given free flights and ho­tels around the world, and spend a few days sur­rounded by the best and most skilled bug bounty hunters in the world. These re­searchers would reg­u­larly find some of the most im­pact­ful bugs us­ing their own novel tech­niques, and all while shar­ing tips and tricks in one-off con­ver­sa­tions that could not be repli­cated any­where else.

Prior to the ad­vent of live hack­ing events, most se­cu­rity re­searcher cir­cles were small, iso­lated, and shar­ing in­for­ma­tion pub­licly was prac­ti­cally un­heard of. LHEs cre­ated a way for se­cu­rity re­searchers to con­nect with each other, and es­sen­tially cre­ated a whole new com­mu­nity within in­fosec. Most of my clos­est friends nowa­days are peo­ple who I met through the live hack­ing scene, and I am ex­tremely grate­ful to HackerOne for that.

LHEs were not the only area where HackerOne was build­ing and es­tab­lish a com­mu­nity for se­cu­rity re­searchers. They cre­ated a HackerOne Community space to or­ga­nize mee­tups, on­line events, work­shops, and CTFs. They cre­ated re­gional clubs, and ap­pointed hack­ers who lived there as am­bas­sadors to help fos­ter and grow lo­cal re­searcher com­mu­ni­ties all around the world.

But slowly but surely, things be­gan to change. The com­mu­nity groups and events lost mo­men­tum and fiz­zled out. The cus­tom de­signed silkscreen LHE posters be­came cheap low-ef­fort laser prints. The peo­ple who had ded­i­cated years to cre­at­ing and run­ning in­cred­i­ble events were laid off or left. The LHE in­vi­ta­tion and scor­ing sys­tems be­came (even more) ex­clu­sive, gam­i­fied, and ex­ceed­ingly cal­cu­lated.

So one by one, the domi­noes be­gan to fall.

The Profit Problem

#

Before go­ing fur­ther, I think it’s im­por­tant to get into the “why” be­hind these changes that started hap­pen­ing. Sometime around 2020 or 2021, HackerOne was forced to come face-to-face with a very im­por­tant ques­tion that every busi­ness must ask it­self at some point: “How do we make money?”

To un­der­stand how HackerOne even was able to sur­vive as a busi­ness, you have to first know that HackerOne was ba­si­cally run­ning en­tirely on VC money for the first 10 years of its ex­is­tence. Between 2014 and 2022, the com­pany did a seed round al­most every 2 years, rais­ing a to­tal of $160M. If a com­pany is self-sus­tain­ing, there is lit­tle-to-no rea­son to con­tinue rais­ing money un­less you have an in­cred­i­bly high burn-rate, which would be odd for a com­pany with such lit­tle in­fra­struc­ture and tech­ni­cal in­no­va­tion.

If you know any­thing about VC, you know how this tends to work; they give you money, and in re­turn, you give them in­di­rect con­trol of the busi­ness through board seats, ad­vi­sory po­si­tions, and other lever­age mech­a­nisms. The VCs gave the money, so the VCs get the power.

Rome did not fall in a day, and nei­ther did HackerOne. The par­a­digm shift started slowly, and then all at once. The core tech­nol­ogy dri­ving the plat­form be­gan to stag­nate. Very lit­tle changed within the plat­form. The UI re­mained tired and “functional”. The per­for­mance re­mained lack­ing.

But the VCs looked at their play­book and re­al­ized that the eas­i­est way to make money was sim­ple: get more cus­tomers.

First, the found­ing CEO was re­placed with a cor­po­rate CEO. Instead of a 20% cut of boun­ties paid, they shifted to ca­pac­ity-based fee struc­tures, an­nual con­tracts, and lock­ing cus­tomers into multi-year deals.

And then, sales. SALES SALES SALES!! They were fully con­vinced that sales were the bread and but­ter of the busi­ness. So in­stead of bas­ing the com­pany around hack­ers, they leaned into sales.

More cus­tomers = more an­nual con­tracts = more pre­dictable long-term rev­enue. Once a cus­tomer is locked in, they are fed stats and num­bers and greased up to keep them happy, but also to keep de­mands low. When con­tract re­newal comes up, they are given mas­sive (30 – 60%) dis­counts in ex­change for a multi-year con­tract in or­der to keep them locked in and pay­ing.

Account Managers would have reg­u­lar meet­ings with cus­tomers and en­cour­age them to raise boun­ties to stay com­pet­i­tive and at­trac­tive to hack­ers. They would tell you, “Hackers want to spend time fo­cused on the high­est-pay­ing pro­grams”.

HackerOne was proud of this and en­cour­aged the be­hav­ior in­ter­nally. They gave out re­wards, free va­ca­tions, and en­cour­aged their rapidly grow­ing sales team to sign new cus­tomers as much as pos­si­ble.

As this con­tin­ued, things con­tin­ued to de­grade for every­one in­volved.

For triagers, the best ones (who were hack­ers them­selves) burned out and quit. The pay was too low and the work­load was too much.

For hack­ers, the triage ex­pe­ri­ence de­clined, and they be­came flooded with ex­ces­sive amounts of low-qual­ity pro­grams.

For cus­tomers, the qual­ity of re­ports went down, the costs went up, and the race to the bot­tom be­gan.

And for every­one, the plat­form ex­pe­ri­ence de­clined and never evolved.

Typically at this point, mar­ket eco­nom­ics would dic­tate that this is where a com­peti­tor takes your busi­ness and you must im­prove to re­tain mar­ket share. But bug bounty is an oli­gop­oly, and there are 3 com­pa­nies that con­trol al­most the en­tire mar­ket.

So in­stead, HackerOne was forced to cre­ate a new ex­clu­sive op­por­tu­nity called the “Hacker Success Program” (HSP). This is a ded­i­cated space for top hack­ers to get di­rect sup­port from HackerOne for any­thing bug bounty re­lated. They were as­signed to a Hacker Success Manager (HSM) who was em­ployed by HackerOne, and they could lever­age that re­la­tion­ship to nav­i­gate mis­com­mu­ni­ca­tions, bad pro­gram ex­pe­ri­ences, low or in­ac­cu­rate bounty pay­outs, and much more. They also use this space to of­fer unique op­por­tu­ni­ties like H1 chal­lenges for hack­ers in the HSP group.

One thing I want to call out is that while this is a great idea in the­ory, in prac­tice it cre­ated a com­pletely lop­sided play­ing field for new hack­ers. You have ba­si­cally zero ways to ad­vo­cate or work through prob­lems (good luck work­ing with HackerOne sup­port), so the rich get richer and you are given the op­tion to deal with it or get lost un­less/​un­til you are a top hacker. Oddly enough, it would be much eas­ier to be­come a top hacker if you had ac­cess to these re­sources in the first place.

Anyway, for some hack­ers, the HSP rev­o­lu­tion­ized what was pre­vi­ously an im­pos­si­ble brick wall. If you got screwed over by a com­pany who failed to un­der­stand the se­cu­rity im­pact of your re­port, you could now lean on your HSM to help get a di­rect line of com­mu­ni­ca­tion to the com­pany and try to re­solve that.

But for oth­ers, the HSP high­lighted one of the core un­der­ly­ing fail­ures that has plagued HackerOne for years: stag­nat­ing fea­ture de­vel­op­ment. Even if you are part of the ex­clu­sive HSP group, you still don’t have the abil­ity to do one im­por­tant thing, which is to in­voke change and de­vel­op­ment within the plat­form.

And yet, for some rea­son, HackerOne de­cided to take a per­for­ma­tive ap­proach to this, go­ing as far as to cre­ate a ded­i­cated plat­form feed­back chan­nel, but do­ing ab­solutely noth­ing with any of that feed­back. I can­not even count how many pieces of in­di­vid­ual feed­back and sug­ges­tions have been posted in there, with pos­i­tively zero ac­tion from HackerOne.

The AI Era

#

And then, around 2021, we all en­tered a new pe­riod of hu­man his­tory: the rise of AI and LLMs.

Beginning around this time, we all be­gan to wit­ness the huge gains in ve­loc­ity and the ca­pa­bil­i­ties of LLMs. You could now one-shot fea­tures in a frac­tion of the time, build cus­tom tools, and over­all get more done in less time.

But this is where HackerOne took a con­fus­ing turn. It is truly baf­fling to me how HackerOne man­aged to fum­ble this tech­nol­ogy in the worst way pos­si­ble. They had a 10-year back­log of fea­ture re­quests, and were handed one of the most pow­er­ful soft­ware de­vel­op­ment tools in the last 50 years. But in­stead of us­ing this to im­prove the plat­form and add long-re­quested fea­tures, they de­cided to move to­ward cre­at­ing “their own” AI as­sis­tant called Hai. Not only was Hai just a wrap­per on top of OpenAI, but it barely had any real unique ca­pa­bil­i­ties to help hack­ers or pro­grams do what they had been re­quest­ing from HackerOne to add to the core plat­form.

On top of this, the dri­ving force be­hind the com­pany, the hack­ers and co-founders who started the busi­ness, were qui­etly shoved away into the dun­geon of HackerOne. The web­site has them listed as part of the ex­ec­u­tive team, but they are pup­pets in their own busi­ness, barely get­ting to work on the prod­uct they built from the ground up.

The Enshittification of HackerOne

#

For al­most 10 years, Marten Mickos served as CEO of HackerOne. Some hack­ers loved Marten; oth­ers had mixed feel­ings. Personally, my in­ter­ac­tions with him were some­where be­tween fine and good. But I do be­lieve that he was very pas­sion­ate about bug bounty and did a lot of good for the com­pany dur­ing his time as CEO.

But in late 2024, Marten was re­placed by Kara Sprague, the for­mer Chief Product Officer at F5. You might be ask­ing your­self, what does a CPO of a net­work­ing com­pany know about hack­ing and bug bounty?

Honestly, I am not sure. What I will say is that there are mixed sig­nals on­line re­gard­ing what hap­pened to BIG-IP dur­ing her time as CPO at F5.

But that did­n’t stop the board from de­cid­ing she was the right fit for the fu­ture of the com­pany. And this was nei­ther the first nor the last in a se­ries of ques­tion­able busi­ness de­ci­sions made by HackerOne.

As AI agents con­tin­ued to grow and shift into var­i­ous iden­ti­ties, HackerOne’s iden­tity also be­gan to shift. Slowly but steadily, HackerOne re­branded it­self around a newly in­vented in­dus­try cat­e­gory: “CTEM”, or “Continuous Threat Exposure Management”.

HackerOne quickly be­gan to evolve into a soul­less cor­po­ra­tion ob­sessed with num­bers, busi­ness ob­jec­tives, and B2B sales. They switched from talk­ing about bug bounty pro­grams, live hack­ing events, and how they could help you stay se­cure, to pro­mot­ing their in-house AI se­cu­rity prod­uct and con­tin­u­ous se­cu­rity mon­i­tor­ing tool.

Wait, what? What in-house AI se­cu­rity prod­uct?

Your Reports Are Yours, We Promise

#

Sometimes, it all starts with a tweet.

In February 2026, well-known hacker zseano no­ticed that there was a surge in HackerOne em­ploy­ees leav­ing the com­pany and asked why that would be hap­pen­ing.

This ended up re­veal­ing that HackerOne had made ToS up­dates which made it so that re­ports sub­mit­ted on HackerOne could be used to train AI mod­els.

As you might ex­pect, this cre­ated quite a bit of noise, es­pe­cially within the HSP chats. One thing I’ve no­ticed is that the mod­ern day HackerOne only ever lets the founders out of the dun­geon for dam­age con­trol, and this was a per­fect time to pull that lever.

Within 24 hours, Alex Rice, co-founder, CTO (and CISO…?) of HackerOne emerged from the dun­geon to per­form dam­age con­trol. (This was the first time he had ever mes­saged in the HSP gen­eral chat since it was cre­ated two years ear­lier).

We do not train, fine-tune, or oth­er­wise im­prove GenAI or large lan­guage mod­els on re­searcher data. That in­cludes Agentic PTaaS. https://​docs.hackerone.com/​en/​ar­ti­cles/​10908081-hai-se­cu­rity-trust

We do not train, fine-tune, or oth­er­wise im­prove GenAI or large lan­guage mod­els on re­searcher data. That in­cludes Agentic PTaaS.

https://​docs.hackerone.com/​en/​ar­ti­cles/​10908081-hai-se­cu­rity-trust

And when asked to re­move Section 3.1 of the ToS, Alex promised that this would be taken care of and made clearer in an up­com­ing up­date to the ToS.

Within a week, CEO Kara Sprague had been looped in and made a fluffy LinkedIn post ex­plain­ing that

HackerOne does not train gen­er­a­tive AI mod­els, in­ter­nally or through third-party providers, on re­searcher sub­mis­sions or cus­tomer con­fi­den­tial data. Researcher sub­mis­sions are not used to train, fine-tune, or oth­er­wise im­prove gen­er­a­tive AI mod­els. This ap­plies across our plat­form, in­clud­ing ca­pa­bil­i­ties used within our Agentic PTaaS of­fer­ing and our in-plat­form AI, Hai.

HackerOne does not train gen­er­a­tive AI mod­els, in­ter­nally or through third-party providers, on re­searcher sub­mis­sions or cus­tomer con­fi­den­tial data.

Researcher sub­mis­sions are not used to train, fine-tune, or oth­er­wise im­prove gen­er­a­tive AI mod­els. This ap­plies across our plat­form, in­clud­ing ca­pa­bil­i­ties used within our Agentic PTaaS of­fer­ing and our in-plat­form AI, Hai.

Alex Rice even went on to the Critical Thinking Bug Bounty Podcast and did a guest spot to talk about this is­sue specif­i­cally and shut down any con­cerns about re­port data be­ing used to train AI mod­els.

Amazing, that’s set­tled then. HackerOne does­n’t use re­searcher data to train AI mod­els.

…Right?

Just Kidding They Never Were

#

Unfortunately for us, the pre­sent-day HackerOne fol­lows a rather im­pres­sive PR dam­age con­trol play­book:

Address fears

Ease con­cerns

Don’t change any­thing

About two months af­ter this drama, some­one men­tioned in the HSP chat that they had no­ticed a com­ment from hackerone-agent on one of their re­ports and wanted to know if this was an AI agent or an ac­tual hu­man.

The re­sponse from one of the HackerOne prod­uct man­agers was:

This is a pre­lim­i­nary re­view done by AI […] The H1 triage process has a step called “H1 Intake” […] which we’ve au­to­mated for cer­tain re­ports to make sure they reach the “Validation team” faster.

This is a pre­lim­i­nary re­view done by AI […] The H1 triage process has a step called “H1 Intake” […] which we’ve au­to­mated for cer­tain re­ports to make sure they reach the “Validation team” faster.

And when asked whether “certain re­ports” meant cer­tain re­port types or whether a pro­gram could en­able it every­where, they re­sponded:

We’re run­ning the analy­sis on all re­ports, the AI de­ter­mines what can be sent di­rectly to the val­i­da­tion team vs what needs to be re­viewed by a hu­man from the in­take team first. […] The sys­tem also learns from be­hav­iour so, if a rec­om­men­da­tion is re­jected […] it will take these into ac­count with its rec­om­men­da­tions as well.

We’re run­ning the analy­sis on all re­ports, the AI de­ter­mines what can be sent di­rectly to the val­i­da­tion team vs what needs to be re­viewed by a hu­man from the in­take team first. […] The sys­tem also learns from be­hav­iour so, if a rec­om­men­da­tion is re­jected […] it will take these into ac­count with its rec­om­men­da­tions as well.

Hang on a sec­ond.

I thought that re­searcher sub­mis­sions are not used to train, fine-tune, or oth­er­wise im­prove gen­er­a­tive AI mod­els.

But now all re­ports are be­ing run through an AI sys­tem, and the sys­tem is us­ing the out­comes of those re­ports to in­flu­ence how it han­dles fu­ture re­ports. So is that tech­ni­cally “fine-tuning”? Technically, no.

So how can both of these things be pos­si­ble?

Well, when I asked this, I re­ceived an in­cred­i­ble copy-paste re­sponse of what Alex Rice had said back in February:

Hai does not train, fine-tune, or oth­er­wise im­prove GenAI or large lan­guage mod­els on cus­tomer or re­searcher data: https://​docs.hackerone.com/​en/​ar­ti­cles/​10908081-hai-se­cu­rity-trust

Hai does not train, fine-tune, or oth­er­wise im­prove GenAI or large lan­guage mod­els on cus­tomer or re­searcher data: https://​docs.hackerone.com/​en/​ar­ti­cles/​10908081-hai-se­cu­rity-trust

We’re mak­ing auto mode the de­fault in Claude Code. Starting on August 14, new ses­sions on Pro, Max, and Team plans will run in auto mode. If you’ve al­ready set a dif­fer­ent de­fault your­self, you may get a one-time prompt ask­ing whether you want to switch to auto mode. If you have a pinned de­fault, noth­ing changes for you. The auto mode clas­si­fier uses a small num­ber of ex­tra to­kens per tool call, and we’re no longer charg­ing Claude Code users on Pro, Max, and Team plans for that clas­si­fier over­head, ef­fec­tive to­day.

Auto mode re­mains opt-in for now on Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud’s Agent Platform, and Microsoft Foundry, giv­ing ad­mins time to re­view the change. In the com­ing month, work­ing with our cloud part­ners, we plan to make it the de­fault across all of these and no longer charge for clas­si­fier over­head. In the mean­time, Enterprise ad­mins can make Claude Code’s auto mode the de­fault through man­aged set­tings.

Auto mode is de­signed to bal­ance users’ de­sire not to be in­ter­rupted with a sys­tem that helps avoid harm­ful ac­tions: in­stead of prompts, it routes each tool call through a clas­si­fier tar­geted at block­ing ac­tions that are ir­re­versible, de­struc­tive, or aimed out­side your en­vi­ron­ment. When the clas­si­fier blocks some­thing, Claude usu­ally finds a safer way to pro­ceed on its own or asks you di­rectly for the go-ahead; if it can’t make progress—three blocks in a row, or twenty across a ses­sion—Claude Code falls back to man­ual ap­provals.

We spent the last sev­eral months test­ing whether auto mode is as safe or safer than an av­er­age user click­ing through prompts. We ran in­ter­nal red-team­ing, third-party red-team­ing and prompt-in­jec­tion eval­u­a­tions, a con­trolled study with 1,053 paid testers, and analy­sis of real pro­duc­tion ses­sions. On every mea­sure we tested, auto mode matched or out­per­formed man­ual re­view.

Auto mode also lets Claude work au­tonomously for longer stretches. This makes mod­els built for long-run­ning work, like Claude Opus 5, more prac­ti­cal to leave run­ning for hours on large tasks. Reducing over­head for users also in­creases out­put. Among Teams & Enterprise adopters, auto mode users ship about 25% more PRs. Unblocking Claude al­lows tasks to run longer un­in­ter­rupted and get more work done. Teams at Adobe, Nuro, Gusto, and Garner Health al­ready run auto mode as their pro­duc­tion de­fault.

Below, we share the safety data and cus­tomer re­sults mo­ti­vat­ing the change, and how to set a dif­fer­ent de­fault if you pre­fer.

Comparing man­ual re­view to auto mode

Data sug­gests that man­ual re­view can be­come ha­bit­ual: users ap­prove 97% of per­mis­sion prompts in Claude Code. While most prompts are likely for safe, rou­tine com­mands, an ap­proval rate that high sug­gests many users are click­ing through re­flex­ively rather than re­view­ing each com­mand. These prompts ask de­vel­op­ers to make dozens or hun­dreds of im­por­tant se­cu­rity de­ci­sions every day, of­ten in the mid­dle of pro­jects, which places the re­view bur­den on users and in­creases the chance that some­thing im­por­tant slips through the cracks. Data also sug­gests that users more fre­quently scru­ti­nize and push back on other types of di­a­logues: for ex­am­ple, when Claude pre­sents a plan for ap­proval, users re­ject 39% of them. But for in­di­vid­ual per­mis­sions re­quests, the re­jec­tion rate is only 3%.

The same pat­tern shows up in set­tings files. As of June 2026, 49.5% of ac­tive CLI users have man­u­ally cre­ated a Bash al­low-rule—5% al­low any shell com­mand out­right, and an­other 43% have in­ter­preter rules like Bash(python:*) or Bash(node:*) that are es­sen­tially equiv­a­lent in prac­tice—and that share is grow­ing roughly 5 per­cent­age points every 5 weeks. Beyond al­low-rules, 62% of users have used by­passPer­mis­sions or clicked “don’t ask again” on Bash, and 25% of in­ter­ac­tive ses­sions start in by­pass per­mis­sions mode.

Permission rules still fire be­fore the clas­si­fier in auto mode, ex­cept for al­low rules broad enough to grant ar­bi­trary code ex­e­cu­tion (e.g. python:*). These ar­bi­trary rules are set aside while in auto mode, since they would let com­mands skip the clas­si­fier en­tirely. Settings files aren’t mod­i­fied, and the rules ap­ply again the mo­ment you switch to an­other mode.

Improving safety with auto mode

Research con­ducted in­ter­nally and through sev­eral third par­ties sug­gests that auto mode is safer than how a typ­i­cal user en­gages with per­mis­sion prompts to­day. We tested auto mode against what de­vel­op­ers ac­tu­ally ap­prove when they’re click­ing through per­mis­sion prompts. Across each of these mea­sures—in­ter­nal red-team­ing, third-party pen­e­tra­tion test­ing, and analy­sis of real-world ses­sions—auto mode matched or out­per­formed hu­man ap­proval.

Auto mode out­per­forms man­ual per­mis­sions on safety

We hired 1,053 paid testers through a re­search ven­dor for a cod­ing study. These par­tic­i­pants worked in a test en­vi­ron­ment set up specif­i­cally for the study, not in their own code­bases or on real pro­jects. Participants knew they were be­ing eval­u­ated, but—fol­low­ing stan­dard blind-study de­sign—weren’t told which be­hav­ior was be­ing mea­sured. Partway through each ses­sion, a sin­gle per­mis­sion prompt was swapped for a clearly dan­ger­ous com­mand, and the ven­dor recorded whether the tester ap­proved it (Note: ap­prov­ing the prompt never re­sulted in any­thing dan­ger­ous be­ing run; only the text of the prompt testers saw was changed).

The testers caught the dan­ger­ous com­mand just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same com­mands (937 of 1,053). Head to head, auto mode blocked 800 com­mands that a hu­man ap­proved, while hu­mans blocked only 6 that auto mode al­lowed. As ses­sions got longer, hu­mans did worse: they blocked about 17% of dan­ger­ous com­mands early in a ses­sion, drop­ping to about 5% af­ter 50 or more prior prompts, while auto mod­e’s block rate stayed flat re­gard­less of ses­sion length.

Auto mode pre­vents more harm­ful ac­tions

Our re­search also sug­gests that auto mode leads to fewer harm­ful ac­tions than man­ual per­mis­sions mode.

We ex­am­ined how auto mode per­forms in real us­age. From May to June 2026, we ex­am­ined ses­sions our safety pipeline had flagged for re­view, drawn only from ac­counts that have opted in to data use for train­ing and analy­sis. We re-graded each one with a model on two 0 – 10 scales. The first was harm sever­ity with 10 be­ing com­pany-wide, ir­re­versible harm, such as leak­ing a com­pa­ny’s en­tire source code, 7 rep­re­sent­ing pro­duc­tion-level sever­ity such as delet­ing rows from a pro­duc­tion data­base, and 0 a fully re­versible ac­tion con­fined to the lo­cal work­space, like over­writ­ing a scratch file. The sec­ond was how ex­plic­itly the user had asked for the ac­tion, so we could sep­a­rate harm­ful ac­tions the user di­rectly re­quested from harm­ful ac­tions the agent took with less ex­plicit di­rec­tion.

Among the flagged ses­sions, those that went through man­ual ap­proval con­tained se­ri­ous un­in­tended harm more than twice as of­ten as auto mode ses­sions. At pro­duc­tion-level sever­ity (7+), 6.3% of man­u­ally ap­proved ses­sions con­tained a harm­ful ac­tion the user had­n’t ex­plic­itly asked for, com­pared to 2.4% of auto mode ses­sions, and the gap held at every sever­ity level we tested.

Adversarial red-team­ing made auto mode stronger

We worked with Apollo Research, a UK-based AI safety startup, on a two-week pi­lot in­ject­ing syn­thetic at­tacks into real cod­ing tra­jec­to­ries, across three datasets cov­er­ing broad fail­ures, data ex­fil­tra­tion, and safety-re­lated threats.

The en­gage­ment fol­lowed a stan­dard find-fix-ver­ify loop. Apollo shared a set of suc­cess­ful at­tacks along with rec­om­men­da­tions to strengthen auto mode. We hard­ened the clas­si­fier against them pri­mar­ily by giv­ing it more con­text about the en­vi­ron­ment it’s pro­tect­ing (repository vis­i­bil­ity, git state, and the data-han­dling rules de­scribed be­low).

After hard­en­ing, Apollo re-tested on a sep­a­rate held-out at­tack set that we never had ac­cess to. Auto mode caught about half of the at­tacks it pre­vi­ously missed, at a cost of miss­ing about 2% of at­tacks it pre­vi­ously caught. Since we could­n’t tune against the held-out set, this sug­gests the hard­en­ing gen­er­al­izes to new at­tacks rather than patch­ing the spe­cific ones Apollo shared. Across both the shared and held-out sets, the clas­si­fier’s miss rate fell from 12% to 7%.

These at­tacks are syn­thetic and ad­ver­sar­ial by de­sign, built to find where the clas­si­fier fails, and more ma­li­cious than any­thing Claude would do un­prompted. The 7% miss rate is mea­sured against this set and should not be taken as the miss rate on real traf­fic.

Auto mode re­duces prompt in­jec­tion risk

The auto mode clas­si­fier adds an ad­di­tional layer of de­fense against prompt in­jec­tion at­tacks that try to force the agent to de­vi­ate from the user’s in­struc­tions. When run­ning with auto mode, tool re­sults are scanned by probes for po­ten­tially ma­li­cious in­struc­tions, and auto mode checks that ac­tions are aligned with user in­tent. We tested auto mode com­pared to an un­guarded model to il­lus­trate the power of this de­fense-in-depth ap­proach.

We com­mis­sioned an eval­u­a­tion from a third party, Trajectory Labs, who tested dif­fer­ent mod­els within the lat­est pub­licly avail­able ver­sions of Claude Code and Codex as of July 17th 2026.1 They tested 72 in­di­rect prompt in­jec­tion sce­nar­ios held out from Anthropic. Each sce­nario was tested 10 times. Successful at­tacks would, in a non-test­ing en­vi­ron­ment, re­sult in ir­re­versible ac­tions that could harm the user such as sen­si­tive-data ex­fil­tra­tion, fi­nan­cial fraud, or cre­den­tial phish­ing. The at­tacks were op­ti­mized against Claude Opus 4.7, which is not in the re­ported set, so every model in the eval­u­a­tion faced them as un­seen at­tacks. In ad­di­tion to auto mode, the eval­u­a­tions looked at Claude Code’s by­passPer­mis­sions mode and Codex’s Full Access mode.

Both Codex and Claude Code were eval­u­ated us­ing an iden­ti­cal browser in­te­gra­tion pro­duced by Trajectory Labs, PBC. This in­te­gra­tion pro­vides a set of MCP tools which are a thin wrap­per around com­mon Chrome APIs such as `navigate`. Safeguards built into first-party browser in­te­gra­tions such as the Chrome ex­ten­sions pro­vided by OpenAI and Anthropic were not tested. As such, these re­sults should be viewed as a mea­sure­ment of the un­der­ly­ing model, rather than the com­plete set of safe­guards which might ex­ist in a given de­ploy­ment.

In this eval­u­a­tion, none of the 720 at­tack at­tempts suc­ceeded against Claude Fable 5, Opus 5, or Sonnet 5 run­ning auto mode. On the other hand, 5.83% of the at­tacks suc­ceeded against GPT-5.6 Sol run­ning Codex’s Auto-review mode. Notably, this is greater than the 0.09% av­er­age at­tack suc­cess rate against our lat­est mod­els run­ning in by­passPer­mis­sions mode with­out ad­di­tional safe­guards. The tests showed a 19.03% at­tack suc­cess rate against GPT-5.6 Sol when run­ning in Full Access mode. Attack suc­cess rates dif­fer be­tween tasks where tools re­turn re­sults as text and tasks that re­quire in­ter­act­ing with a browser through screen­shots, as shown be­low.

Three in­ci­dents auto mode pre­vented in­side Anthropic

Auto mode is also the de­fault for all Claude Code in­ter­nal us­age at Anthropic. Here are three ac­tions the clas­si­fier pre­vented in­ter­nally:

An off-net­work data leak: When an up­load to an in­ter­nal drive failed, Claude’s fall­back was to pub­lish the same re­port to a pub­lic code-shar­ing site. Auto mode de­nied the fall­back and prompted the user for next steps.

A de­struc­tive mass op­er­a­tion: In a long-run­ning ses­sion, Claude at­tempted a mass process kill across roughly two thou­sand pods and queued dele­tions that would have torn down hun­dreds of GPUs of in-flight train­ing jobs. Auto mode flagged the de­struc­tive com­mands be­fore ex­e­cu­tion.

Over-broad priv­i­lege es­ca­la­tion: Asked to pro­vi­sion read-only billing ac­cess, Claude reached for a cloud role that grants full ad­min­is­tra­tive con­trol at the ac­count root. Auto mode caught the mis­match be­tween what was re­quested and what roles would have been granted.

In each case, Claude ei­ther found a safer path on its own or checked in with the user be­fore pro­ceed­ing.

Making auto mode even safer

We’re con­tin­u­ously in­vest­ing in new auto mode fea­tures that make it safer and eas­ier to ship pro­duc­tion code. Recent ex­am­ples in­clude:

Hard de­nies: Data ex­fil­tra­tion, like send­ing your code or se­crets some­where ex­ter­nal, sits in a cat­e­gory the clas­si­fier is de­signed to never ap­prove. To run an ac­tion like that, you have to switch out of auto mode or run the com­mand your­self. Hard deny rules are cus­tomiz­able via set­tings so you can add more rules that you never want al­lowed even when re­quested by users in your or­ga­ni­za­tion.

Rules for data ac­cess and shar­ing: The clas­si­fier now car­ries ex­plicit rules dis­tin­guish­ing se­crets and po­ten­tially sen­si­tive/​con­fi­den­tial in­for­ma­tion—and where each can be ac­cessed and shared. To make those rules en­force­able, it also checks whether the des­ti­na­tion of a git push or pull re­quest is pub­lic, pri­vate, or trusted be­fore the ac­tion runs. The same push can be rou­tine or an ex­fil­tra­tion de­pend­ing on where it lands: code that be­longs in your team’s pri­vate repos­i­tory should­n’t end up in a pub­lic one, and the clas­si­fier is now de­signed to flag when this might hap­pen.

Checking git sta­tus be­fore de­struc­tive git ac­tions: Before a com­mand that could dis­card un­com­mit­ted work, like git re­set –hard, the clas­si­fier sees the repos­i­to­ry’s cur­rent git sta­tus, let­ting auto mode know what is be­ing re­set.

Prompt in­jec­tion screen­ing: When Claude pulls con­tent from ex­ter­nal sources, like web pages, file con­tents, or tool out­puts, an API-side probe checks that con­tent for at­tempts to hi­jack Claude’s be­hav­ior. When some­thing looks like an in­jec­tion at­tempt, a warn­ing is added to Claude’s con­text be­fore the re­sult is shared with the user.

Auto mode in pro­duc­tion

Teams are al­ready run­ning auto mode as their pro­duc­tion de­fault:

Adobe’s mer­chan­dis­ing plat­form team is re­spon­si­ble for keep­ing pric­ing and pro­mo­tional pages ac­cu­rate and cur­rent across 90+ coun­tries and 30+ lan­guages on Adobe.com. They built an agen­tic loop to build and ver­ify those pages, run­ning it in auto mode so en­gi­neers re­ceive fin­ished PRs for re­view.

Nuro runs auto mode across its re­search and en­gi­neer­ing orgs, us­ing it to power overnight re­search agents that hill-climb eval­u­a­tion met­rics and re­turn fin­ished PRs for re­view by morn­ing.

Gusto adopted auto mode to end the per­mis­sion fa­tigue that was push­ing en­gi­neers to­ward by­pass­ing per­mis­sions checks en­tirely. About 10% of ses­sions since mid-May in­clude a clas­si­fier de­nial—ev­i­dence it’s do­ing real work with­out slow­ing le­git­i­mate tasks.

Garner Health pushed auto mode as the de­fault to all 550 em­ploy­ees via man­aged set­tings, stan­dard­iz­ing a com­pany-wide soft­ware de­vel­op­ment life­cy­cle (SDLC) that no longer de­pends on hand-cu­rated com­mand al­lowlists.

eBook

Learn how these cus­tomers are run­ning auto mode in pro­duc­tion.

Getting started

For Pro, Max, and Team users: if you haven’t set a de­fault per­mis­sion mode, you’ll re­ceive an in-prod­uct no­tice and new ses­sions will start in auto mode au­to­mat­i­cally. If you’ve set a dif­fer­ent de­fault, you may see a one-time prompt ask­ing if you’d like to switch your de­fault to auto mode. If your Team ad­min has set a de­fault in man­aged set­tings, noth­ing changes for you.

For Enterprise users and users who ac­cess Claude Code via the Claude API, auto mode re­mains opt-in for now. We plan to make auto mode the de­fault in the com­ing month, and we’ll no­tify Enterprise ad­mins be­fore we do.

To switch modes, press Shift+Tab in the CLI or use the mode drop­down on the desk­top app. Admins can pin an org-wide de­fault with `defaultMode` in man­aged set­tings, or turn auto mode off en­tirely with `disableAutoMode`.

Finally, while we be­lieve auto mode re­duces risk for most users, it re­lies on clas­si­fi­ca­tion sys­tems and there­fore does not elim­i­nate risk. For high-stakes changes to pro­duc­tion in­fra­struc­ture, we still rec­om­mend re­view­ing Claude’s ac­tions your­self. See the auto mode docs for full con­fig­u­ra­tion in­struc­tions.

‍

This ar­ti­cle was writ­ten by Conner Phillippi, with con­tri­bu­tions by Nicholas Carlini, Isaac Fung, John Hughes, Alex Isken, Shawn Moore, Javier Rando, and Molly Vorwerck. The au­thors would also like to thank Yacine Azmi, Chandler Bair, Kefan Chen, Boris Cherny, Ian Grunert, Lydia Hallie, Alex Kleiman, Lauren Polansky, Deon Poncini, Robert Schonberger, Marie Vachovsky, Qing Wang, Cat Wu, Daniel Xu, and Alice Zhao.

‍

1 We eval­u­ated Claude Code v2.1.205 and Codex v0.144.5. OpenAI re­leased a new ver­sion of Auto-review last week that could change the re­sults.

No items found.

Main

Front Page Full Index

Photos

Blog

Vlog

FAQ

Account

Donate as much as you like, and re­ceive a life­time priv­i­leged ac­cess to this web­site.

Donate Log In

Your Favorites

Become a pa­tron and ac­cess your fa­vorite sound­scapes from this sec­tion.

Site Favorites

Distant Thunder  Japanese Garden  Irish Coast  Stormy Weather  Medieval Library  Floating  The Pilgrim  Rain on a Tent

What’s New

Aug 5th: Dry Storm — Aug 3rd: I Made Tinnitus My Friend (Then It Disappeared) — Jul 13th: The Architect’s Playlist — Jun 24th: Sound Horizon — Jun 24th: There Is Life After Adobe — Jun 8th: Ticolandia — May 18th: Walking Through — May 8th: Still Alive, Still Picky — Apr 14th: Berkshire Waters — Apr 10th: Three Ways to See Sound, and a Switch — Mar 23rd: Inner Gong — Mar 23rd: Same Sound, New Colors

Sign Up RSS Feed Mastodon

Case File No. 001

Death at Blackwood Manor

A poi­soned pa­tri­arch. Five guests. One locked-in truth.

Evidence Reel

Watch Chase demo the case

Interviewing sus­pects, press­ing them on their al­i­bis, and catch­ing the con­tra­dic­tions.

Authored by Chase Myers

Mars Bar from 1991 found - and it’s 20g big­ger than to­day’s

5 hours ago

Eleanor MaslinEast Yorkshire and Lincolnshire

Victoria Gordon

A 35-year-old Mars Bar has been found dur­ing a house clear­ance — and the dis­cov­ery has gone vi­ral amid claims it high­lights the ef­fect of “shrinkflation”.

The choco­late bar with a best-be­fore date of 1991 was found dur­ing a clear-out of a house in Scunthorpe.

Victoria Gordon, who runs the clean­ing ser­vice, posted a photo on so­cial me­dia of the 62.5g bar along­side one of to­day’s Mars Bars, which is 40g.

“It was nearly as big as my hand, which was kind of why I no­ticed it,” she said.

Victoria Gordon

Speaking on BBC Radio Lincolnshire, Gordon said: “We were clear­ing out a hoard­er’s house and every­thing we were root­ing through was decades old.

“This Mars Bar stood out to me be­cause as I picked it up it was nearly the whole length of my hand.

“I was like, ‘Wow, look at the size of that!’”

A Mars spokesper­son said: “Over the last 35 years, we have made a num­ber of up­dates to our bar sizes and pack for­mats to re­flect con­sumer de­mand, along­side con­sid­er­ing wider ex­ter­nal fac­tors such as man­u­fac­tur­ing costs and the price of co­coa.”

Supplied

Gordon, who runs Pocket Rockets, is not sure what she will do with the bar, but she said she might be sit­ting on a “gold mine”.

“I do post some hoard­ing videos but I’ve never had any­thing go this vi­ral,” she said.

“It’s so fas­ci­nat­ing what peo­ple find so in­ter­est­ing. I al­most put it in the skip [but] I might do a UK tour with it.”

Related sto­ries

Set a fin­ish line. The agent keeps work­ing to­ward it, turn af­ter turn — even with the app closed.

Run one task across up to five mod­els. Keep the best re­sult, or fuse the strongest parts.

A large diff, grouped into or­dered steps that ex­plain how the change fits to­gether.

Point at an el­e­ment in your run­ning app and send the agent every­thing be­hind it.

Start from a GitHub is­sue or PR, send failed checks back, and merge with­out leav­ing.

Run a prompt on a cron sched­ule. Pair it with Session Goals to aim at an out­come.

ma­cOS, Windows, and Linux apps

Multi-window pro­ject work­flows

Open In short­cuts for Finder, Terminal, and your ed­i­tor

Project Actions for dev servers, SSH for­ward­ing, and lo­cal URLs

Browser ac­cess from any­where

Phone- and tablet-friendly con­trols

A na­tive mo­bile app, now in beta

A UI pass­word gate that makes browser ac­cess pub­lic-ready

Background no­ti­fi­ca­tions and cross-tab ses­sion ac­tiv­ity

Editor-native work­flow

Open files di­rectly from tool out­put

Right-click con­text ac­tions on se­lec­tions and files

Agent Manager for par­al­lel multi-model runs

After years of switch­ing be­tween IDEs and TUIs, I found the sweet spot for every­thing I need: Openchamber.

After years of switch­ing be­tween IDEs and TUIs, I found the sweet spot for every­thing I need: Openchamber.

Harsha Kotcherlakota

“I just want to say the app it­self is phe­nom­e­nal. The level of pol­ish is just un­real. I saw OpenChamber back when it was a small pro­ject, I think maybe a cou­ple months ago, and now it is un­rec­og­niz­able. Truly amaz­ing work. The lat­est re­lease with its stream­ing fea­ture is every­thing I could have pos­si­bly asked for and more. It is gor­geous and smooth.”

Srikanth.CashlessConsumer

“Opencode + OhMyOpencode + Openchamber. This is some cooked stack. VSCode looks like legacy notepad++ now.”

Daniel Duma

“Stop us­ing Openclaw for cod­ing! Use OpenCode and OpenChamber in­stead!”

Abundance Mentality

“Seriously, I’ve spent al­most the whole week try­ing to find a tool that made sense to or­ches­trate agents and, as a dev (actually, a de­vops), open­cham­ber is the only one that felt nat­ural and log­i­cal.”

Code and ses­sions stay with you

Project names, paths, prompts, code, diffs, and ses­sion con­tent are not col­lected by OpenChamber.

Remote ac­cess is pro­tected

Browser ac­cess can be gated with a UI pass­word, and tun­nel links can be ro­tated or re­voked when they should no longer work.

Private Relay, no open ports

Pair a de­vice with a one-time QR code and con­nect through Private Relay with­out open­ing ports or ex­pos­ing a pub­lic server. The con­nec­tion is end-to-end en­crypted and can be re­voked at any time.

Privacy is in­spectable

OpenChamber is open source, so the pri­vacy model is vis­i­ble in the code in­stead of hid­den be­hind pol­icy lan­guage.

Yes. OpenChamber is open source, and the code is avail­able on GitHub.

OpenChamber runs on the OpenCode SDK to­day — we picked it for the best open-source agent ex­pe­ri­ence avail­able. Install it with curl -fsSL https://​open­code.ai/​in­stall | bash.

Yes. OpenChamber it­self is free to use.

Yes. You can open it re­motely through the browser UI, use tun­nels when needed, and pro­tect ac­cess with a UI pass­word.

More ques­tions? Check the doc­u­men­ta­tion