llms.txt útok: zastav agenta, než nainstaluje balíček, který nikdo nevlastní

Když si příště necháš od agenta "rozejít projekt podle dokumentace", může se stát něco, co tě nenapadne: agent si z dokumentace přečte instalační příkaz, zjistí, že balíček neexistuje v registru — a nainstaluje si ho od kohokoli, kdo si ho mezitím zaregistroval. Není to teorie. Výzkumníci izraelského startupu to právě otestovali na reálných firemních webech a během hodiny se jim ozval beacon z Fortune 500 společnosti.

O co jde, proč to tvůj endpoint protection nevidí a jak to dnes zastavíš za půl hodiny — to si rozbereme v tomto článku.

Co se vlastně stalo

Společnosti začaly publikovat soubory llms.txt a llms-full.txt. Je to nová konvence: strojově čitelný souhrn obsahu webu, Něco jako robots.txt, akorát pro AI agenty. Vendor dokumentace, API přehledy, instalační instrukce — všechno hezky na jednom místě, formátované pro jazykové modely.

Výzkumníci proskenovali 6 214 domén patřících dodavatelům obranného průmyslu, Fortune 500 firmám a velkým technologickým společnostem. Našli 8 265 souborů llms.txt a llms-full.txt. A v 120 z nich, vždy na jiném webu, našli odkazy na balíčky nebo domény, které nikdo nemá zaregistrované. Celkem 227 instalačních příkazů mířících do prázdna.

Prázdné místo v registru je ale bezpečnostní díra. Když si název balíčku zaregistruješ ty (nebo útočník), všechno, co tento příkaz spustí, si stáhne tvůj kód. Výzkumníci to otestovali: zaregistrovali pár neobsazených názvů, hostovali balíčky, které se ozvaly domů, a do hodiny dostali phone-home signál od Fortune 500 firmy. Postupně přibyly desítky dalších. Řetězec rodičovských procesů prozradil, že instalace spouštěli coding agenti — Claude, OpenAI Codex i Hermes od Nous Research.

Proč agent dokumentaci věří víc než ty

Tady je jádro problému. Agent, který čte llms.txt, vidí soubor servírovaný přes HTTPS, na oficiální doméně firmy, ve standardizovaném formátu určeném pro AI. Každý signál, na který se systém spoléhá, ukazuje správným směrem. Takže když soubor říká pip install internal-tool, agent se nezastaví, aby ověřil, jestli balíček skutečně patří dané firmě. Nezkontroluje namespace na PyPI. Nesleduje, že odkazovaná doména vypršela před třemi měsíci. Prostě to udělá.

Jak to výzkumníci formulují: agent nerozlišuje mezi stránkou a příkazem. Všechno, co přečte, je vstup — a každý vstup je potenciální instrukce. Důvěra je navíc tranzitivní: llms.txt nemusí ležet přímo na webu Fortune 500. Agent si kontext tahá z dokumentace partnerů, vendor SDK, komunitních návodů. Stačí, aby jeden článek v tomhle řetězci důvěry mířil na neobsazený balíček.

A jak se tyhle chybné záznamy do souborů vůbec dostaly? Část z nich předchází éře AI — jsou to lidské překlepy z klasických dokumentací. Další část zřejmě vygenerovala samotná AI, která si název balíčku vymyslela, úplně stejně jako agent, který ten soubor čte. Halucinace na vstupu, halucinace na výstupu.

Případ Clerk: jedna řádka a živý malware

Nejvíc konkrétní případ se týkal clerk.com. Jejich llms.txt obsahoval příkaz npx clerk-next-fix-auth-protection. Příkaz npx je zrádný tím, že si balíček stáhne do cache a rovnou spustí jeho binárku — aniž by ho přidal do závislostí projektu. Výzkumníci zjistili, že někdo si ten prázdný slot už nárokoval a hostoval na něm živý malware. Clerk problém následně vyřešil; pokud agent měl už dřív nainstalovaný legitimní balíček @clerk/eslint-plugin, hrozba se ho netýkala.

Proč tohle zpozornit, i když Clerk už je historie? Protože 227 příkazů z výzkumu je jen zlomek toho, co je venku. Scan pokryl 6 214 domén — internet jich má miliardy.

Proč to tvoje bezpečnostní nástroje nevidí

