Vaše AI dev nástroje jsou tím útočným povrchem

Devátého června někdo nahrál payloady kradoucí credentials do víc než sedmdesáti open-source repozitářů hostovaných pod GitHub organizacemi spojenými s Microsoftem. Zajímavé na tom není to číslo, ale cílení. Malware se nešířil naslepo. Kontroloval přítomnost konkrétních nástrojů na stroji, kde se kód spouštěl, Claude Code, Gemini CLI, agentní rozšíření pro VS Code, a spustil se jenom tehdy, když je našel. To vám napovídá, že lidé za tím přesně věděli, koho chtějí a co ti lidé mají ve svém prostředí. Pokud jste si za posledních osmnáct měsíců nasadili agentní nástroje na psaní kódu, a to udělal skoro každý, pak vaši nejproduktivnější inženýři, ti, co stáhnou ukázkový repo, aby otestovali MCP integraci nebo se podívali, jak někdo zapojil tool call, byli přesně tou skupinou v zóně zásahu.

Samotné payloady byly nudné v tom dobrém inženýrském smyslu. Přečetly proměnné prostředí, prohledaly obvyklá místa s credentials, ~/.aws/credentials, ~/.config/gcloud, .env soubory v adresáři, kam si dev klonoval, a npm a pip tokeny, které skoro nikdo nerotuje. Pak úlovek odeslaly přes něco, co vypadalo jako běžný telemetrický provoz. Na vývojářském stroji, na kterém běží půl tuctu agentů, kteří stejně neustále volají domů, je to v podstatě neviditelné. Egress filtrováním se z tohohle nedostanete, když legitimní nástroje generují přesně stejný tvar odchozího provozu jako exfiltrace.

Lekce, kterou si lidé z tohohle odnesou, bude „dávej pozor, jaké repo klonuješ". Ta lekce je správná, ale malá. Větší věc je, že vrstva nástrojů pod AI-asistovaným vývojem se stala vlastním samostatným povrchem a většina týmů do ní nemá vůbec žádný vhled.

Zamyslete se, kam šly vaše peníze na bezpečnost posledních deset let. SAST a DAST na aplikační kód, scanování závislostí toho, co vaše aplikace shipuje, detekce secrets v CI, možná software bill of materials, abyste příští Log4j otázku zvládli za odpoledne místo za týden. Tohle všechno chrání artefakt, který deployujete. Nic z toho nechrání laptop, na kterém ten artefakt píše váš senior backend inženýr. A na tom laptopu teď běží malá konstelace dlouho žijících procesů se širokým přístupem k souborovému systému, k síti a v mnoha případech i se schopností spouštět libovolné shell příkazy jménem vývojáře.

MCP server je daemon, který jste si nainstalovali, protože Claudovi dovolil číst vaše Jira tickety nebo dotazovat se na staging databázi. Sedí tam, drží credentials, naslouchá na lokálním portu a přijímá tool cally od LLM, který s radostí udělá cokoliv, k čemu ho chytře formulovaný prompt přesvědčí. Lokální agent runtime je věc, která čte soubory, zapisuje soubory a spouští příkazy, by design. LiteLLM a zbytek open-source proxy a framework vrstvy je plný cest, které načítají config z prostředí, tahají provider klíče a routují requesty přes jakýkoliv endpoint, na který config ukazuje. Každému z těchhle nástrojů implicitně důvěřujete, protože vás zrychlují, a důvěra je celý ten problém, protože nic z toho neprošlo tou review bránou, kterou by prošla produkční závislost.

Když teď děláme bezpečnostní audity pro klienty, první otázka, kterou se ptáme, není o aplikaci. Je to „co běží na strojích lidí, kteří tu aplikaci píšou", a skoro nikdo na to nemá čistou odpověď.

Sedněte si a opravdu si vytrasujte zónu zásahu, protože pokud jste si tohle cvičení neudělali, abstraktní riziko zůstane abstraktní a budete ho dál odsouvat. Začněte jediným kompromitovaným vývojářským strojem a zeptejte se, co útočník získá v prvních šedesáti vteřinách. Na typickém setupu seniora to jsou cloudové credentials s dostatečným IAM scope na čtení produkčních dat, GitHub token s write přístupem do privátních repozitářů, kubeconfig namířený na živý cluster, connection stringy do databáze ve třech různých .env souborech a cokoliv, co si agent runtime nacachoval, když byl nápomocný.

Teď ten laterální pohyb, kde to začne být ošklivé. Ten GitHub token nečte jenom kód, umí kód i pushnout, což znamená, že útočník může otrávit vaše vlastní interní repozitáře stejně, jako se otrávily ty Microsoftí, a vaši ostatní inženýři si tu otravu stáhnou přes svůj důvěryhodný toolchain při příštím syncu. MCP server, který byl tak praktický, protože měl trvalý přístup do vaší staging databáze, je pivot bod přímo do vašich dat. Agent, který spouští shell příkazy, si stihne nainstalovat persistenci, než si toho někdo všimne, a protože vývojářské stroje jsou ze své podstaty hlučné, plné běžících procesů na pozadí, neustálého síťového šumu, běžících buildů, naskakujících kontejnerů, je poměr signálu k šumu pro odhalení mizerný.

