Proč AI coding nástroje a nové knihovny nemají běžet přímo na vašem Macu

Když se dnes řeší bezpečnost kolem vibe coding toolů, často to zní, jako by šlo o úplně nový problém. Ve skutečnosti nejde o nic nového. Jen jsme si poslední roky zvykli spouštět cizí kód, cizí dependencies a čím dál častěji i cizí shell commandy přímo na svém lokálním stroji, kde máme SSH klíče, .env soubory, přihlášený browser, přístupy do cloudu a často i produkci.

AI tooling ten problém nevymyslel. Jen ho dost zesílil a udělal viditelnější.

Na macOS je to podle mě vidět asi nejlíp. Spousta lidí nechce vyvíjet v Dockeru, protože DX jde rychle dolů a kontejnery na Macu pořád nejsou bez overheadu. Takže reálný default je pořád stejný: všechno běží na host machine a doufá se, že se nic nestane.

Tohle funguje přesně do chvíle, než to nefunguje.

LiteLLM jen připomněl starý problém

24. března 2026 se na PyPI objevily kompromitované verze litellm 1.82.7 a 1.82.8. Nešlo o žádný exotický exploit. Stačilo udělat pip install a do prostředí se dostal škodlivý .pth soubor, který se spouštěl při startu Pythonu.

Ten pak sahal po věcech, které na vývojářském stroji typicky najde snadno:

• SSH klíče
• .env soubory
• cloud credentials
• další secrets a konfigurační soubory

Pak je odesílal na remote server.

Na tomhle incidentu je důležité hlavně to, jak banální ten attack path byl. Nepotřeboval rozbít Python, obejít kernel ani přesvědčit člověka, aby spustil něco extra. Stačilo, že vývojář udělal to, co dělá běžně každý den: nainstaloval si dependency.

Paradoxně se na celou věc přišlo rychleji i proto, že malware nebyl úplně dobře napsaný a na některých strojích odpálil fork bombu. Kdyby se držel při zemi a jen tiše exfiltroval data, je dost možné, že by to déle unikalo pozornosti.

Podle mě by tomuhle podlehla velká část běžných developerů, ne jen lidi, kteří experimentují s vibe codingem. Důvod je jednoduchý: málokdo má lokální Python prostředí opravdu izolované.

A ani JavaScript svět na tom nebyl líp

Tohle mimochodem není jen Python story.

30. a 31. března 2026 se kompromitoval i axios, jedna z nejpoužívanějších knihoven v JavaScript světě. Útočník převzal maintainer účet na npm a publikoval škodlivé verze axios@1.14.1 a axios@0.30.4.

Zajímavé je, že škodlivý payload nebyl přímo v samotném axiosu. Ty verze jen přidaly novou transitive dependency plain-crypto-js, která se spouštěla přes postinstall hook. Jinými slovy: i tady stačilo udělat obyčejný install a z dependency chainu se stal execution chain.

To je přesně důvod, proč mi přijde nebezpečné tvářit se, že supply-chain riziko je jen problém nějakých pochybných balíčků z okraje ekosystému. Není. Minulý týden se to ukázalo i v jednom z nejběžnějších HTTP clientů pro Node.js.

exclude-newer je rozumný default

Jeden z mála levných guardrailů, které dávají smysl skoro každému, je neinstalovat úplně čerstvé releasy balíčků.

V uv jde použít exclude-newer, takže si dependency resolution omezíte jen na balíčky publikované před zvoleným datem:

‍

[tool.uv]
exclude-newer = "2026-03-24"

‍

Tohle není magická obrana. Jen si tím kupujete čas. Když budete držet třeba 14denní odstup, je slušná šance, že se během té doby na kompromitovaný release přijde a někdo ho stáhne nebo alespoň rozjede warningy napříč komunitou.

Úplně stejná logika platí pro AI coding tools

Stejně jako nechcete bezmyšlenkovitě pouštět čerstvé dependencies na hostu, nechcete na hostu pouštět ani code generátor s plným přístupem ke všemu okolo.

Tohle není argument proti Codexu, Claude Code ani jakémukoliv jinému nástroji. Je to argument proti tomu, jak velký trust těm nástrojům dáváme by default.

Lehké sandboxy jsou dobrý začátek. Codex CLI na macOS historicky používal sandbox-exec a umí tím dost omezit, kam proces smí sáhnout. V Claude Code jde sandbox zapnout přes /sandbox. V obou případech je to výrazně lepší než režim, kde agent vidí celý disk a může bez omezení pouštět shell.