Tady je druhá nepříjemná část. Pro EDR, proxy ani SIEM to nevypadá jako útok. Vypadá to jako vývojář, který spouští legitimní package manager: pip install z pypi.org — domény, kterou každý firemní proxy povoluje — s coding agentem jako rodičovským procesem, který společnost sama nasadila. Žádný podpis, žádný exploit, žádná anomálie v binárce. Prostě instalace balíčku.

Je to stejný důvod, proč funguje prompt injection: model neumí spolehlivě oddělit instrukce, které napsal uživatel, od instrukcí, které našel v textu na webu. Útočníkovi stačí publikovat obsah, který si agent sám přečte.

Pět vrstev obrany, které postavíš dnes

1. Zámek na instalaci balíčků

Nejdřív to nejdůležitější: agent nesmí spouštět pip install a npm install s libovolným názvem. V Claude Code nastav permissions tak, aby instalační příkazy vyžadovaly potvrzení, nebo je rovnou zakaž a povol jen konkrétní patterny. V Codexu použij approval mode pro shell příkazy. Obecně platí: čím méně je agent schopen sám dotahovat nové závislosti, tím menší plocha útoku. Instalace nové knihovny je rozhodnutí, ne implementační detail.

2. Interní registry jako jediná cesta

Nastav agentovi a celému týmu interní mirror — Verdaccio pro npm, devpi pro Python, případně Artifactory nebo GitHub Packages. V pip.conf a .npmrc nastav index-url na interní registr a odeber fallback na veřejný registru. Balíček, který v interním mirroru není, se nenainstaluje vůbec — a to je přesně ten stav, který chceš. Nové balíčky přidáváš přes review proces, ne přes agenta v pátek odpoledne.

3. Lock soubory a hashe

Závislosti lockuj a podepisuj. package-lock.json a uv.lock s hexou každého artefaktu znamenají, že i když útočník nahraje obsah známého názvu, hash nesedí a instalace spadne. U kritických projektů zapni pip install --require-hashes. Agent pak pracuje se zamčeným stavem a jeho pip install -r requirements.txt nemá prostor pro improvizi.

4. Audit vlastního llms.txt

Pokud publikuješ llms.txt (a v roce 2026 bys měl, pokud máš dokumentaci nebo API), zkontroluj si ho. Vypiš všechny balíčky a domény, které v něm zmiňuješ, a ověř, že existují a patří tobě. Zvlášť pozor na příklady typu "takhle nainstaluješ náš SDK" — překlep v názvu balíčku dělá z tvého webu útočnou plochu. Ideálně si přidej do CI check, který každý zmíněný balíček ověří v registru a každou doménu přes DNS. Trvá to dvacet řádků skriptu.

5. Monitoring, který beacon odhalí

Protože endpoint detekce nenabídne, nastav aspoň detekci na úrovni sítě: nově registrované domény, neobvyklé DNS dotazy z CI a vývojových strojů, opakované odchozí spojení po instalaci balíčku. Signál "po pip install se objevil odchozí provoz na neznámou doménu" je přesně ten, který tahle kampaň produkuje.

Kontrola za 30 minut

Kdybys měl dnes jen půl hodiny, udělej v tomhle pořadí:

1. Zkontroluj, jestli tvůj agent smí spouštět pip install / npm install bez potvrzení. Pokud ano, nastav approval.
2. Zkontroluj, jestli má projekt lock soubor a jestli se v CI instaluje přes --frozen / --locked variantu.
3. Pokud publikuješ llms.txt, projdi zmíněné balíčky a domény — případně je vyhoď.
4. Sdílej tenhle článek kolegovi, který má agenta napojeného na produkční prostředí.

Závěr

Útok přes llms.txt není o slabině jednoho modelu. Je o tom, že jsme agentům dali právě tolik důvěry, že berou cizí dokumentaci jako ground truth — a spolu s ní i instalační příkazy, které nikdo neověřil. Obrana přitom není o drahých nástrojích, ale o disciplíně: zamčené registry, lock soubory, ověřené instrukce a agent, který se na instalaci nových závislostí musí zeptat.

Vyplatí se to dvojnásob — stejný mechanismus tě chrání i před klasickým dependency confusion a typosquattingem, které tu byly dlouho před AI. Agenti jen způsobili, že se ta díra otevírá rychleji.