Exfiltrace credentials je okamžitá ztráta. Laterální pohyb přes vaši vlastní důvěryhodnou infrastrukturu je ta část, která z jednoho špatného klonu udělá celofiremní incident. A supply-chain rovina, kde se váš toolchain stane vektorem pro další tým po proudu, je způsob, jak jediná kompromitace přestane být vaším problémem a stane se i problémem vašich zákazníků.

Nezakázali jsme ty nástroje, protože to je nereálné a hloupé. Nárůst produktivity z agentního kódování je reálný a předstírat opak jen donutí lidi používat ty nástroje mimo záznam, kde máte ještě menší vhled. Co jsme udělali, bylo, že jsme s toolchainem začali zacházet jako s privilegovaným softwarem, kterým je.

Zaprvé, credentials na vývojářských strojích jsme tvrdě zúžili a dali jim krátkou životnost. Žádné dlouho žijící AWS klíče sedící v dotfile. Všechno jde přes krátkodobé SSO s credentials, které vyprší za hodinu, takže snapshot stroje v momentě exfiltrace má mnohem menší cenu, než míval. Přístup k databázi pro lokální agenty jde přes proxy, kterou umíme auditovat a odvolat, nikdy ne přímý connection string předaný MCP serveru.

Zadruhé, samotné agentní nástroje jsme připnuli na verze a prošli review. MCP servery, které provozujeme, jsou známá, prověřená sada, nainstalovaná z pevně daných verzí, ne z toho, co doporučil poslední blogpost. LiteLLM a podobný framework kód, který sahá na credentials, dostává stejné dependency review, jaké bychom dali produkční knihovně, protože přesně to je. Přestali jsme lidem dovolovat tahat náhodné ukázkové repozitáře na primární pracovní stroj a clone-and-run neznámého kódu přes agenta, který má přístup k souborovému systému. Zní to omezujícím, dokud si nevzpomenete, že přesně takhle devátý červen fungoval.

Zatřetí, a to je ta nudná věc, na které záleželo nejvíc, jsme udělali telemetrii z vývojářských strojů skutečně čitelnou. Pokud je všechno, co agent dělá, neviditelný šum, nic nechytíte. Provoz agentů jsme protlačili přes známé egress cesty, aby cokoliv mimo ně vyčnívalo, a logujeme MCP tool cally, takže existuje záznam, co LLM se svým přístupem reálně udělal. Nic z toho není exotické. Je to stejná strategie, jakou byste aplikovali na jakoukoliv privilegovanou službu, jen aplikovaná na privilegované služby, které náhodou žijí na laptopech.

Nepříjemná pravda je, že útočný povrch roste pokaždé, když někdo ve vašem týmu najde nového agenta nebo MCP integraci, která mu denně ušetří dvacet minut. A budou je nacházet dál, protože ekosystém se hýbe rychleji než jakýkoliv security review proces, který postavíte. Tohle nezagatujete tak, jako gatujete produkční deploy. Poločas rozpadu „prověřili jsme seznam schválených nástrojů" jsou asi tři týdny.

Takže trvalý tah je spíš architektonický než procesní. Předpokládejte, že vývojářský stroj je nepřátelský, nebo v nějakém momentě bude, a navrhněte to tak, aby vás kompromitovaný laptop stál rotaci credentials a jedno odpoledne, ne oznámení o průniku. To znamená, že trvalý přístup je nepřítel, krátká životnost všeho je default a cesta mezi vývojářovým lokálním agentem a vašimi produkčními daty má uprostřed auditovatelný, odvolatelný choke point, který ovládáte. Pokud útočník, který plně vlastní dev stroj, pořád nedosáhne na produkční data ani nepushne otrávený kód do vašich repozitářů, aniž by něco spustil, vyhráli jste tu část boje, která se vyhrát dá.

Pokud jste napříč týmem nasadili agentní nástroje na kódování a ještě jste si nesedli vytrasovat, co vás reálně stojí „kompromitovaný toolchain", tohle cvičení si udělejte ještě tento týden, než bude příští devátý červen mít v titulku jméno vaší firmy. Tenhle typ threat modelingu a auditu toolchainu děláme pro týmy, které se v AI nástrojích rozjely rychle a chtějí vědět, kde mají díry. Audity skoro vždycky najdou ten stejný problém s trvalými credentials a neprověřenými MCP, protože všichni si tyhle nástroje nasadili stejně, rychle a bez otázky, co se může pokazit.