Tohle má dvě praktické výhody:

• agent typicky vidí jen repozitář nebo explicitně povolené cesty
• nemusíte potvrzovat každou drobnost jen proto, abyste měli aspoň nějaký control surface

Pro běžné čtení, editaci souborů a část shell práce je to fakt příjemný middle ground.

Kde tenhle model naráží

Problém je, že lehký sandbox není totéž co skutečná izolace.

Jakmile nástroj potřebuje dělat něco trochu praktičtějšího, začnou vylézat hrany:

• instalace balíčků přes uv, pip, npm nebo podobné nástroje často sahá do globálních cache
• browser tooling nemusí uvnitř sandboxu fungovat dobře nebo vůbec
• některé MCP servery potřebují přístup mimo boundary repa
• dřív nebo později narazíte na command, který prostě musíte pustit mimo sandbox

A v ten moment se stejně vyhodí otázka na vibecodera jestli může systém sandbox odejít a většina klikne prostě na "Yes".

Proto mi přijde důležité neplést si "má nějaký sandbox mode" s "je to bezpečně izolované".

Co podle mě dává smysl víc

Pokud chceme agenty nebo code generátory používat vážně, potřebujeme reálný sandbox. Ideálně separátní VM nebo microVM pro každý projekt. Na Macu to může být něco ve stylu Lima nebo obdobné VM-based řešení. Docker sandboxy jsou v principu podobný směr, i když na macOS často naráží na performance a DX.

Pointa ale není konkrétní produkt. Pointa je trust boundary.

Do takového prostředí přesunete jen to, co ten konkrétní projekt opravdu potřebuje:

• checkout repa
• project-scoped credentials
• lokální cache jen pro ten projekt
• případně browser session nebo MCP servery, ale zase jen tam, kde to dává smysl

Tím snížíte blast radius hned dvakrát.

Za prvé: když agent spustí destruktivní command typu rm -rf /, tak zničí maximálně svůj sandbox.

Za druhé: když nainstalujete kompromitovanou dependency typu infikovaného litellm, tak z ní neodtečou všechny credentials z celého laptopu, ale maximálně to, co jste do toho konkrétního prostředí dali. Ideálně jen dev secrets pro jeden projekt.

To pořád není příjemný incident. Ale je to o řád lepší incident.

Classifier je fajn, ale není to sandbox

Claude Code teď přidal i auto mode, kde nad citlivějšími akcemi běží další classifier. Ten vyhodnocuje transcript a jednotlivé tool calls, hlavně Bash commandy a další akce mimo repo, a snaží se blokovat věci jako data exfiltration, credential hunting nebo destruktivní zásahy mimo scope úkolu.

To je rozumný posun. Approval fatigue je reálná a ruční odklikávání všeho není moc udržitelný model.

Ale i tady je podle mě důležité držet si správné očekávání: classifier je guardrail, ne izolace.

Stejně tak to neřeší supply-chain problém. Pokud si uvnitř důvěryhodného prostředí nainstalujete škodlivý balíček, classifier nad Bash commandy vám nepomůže proti tomu, co ten balíček provede při importu nebo startu interpreteru.

Co bych z toho bral jako praktický default

Můj aktuální take je jednoduchý:

• nepouštět úplně čerstvé dependencies bez odstupu
• neprovozovat AI coding tools přímo na host machine s plným přístupem
• když už používám lehký sandbox, nebrat ho jako finální řešení
• pro důležitější práci mít per-project izolované prostředí s omezeným blast radiusem

Tohle všechno platilo už dávno předtím, než někdo vymyslel termín vibe coding.

Jen teď už není moc kam uhýbat. Když dáte agentovi shell, filesystem, browser a credentials, dáváte mu v praxi velmi silné pravomoci. A jak ukázal LiteLLM incident, podobně silné pravomoci dostává i obyčejný package manager ve chvíli, kdy mu bez izolace dovolíte instalovat cizí kód přímo na svůj laptop.

To není niche security debata. To je docela obyčejný engineering default, který jsme měli mít už dávno.

Apple právě pracuje na novém container enginu který tohle všechno bude mít doufám built in. Do té doby se snažím opravdu koukat kdykoliv se spouští příkazy mimo sandbox.