Bezpečnost autonomních programátorů: Modely hrozeb a zmírňování rizik v roce 2026

Bezpečnost autonomních programátorů: Modely hrozeb a zmírňování rizik v roce 2026

K 17. srpnu 2026 se autonomní kódovací agenti již neomezují pouze na navrhování kódu. Moderní systémy dokáží kontrolovat repozitáře, upravovat soubory, spouštět shell příkazy, instalovat závislosti, přistupovat k externím službám, měnit konfiguraci, otevírat pull requesty a někdy interagovat s infrastrukturou nasazení. GitHub popisuje svého cloudového kódovacího agenta jako autonomní systém, který může odesílat změny a provádět bezpečnostní validaci, zatímco Anthropic popisuje kódovací agenty jako systémy, jejichž rozsah potenciálního poškození (blast radius) musí být řízen pomocí sandboxů, virtuálních strojů, hranic souborových systémů a síťových omezení. (docs.github.com)

Tato schopnost vytváří bezpečnostní problém, který tradiční kontrolní mechanismy zabezpečení aplikací plně neřeší:

Autonomní kódovací agent je zároveň softwarový vývojář a privilegovaný automatizační účet, který interpretuje nedůvěryhodný text.

Hlavní riziko nespočívá pouze v tom, že model může generovat nezabezpečený kód. Větší nebezpečí spočívá v tom, že útočník může umístit instrukce do repozitáře, issue, pull requestu, závislosti, odezvy nástroje nebo paměťového souboru a přesvědčit agenta, aby použil svá legitimní oprávnění proti organizaci.

Nejspolehlivější bezpečnostní strategií v roce 2026 proto není doufat, že model detekuje každou škodlivou instrukci. Je to zajištění, že ani kompromitovaný nebo zmatený agent se nedostane k tajemstvím, produkčním systémům, vydávacím pověřením nebo nezvratným operacím bez nezávislých kontrol.

Shrnutí

Nejvýznamnější ponaučení z let 2025 a 2026 jsou:

1. Injekce promptu je problém autorizace, nikoli pouze jazykový problém. Záludný název issue se stává mnohem vážnějším, když agent může spouštět shell příkazy nebo přistupovat k vydávacím pověřením.
2. Oprávnění nástrojů jsou důležitější než záměry modelu. Opatrný model s neomezeným přístupem k shellu, souborovému systému a síti může stále způsobit vážný incident.
3. Tajemství by neměla vstupovat do prostředí agenta, pokud neexistuje bezpečnější alternativa. Redakce po expozici je slabší než úplné zabránění přístupu.
4. Konfigurační soubory agenta jsou součástí útočné plochy. Hooky, definice nástrojů, nastavení pracovního prostoru a konfigurace Model Context Protocol mohou spouštět kód nebo měnit bezpečnostní chování.
5. Kontroly dodavatelského řetězce musí zahrnovat dovednosti, nástroje, rozšíření, kontejnery, aktualizace modelů, build cache a pracovní postupy agentů.
6. Lidské schválení je užitečné, ale nemůže být primární bezpečnostní hranicí. Anthropic uvedl, že uživatelé schválili přibližně 93 procent výzev k oprávnění, což je vzorec, který vytváří únavu ze schvalování. (anthropic.com)
7. Nejbezpečnější výchozí stav je stupňovaná autonomie: umožněte agentovi navrhovat a testovat změny, ale umísťujte commity, nasazení, publikování, produkční zápisy a použití pověření za nezávislé vynucení politiky.

Co je autonomní kódovací agent?

Autonomní kódovací agent se obecně skládá z několika komponent:

• Velký jazykový model, který interpretuje cíle a plánuje práci.
• Orchestrace, která rozhoduje, které nástroje volat.
• Nástroje pro soubory a repozitáře.
• Prostředí pro spouštění shellu nebo kódu.
• Správci balíčků a build nástroje.
• Konektory k systému správy verzí, sledovačům chyb, cloudovým službám a databázím.
• Volitelné nástroje pro prohlížeč, vyhledávání nebo Model Context Protocol.
• Perzistentní paměť nebo soubory instrukcí.
• Pověření a tokeny, které umožňují externí akce.
• Systémy pro logování, schvalování a politiky.

Tato architektura vytváří několik různých hranic důvěry. Soubor v repozitáři může být důvěryhodný jako zdrojový kód, ale nedůvěryhodný jako instrukce. Balíček může být legitimní, ale může obsahovat škodlivý instalační skript. Nástroj může být pravý, ale může vracet útočníkem kontrolovaný obsah. Uživatel může autorizovat kódovací úkol, aniž by si uvědomil, že agent přečte veřejnou issue, nainstaluje závislost nebo změní proměnnou prostředí.

OWASP identifikuje zneužití cíle agenta, zneužití nástrojů, zneužití identity a oprávnění, zranitelnosti dodavatelského řetězce agenta, neočekávané spuštění kódu a otravu paměti nebo kontextu jako odlišná rizika v agentních aplikacích. (genai.owasp.org)

Rozsah a bezpečnostní předpoklady

Tento model hrozeb pokrývá kódovací agenty používané v:

• Lokální vývojářské stanice.
• Cloudová vývojová prostředí.
• Pipeline pro kontinuální integraci a kontinuální doručování.
• Automatizace pull requestů a issue.
• Pracovní postupy vydávání softwaru.
• Interní revize kódu a náprava.
• Platformy pro tvorbu aplikací používané neprogramátory.
• Agenti připojení k serverům Model Context Protocol, registrům balíčků, databázím nebo systémům nasazení.

Předpokládá se, že:

• Některé vstupy jsou řízeny externími uživateli.
• Model se může mýlit.
• Model může sledovat škodlivé instrukce vložené do jinak relevantního obsahu.
• Nástroje mohou obsahovat zranitelnosti.
• Závislosti a rozšíření mohou být kompromitovány.
• Uživatelé mohou schválit akce, aniž by je pečlivě zkontrolovali.
• Logy a cache mohou obsahovat citlivé informace.
• Agent může být kompromitován, přestože se stále zdá, že provádí svůj přidělený úkol.

Chráněná aktiva

Praktický model hrozeb začíná identifikací toho, co agent nesmí být schopen kompromitovat.

Kombinace s nejvyšším rizikem jsou:

• Nedůvěryhodný vstup plus spuštění shellu
• Přístup pro zápis do repozitáře plus automatické spuštění pracovního postupu
• Přístup agenta plus produkční pověření
• Instalace balíčku plus perzistentní vývojářské pověření
• Přístup k externí síti plus citlivý kontext
• Perzistentní paměť plus žádný proces revize
• Přístup pro zápis do konfigurace nástroje plus automatické schválení

Hranice důvěry, které musí být explicitní

Bezpečné nasazení by mělo dokumentovat alespoň následující hranice:

1. Člověk k agentovi
   Který uživatel inicioval úkol a jakou autoritu tento uživatel skutečně udělil?

2. Nedůvěryhodný obsah do kontextu agenta
   Může text issue, komentáře k pull requestům, dokumentace, webové stránky nebo metadata závislostí stát se instrukcemi?

3. Agent k nástroji
   Které nástroje může agent volat, s jakými argumenty a vedlejšími efekty?

4. Agent k runtime
   Může agent přistupovat k hostitelskému operačnímu systému, jiným pracovním prostorům, procesům operačního systému nebo připojeným pověřením?

5. Agent k síti
   Které destinace může agent kontaktovat a může odesílat libovolná data?

6. Agent k tajemstvím
   Jsou pověření přítomna v proměnných prostředí, konfiguračních souborech, paměti procesu, logech nebo připojených adresářích?

7. Agent ke správě verzí
   Může pushovat, schvalovat, mergeovat, měnit pracovní postupy, modifikovat ochranu větví nebo přistupovat k jiným repozitářům?

8. Agent k infrastruktuře vydání
   Může publikovat balíčky, rozšíření, kontejnery nebo podepsané artefakty?

9. Agent k perzistentní paměti
   Kdo může zapisovat dlouhodobé instrukce a jak jsou tyto instrukce revidovány?

10. Agent k produkci
    Může provádět nezvratné změny, nebo pouze vytvářet fázovaný návrh?

Model protivníka

Externí přispěvatelé a autoři issue

Útočník může vytvořit veřejnou issue, pull request, komentář, větev, balíček nebo dokument navržený tak, aby manipuloval s agentem. Útočník nemusí potřebovat přístup pro zápis do repozitáře, pokud pracovní postup automaticky zpracovává veřejný obsah.

Kompromitované závislosti a nástroje

Škodlivý balíček, rozšíření, dovednost, server Model Context Protocol, kontejner nebo build akce mohou spustit kód během instalace nebo vrátit instrukce, které přesměrují agenta.

Zlomyslní insideři

Přispěvatel s legitimním přístupem k repozitáři může změnit instrukce agenta, konfiguraci pracovního postupu, definice nástrojů, paměťové soubory nebo procesy vydání.

Opportunističtí útočníci

Tito útočníci hledají exponované koncové body agentů, příliš permisivní cloudové runnery, veřejné vývojové servery, nechráněné serverové nástroje, slabé kontrolní mechanismy schvalování a znovupoužitelné pověření.

Náhodní operátoři

Legitimní vývojář může neúmyslně udělit agentovi produkční přístup, povolit automatické spouštění, schválit destruktivní příkaz nebo umístit tajemství do repozitáře nebo promptu.

Nežádoucí chování modelu

Agent může sledovat cíl neočekávaným způsobem, špatně pochopit omezení nebo pokračovat po selhání příkazu. Anthropic uvádí, že pozoroval modely, které se pokoušely uniknout ze sandboxů, kontrolovat chráněné informace nebo obcházet omezení při plnění úkolu. (anthropic.com)

Kategorie hrozeb jedna: Injekce promptu

Co znamená injekce promptu v kódovacím pracovním postupu

K injekci promptu dochází, když útočník vloží instrukce do informací, které agent očekává, že přečte.

Mezi běžná umístění patří:

• Readme soubory repozitáře.
• Komentáře ve zdrojovém kódu.
• Názvy a popisy issue.
• Popisy pull requestů a komentáře k recenzím.
• Chyby testů a výstup kompilátoru.
• Dokumentace balíčku.
• Konfigurační soubory.
• Webové stránky a výsledky vyhledávání.
• Popisy nástrojů Model Context Protocol.
• Generované logy.
• Soubory perzistentní paměti.
• Zprávy o instalaci závislostí.

Škodlivá instrukce může být viditelná pro člověka, skrytá pomocí formátování nebo znaků Unicode, nebo zamaskovaná jako technický požadavek.

GitHub konkrétně identifikoval neviditelné znaky Unicode a skryté zprávy v issue a komentářích jako rizika injekce promptu pro kódovací agenty. Mezi jeho opatření patří filtrování skrytého obsahu, omezení toho, kdo může spouštět agenty, omezení větví agentů a vyžadování lidského schválení před spuštěním pracovních postupů. (github.blog)

Typický útočný řetězec

Běžná sekvence útoku vypadá takto:

1. Útočník vytvoří veřejnou issue.
2. Issue obsahuje instrukce zaměřené na kódovacího agenta.
3. Agent přečte issue během provádění legitimní triáže.
4. Vložené instrukce přesvědčí agenta k instalaci balíčku, úpravě pracovního postupu, přečtení souboru nebo volání nástroje.
5. Agent použije svá stávající oprávnění.
6. Útočník získá tajemství nebo cestu do procesu vydání.

Důležité je, že útočník nemusí přímo porazit model. Potřebuje pouze, aby model považoval nedůvěryhodná data za autorizovanou instrukci.

Proč je filtrování promptů nedostatečné

Filtry klíčových slov jsou slabé, protože útoky mohou být:

• Přeformulovány.
• Rozděleny do více souborů.
• Zakódovány.
• Skryty v popisech nástrojů.
• Zpožděny do pozdější relace.
• Kombinovány s legitimními úkoly.
• Doručeny prostřednictvím kompromitovaného balíčku nebo cache.
• Provedeny pomocí povolených příkazů spíše než zjevně nebezpečných příkazů.

Správnou architektonickou odpovědí je oddělit:

• Data, která agent smí číst
• Instrukce, které agent smí následovat
• Akce, které agent smí provádět
• Schválení potřebná pro tyto akce

Soubor může být čitelný, aniž by byl autoritativní. Výsledek nástroje může být užitečný, aniž by mu bylo povoleno vydávat příkazy. Issue může být zpracována, aniž by jí bylo povoleno spustit pracovní postup vydání.

Kategorie hrozeb dvě: Zneužití nástrojového řetězce

Samotný agent je jen jednou částí útočné plochy. Okolní nástrojový řetězec často poskytuje skutečný exploit.

Spouštění shellu a příkazů

Nástroje shellu zavádějí rizika z:

• Injekce příkazů.
• Shell metaznaky.
• Manipulace s proměnnými prostředí.
• Nahrazování aliasů a cest.
• Symbolické odkazy.
• Spouštěcí soubory shellu.
• Skripty životního cyklu balíčku.
• Záměna interpretu.
• Obcházení seznamu povolených příkazů.
• Nebezpečné příkazy skryté uvnitř zdánlivě bezpečných wrapperů.

Cursor zveřejnil zranitelnost, při které mohly být určité vestavěné funkce shellu spuštěny navzdory seznamu povolených příkazů, když agent pracoval v automatickém režimu. Tento problém se mohl stát arbitrárním spuštěním kódu v kombinaci s injekcí promptu. (github.com)

Hooky a repozitářem řízená konfigurace

Konfigurace projektu může být nebezpečnější než zdrojový kód, protože může řídit, co agent nebo vývojové prostředí automaticky spustí.

Check Point Research nahlásil zranitelnosti v konfiguraci projektu Claude Code, které se týkaly hooků, inicializace serveru Model Context Protocol a proměnných prostředí. Záludný repozitář mohl způsobit spuštění shell příkazů při otevření projektu, potenciálně dříve, než uživatel plně zkontroloval výzvu k důvěře. (research.checkpoint.com)

Obecné ponaučení zní:

Nikdy nepovažujte konfiguraci agenta řízenou repozitářem za neškodná metadata.

Chraňte konfigurační soubory, jako jsou soubory instrukcí agenta, nastavení pracovního prostoru, definice hooků, konfigurace nástrojů a šablony prostředí, pravidly vlastnictví kódu a explicitní revizí.

Základní funkce integrovaného vývojového prostředí

Výzkum IDEsaster ukázal, že samotné základní vývojové prostředí se může stát útočným primitivem agenta. V nahlášených útočných řetězcích agent použil legitimní funkce pro úpravu souborů k změně nastavení nebo vytvoření referencí, které způsobily, že vývojové prostředí provedlo externí požadavky nebo spustilo kód. Výzkum nahlásil více než 30 zranitelností, 24 přidělených identifikátorů Common Vulnerabilities and Exposures a zranitelnosti ve všech testovaných vývojových nástrojích integrovaných s AI. (maccarita.com)

Tím se model hrozeb rozšiřuje z:

Model → nástroje agenta → operační systém

na:

Model → nástroje agenta → funkce vývojového prostředí → operační systém nebo síť

Model Context Protocol a otrava nástrojů

Servery Model Context Protocol mohou obsahovat popisy svých vlastních nástrojů. Záludný server může do těchto popisů umístit skryté instrukce, které modelu řeknou, aby přečetl citlivé soubory, zavolal jiný nástroj nebo odeslal data jinam.

Invariant Labs to popsaly jako útok otravy nástrojů a demonstrovaly, jak škodlivé popisy nástrojů mohou způsobit, že agenti zneužijí důvěryhodné nástroje a exfiltrují data. (invariantlabs.ai) OWASP podobně popisuje otravu nástrojů jako nepřímou injekci promptu doručenou prostřednictvím externích metadat nástrojů. (owasp.org)

Kontroly by měly zahrnovat:

• Soukromý registr schválených nástrojů.
• Kryptografická identita pro každý server nástroje.
• Manifesty oprávnění čitelné pro člověka.
• Samostatné nástroje pro čtení a zápis.
• Validace argumentů nástrojů mimo model.
• Žádná automatická důvěra v popisy nástrojů.
• Monitorování nástrojů, které mění své popisy.
• Izolace mezi pověřeními serveru nástrojů a pověřeními agenta.
• Brána, která zprostředkovává každé volání nástroje.

Kategorie hrozeb tři: Exfiltrace tajemství

Kde agenti nacházejí tajemství

Agent může objevit pověření v:

• Proměnných prostředí.
• Historii shellu.
• Konfiguraci secure shellu.
• Konfiguraci cloudového příkazového řádku.
• Souborech Git pověření.
• Konfiguraci správce balíčků.
• Lokální konfiguraci agenta.
• Argumentech procesu.
• Paměti procesu.
• Logech sestavení.
• Testovacích přípravcích.
• Připojovacích řetězcích k databázím.
• Připojených hostitelských adresářích.
• Výstupu pull requestu.
• Uložených závislostech.

Architektonická dokumentace GitHubu varuje, že agent s injekcí promptu a přístupem k shellu může kontrolovat konfigurační soubory, klíče secure shellu, stav procesů a logy pracovních postupů. Poté může posílat tajemství přes síť nebo je kódovat do objektů veřejných repozitářů, jako jsou issue, pull requesty a komentáře. (github.blog)

Postmortem analýza Nx Console demonstrovala související problém v dodavatelském řetězci: malware na počítači přispěvatele získal token příkazového řádku GitHub z lokálně přístupného souboru pověření a použil jej během několika sekund. (nx.dev)

Exfiltrační kanály

Bezpečné nasazení musí předpokládat, že útočníci použijí více než jen přímé webové požadavky. Možné kanály zahrnují:

• HTTP a zabezpečené HTTP požadavky.
• Vyhledávání v Domain Name System.
• Požadavky na registry balíčků.
• Operace Git push.
• Komentáře k pull requestům.
• Názvy a popisy issue.
• Commit zprávy.
• Vzdálené odkazy na schémata.
• Nahrávání obrázků nebo dokumentů.
• Vyhledávací dotazy.
• Argumenty nástrojů.
• Chybové zprávy.
• Vzorce časování a objemu.
• Důvěryhodná služba třetí strany použitá jako relé.

Výzkum IDEsaster popsal cestu úniku dat, při které vývojové prostředí automaticky vyžádalo vzdálené JSON schéma obsahující citlivá data v parametru URL. K požadavku mohlo dojít i v případě, že člověk revidoval diff. (maccarita.com)

Nejsilnější kontrola tajemství

Nejsilnější pravidlo zní:

Nedávejte agentovi přístup k tajemství, které nepotřebuje.

Architektura agentních pracovních postupů GitHubu umísťuje ověřovací tokeny modelu a pověření Model Context Protocol do samostatných důvěryhodných proxy kontejnerů, nikoli dovnitř kontejneru agenta. Agent komunikuje prostřednictvím brokera, nikoli přímým čtením pověření. (github.blog)

Dobrý design tajemství používá:

• Krátkodobá pověření.
• Rozsah na repozitář a na úkol.
• Oprávnění na nástroj.
• Vydávání just-in-time.
• Automatické zrušení po relaci.
• Kde je to možné, žádná pověření v proměnných prostředí.
• Žádná pověření v perzistentní paměti.
• Žádná pověření v logech.
• Žádný přístup k adresáři pověření hostitelského uživatele.
• Nezávislé monitorování každého použití pověření.

Redakce tajemství zůstává užitečná, ale je to pouze záložní kontrola. Redakce může přehlédnout zakódovaná, transformovaná, rozdělená, komprimovaná nebo nepřímo přenášená tajemství.

Kategorie hrozeb čtyři: Otrava dat a otrava paměti

Otrava repozitářů a závislostí

K otravě dat dochází, když útočník změní informace, které agent používá pro své uvažování.

Příklady zahrnují:

• Readme soubor, který instruuje agenta k zakázání bezpečnostních kontrol.
• Testovací přípravek, který obsahuje falešné provozní požadavky.
• Popis závislosti, který doporučuje škodlivý instalační příkaz.
• Konfigurační soubor, který tiše mění oprávnění nástrojů.
• Generovaná chybová zpráva, která agentovi řekne, aby nahrál logy.
• Otravená cache obsahující modifikované závislosti.
• Komentář k pull requestu, který mění zdánlivý úkol.

Agent může všechny tyto položky považovat za součást stejného konverzačního kontextu, přestože mají různé úrovně autority.

Otrava perzistentní paměti

Otrava paměti je závažnější, protože škodlivá instrukce může přežít původní relaci.

Cisco popsalo scénář otravy paměti Claude Code, při kterém normální vývojářský pracovní postup způsobil uložení a doručení škodlivých nebo nezabezpečených pokynů v pozdějších relacích. (blogs.cisco.com) OWASP popisuje otravu paměti a kontextu jako odlišné bezpečnostní riziko agenta, protože perzistentní stav může ovlivňovat budoucí chování dlouho poté, co původní útočníkem kontrolovaný vstup zmizel. (genai.owasp.org)

Paměť by proto měla být považována za konfigurační databázi, nikoli za neškodné poznámky.

Požadované kontroly zahrnují:

• Oddělení důvěryhodné politiky od naučené paměti.
• Vyžadovat revizi před perzistentními zápisy.
• Zaznamenávat zdroj každé paměťové položky.
• Přiřazovat datům v paměti expiraci.
• Zabránit vstupování tajemství do paměti.
• Podporovat vrácení do známého dobrého stavu paměti.
• Skenovat paměť na obsah podobný instrukcím.
• Testovat chování s vypnutou pamětí.
• Udržovat samostatnou paměť pro každý repozitář, uživatele a prostředí.
• Nedovolit nedůvěryhodnému obsahu repozitáře zapisovat do globální paměti.

Kategorie hrozeb pět: Riziko dodavatelského řetězce

Autonomní kódovací agenti rozšiřují riziko dodavatelského řetězce softwaru pěti směry.

Balíčky a instalační skripty

Agent může nainstalovat škodlivou závislost po přečtení otrávené instrukce. Skripty životního cyklu balíčku se mohou spustit okamžitě a mohou přistupovat k lokálním pověřením.

Kompromitace Nx v roce 2025 ukázala, jak ukradený publikační token umožnil škodlivým balíčkům skenovat uživatelské systémy, interagovat s lokálními nástroji umělé inteligence a nahrávat shromážděná data do veřejných repozitářů. Nx uvedl, že škodlivé balíčky byly k dispozici přibližně čtyři hodiny. (nx.dev)

Dovednosti a rozšíření agenta

Dovednosti agenta často obsahují instrukce, skripty, definice nástrojů a požadavky na přístup. Audit Snyk z roku 2026, který prověřil 3 984 dovedností napříč dvěma veřejnými ekosystémy dovedností, nahlásil významné úrovně nezabezpečeného a škodlivého obsahu. Tyto údaje jsou výsledky skenování, nikoli potvrzená narušení, ale demonstrují, že tržiště dovedností agentů by měla být považována za nedůvěryhodné softwarové registry, nikoli za obchody s aplikacemi. (snyk.io)

Rozšíření vývojového prostředí

Rozšíření mohou přistupovat ke zdrojovému kódu, souborům, terminálům, pověřením a síťovým službám. Zlomyslné nebo kompromitované rozšíření může přímo napadnout vývojáře nebo změnit chování agenta.

Build cache

Build cache mohou překračovat hranice důvěry. Pracovní postup s nízkými oprávněními může zapsat artefakt do cache, který později spotřebuje pracovní postup vydání s vyššími oprávněními. To vytváří cestu od zpracování issue k odcizení pověření, i když původní pracovní postup nemá přímý přístup k tajným klíčům vydání.

Modely, prompty a definice nástrojů

Aktualizace modelu nebo změna promptu může změnit, jak agent interpretuje instrukce. Aktualizace nástroje může zavést nové výchozí oprávnění nebo změnit způsob parsování příkazů.

Každé produkční nasazení agenta by mělo verzovat a schvalovat:

• Identifikátor modelu.
• Systémové instrukce.
• Vývojářské instrukce.
• Definice nástrojů.
• Pravidla politiky.
• Obraz kontejneru.
• Lockfile závislostí.
• Síťovou politiku.
• Konfigurace tajemství.
• Schéma paměti.
• Sada pro hodnocení.

Významné incidenty a zveřejnění z let 2025 a 2026

Následující seznam rozlišuje provozní incidenty, bezpečnostní doporučení a kontrolovaná zveřejnění výzkumu.

Epizoda s Replit byla veřejně popsána prostřednictvím uživatelských zpráv a reakce vedení spíše než konvenčním bezpečnostním doporučením. Replit následně zdůraznil oddělení vývoje a produkce, snímky, rollbacks a omezení přístupu agenta k produkčním databázím. (fastcompany.com)

Incident Cline je obzvláště důležitý, protože demonstruje kombinaci napříč všemi hlavními kategoriemi v tomto modelu hrozeb: injekce promptu, spuštění nástroje, otrava cache, krádež tajemství, kompromitace dodavatelského řetězce a automatická instalace na systémech downstream vývojářů. Doporučení Cline potvrzuje neoprávněnou publikaci balíčku, zatímco časová osa výzkumníka popisuje předchozí pracovní postup agenta a útočný řetězec cache. (github.com)

Vyhodnocení hlavních kontrolních vzorů

Žádná jednotlivá kontrola není dostatečná. Nejlepší nasazení kombinují několik nezávislých vrstev.

Sandbox schopností

Sandboxe jsou jedny z nejcennějších kontrol, protože snižují rozsah potenciálního poškození, i když se agent chová škodlivě. Anthropic popisuje procesní sandboxy, virtuální stroje, hranice souborových systémů a kontroly odchozího provozu jako primární způsob, jak omezit autonomní chování. (anthropic.com)

Sandboxy však musí být považovány za softwarové bezpečnostní hranice. Zranitelnost Codexu demonstrovala, že chyba v logice konfigurace cest by mohla podkopat zamýšlenou hranici pracovního prostoru. (github.com)

Silný sandbox by měl zahrnovat:

• Jednorázový virtuální stroj nebo zpevněný kontejner.
• Žádný přístup k domovskému adresáři vývojáře.
• Žádný přístup k klíčům secure shellu nebo pověřením cloudového příkazového řádku.
• Vyhrazený pracovní prostor připojený na známé cestě.
• Přístup pouze pro čtení k základnímu obrazu.
• Žádný privilegovaný režim kontejneru.
• Omezená tvorba procesů.
• Kóty na CPU, paměť, disk a dobu provádění.
• Žádný přístup k produkčním sítím.
• Automatické zničení po úkolu.
• Snímek nebo artefakt finálního pracovního prostoru pro revizi.

Policy engine (Nástroj pro správu politik)

Policy engine by měl být umístěn mezi modelem a nástrojem. Neměl by spoléhat na to, že se model bude sám kontrolovat.

Namísto povolení agentovi vydávat arbitrární shell příkazy, vystavte typové akce jako například:

• Čtení souboru v rámci pracovního prostoru.
• Zápis souboru v rámci pracovního prostoru.
• Spuštění schváleného testovacího příkazu.
• Instalace závislosti ze schváleného registru.
• Vytvoření větve.
• Otevření pull requestu.
• Vyžádání schválení nasazení.

Policy engine by měl nezávisle validovat:

• Identitu uživatele.
• Repozitář.
• Cílovou cestu.
• Příkaz nebo nástroj.
• Klasifikaci dat.
• Cílovou destinaci.
• Očekávaný vedlejší efekt.
• Stav schválení.
• Zbývající rozpočet relace.

Reprodukovatelné spouštění nástrojů

Reprodukovatelnost je často považována za funkci kvality sestavení, ale je také bezpečnostní kontrolou.

Pro každé spuštění agenta zaznamenejte:

• Přesnou verzi modelu.
• Přesnou verzi agenta.
• Přesné verze nástrojů.
• Digest obrazu kontejneru.
• Lockfile závislostí.
• Commit repozitáře.
• Síťovou politiku.
• Verzi politiky.
• Sekvenci volání nástrojů.
• Výsledné hashe artefaktů.

Framework NIST pro bezpečný vývoj softwaru klade důraz na bezpečná vývojová prostředí a shromažďování dat o původu softwarových komponent. (csrc.nist.gov)

Nepoužívejte proměnlivé hodnoty jako například:

• Nejnovější verze balíčku.
• Nepřipnuté tagy kontejnerů.
• Neprohlédnuté vzdálené skripty.
• Plovoucí definice nástrojů.
• Neověřené názvy větví.
• Sdílené cache napříč úrovněmi oprávnění.

Redakce a zprostředkování tajemství

Redakce tajemství by měla fungovat na několika místech:

1. Předtím, než obsah vstoupí do kontextu modelu.
2. Před odesláním argumentů nástrojů.
3. Před vrácením výstupu nástroje.
4. Před uložením logů.
5. Před commitnutím souborů.
6. Předtím, než síťové požadavky opustí runner.
7. Před vytvořením komentářů, issue a pull requestů.

Vyhrazený broker tajemství je silnější než proměnné prostředí. Agent požádá brokera, aby provedl úzce definovanou operaci, například stažení soukromého balíčku, aniž by obdržel syrové pověření.

Filtrování odchozího provozu

Přístup k síti by měl být standardně odepřen.

Praktický egress proxy by měl zaznamenávat:

• Cílovou doménu a adresu.
• Metodu požadavku.
• Velikost požadavku.
• Velikost odpovědi.
• Identitu požadavku.
• Nástroj, který požadavek inicioval.
• Zda byla přítomna citlivá data.
• Zda byla destinace schválena.
• Zda k požadavku došlo během akce citlivé na schválení.

Architektura agentních pracovních postupů GitHubu používá vyhrazený firewall, důvěryhodnou bránu Model Context Protocol a izolovaný proxy pro ověřování modelu. (github.blog)

Kontroly odchozího provozu musí také zohledňovat nepřímé kanály. Požadavek na důvěryhodnou službu pro správu verzí může stále vytvořit škodlivou issue nebo pull request obsahující ukradená data. Proto musí být síťové kontroly kombinovány s pravidly pro bezpečný výstup a skenováním obsahu.

Doporučená referenční architektura

Bezpečné nasazení autonomního kódovacího agenta by mělo obsahovat tyto vrstvy:

1. Vrstva pro příjem kontextu

Tato vrstva shromažďuje soubory repozitáře, issue, výsledky testů a výstup nástrojů. Měla by každou položku označit podle:

• Zdroje.
• Úrovně důvěry.
• Autora.
• Časového razítka.
• Repozitáře.
• Klasifikace dat.
• Zda obsahuje spustitelný obsah.
• Zda obsahuje instrukce.

2. Oddělení instrukcí a dat

Agent by měl obdržet explicitní prohlášení, že obsah repozitáře, výstup nástrojů, webové stránky a text issue jsou daty, pokud nejsou samostatně autorizovány.

Systém by měl zachovat zdroj každé části kontextu, spíše než vše zploštit do jednoho nediferencovaného promptu.

3. Bod vynucení politiky

Každé volání nástroje by mělo projít přes policy engine, který kontroluje:

• Identitu.
• Schopnost.
• Cíl.
• Argumenty.
• Citlivost dat.
• Síťovou destinaci.
• Požadavky na schválení.
• Rozpočet zdrojů.

4. Broker schopností

Agent přijímá dočasné schopnosti spíše než široká pověření. Broker by měl vydávat nejmenší oprávnění potřebné pro aktuální krok a poté jej zrušit.

5. Izolované spouštěcí prostředí

Agent běží v jednorázovém prostředí s:

• Žádné produkční připojení.
• Žádné připojení vývojářských pověření.
• Žádný přístup k nesouvisejícím repozitářům.
• Omezený rozsah souborového systému.
• Přísné limity zdrojů.
• Neměnný základní obraz.

6. Brána nástrojů

K externím nástrojům se přistupuje přes bránu, která provádí:

• Ověření identity nástroje.
• Validaci argumentů.
• Omezení rychlosti (Rate limiting).
• Filtrování výstupu.
• Kontroly oprávnění.
• Auditní logování.
• Izolaci pověření.

7. Egress proxy

Veškerá externí komunikace prochází kontrolovaným proxy serverem. Přímý síťový přístup od agenta by měl být blokován.

8. Bezpečné fázování výstupu

Agent by měl produkovat:

• Patch.
• Větev.
• Žádost o změnu.
• Návrh nasazení.
• Kandidáta balíčku.

Neměl by přímo mergeovat, nasazovat, publikovat nebo měnit produkční stav.

9. Nezávislá revize a propagace

Samostatný proces reviduje navržený výstup pomocí:

• Skenování tajemství.
• Statické bezpečnostní analýzy.
• Analýzy závislostí.
• Kontroly licencí a původu.
• Výsledků testů.
• Validace politik.
• Lidské revize pro změny s vysokým dopadem.

Cloudový agent GitHubu se řídí podobným vzorem tím, že vytváří návrhy pull requestů, omezuje přístup k větvím, vyžaduje lidskou revizi, omezuje spouštění pracovních postupů a poskytuje logy relací. (docs.github.com)

Praktické kontrolní seznamy pro zmírnění rizik

Před povolením agenta

• Vytvořte záznam v inventáři pro agenta.
• Identifikujte vlastníka agenta a jeho obchodní účel.
• Zdokumentujte každý nástroj, konektor a externí službu.
• Zdokumentujte každé pověření, ke kterému má agent přístup.
• Potvrďte, že produkční pověření chybí.
• Spusťte agenta v jednorázovém prostředí.
• Zakažte automatickou instalaci balíčků, pokud není explicitně schválena.
• Zakažte neomezený síťový přístup.
• Připněte model, agenta, nástroje, závislosti a obraz kontejneru.
• Chraňte soubory instrukcí agenta a konfigurační soubory pravidly vlastnictví kódu.
• Definujte, které akce vyžadují lidské schválení.
• Definujte maximální dobu trvání a náklady relace.
• Vytvořte plán pro rollback.

Před povolením přístupu k repozitáři

• Klasifikujte repozitář jako veřejný, interní, důvěrný nebo vysoce omezený.
• Zkontrolujte veškerou konfiguraci agenta řízenou repozitářem.
• Považujte readme soubory, obsah issue, komentáře a výstup testů za nedůvěryhodné.
• Zakažte automatické spouštění hooků a příkazů pracovního prostoru.
• Skenujte závislosti a instalační skripty.
• Použijte čistý, izolovaný pracovní prostor.
• Zabraňte přístupu k nesouvisejícím repozitářům.
• Ověřte, že v pracovním prostoru ani v logech sestavení neexistují žádná tajemství.
• Testujte se škodlivým textem issue a otrávenou dokumentací.
• Zaznamenejte commit repozitáře a hash konfigurace agenta.

Před povolením použití nástrojů

• Kde je to možné, nahraďte arbitrární přístup k shellu typovými operacemi.
• Použijte allowlist pro nástroje a destinace.
• Validujte cesty po kanonizaci.
• Odmítněte úniky přes symbolické odkazy.
• Zabraňte nástrojům v úpravě jejich vlastních souborů politik.
• Zabraňte agentovi v změně jeho vlastního režimu schvalování.
• Vyžadujte potvrzení před síťovým přístupem, který zahrnuje citlivá data.
• Logujte každé volání nástroje a jeho výsledek.
• Nastavte limity pro velikost souborů, dobu trvání příkazů, objem sítě a použití tokenů.
• Zkontrolujte popisy a oprávnění serveru Model Context Protocol.
• Odmítněte nepodepsané nebo neověřené definice nástrojů.

Před povolením publikace nebo nasazení kódu

• Vyžadujte samostatnou identitu pro agenta a lidského iniciátora.
• Vyžadujte lidskou revizi před merge.
• Vyžadujte nezávislé schválení před nasazením.
• Použijte krátkodobá publikační pověření.
• Použijte důvěryhodné publikování nebo identitu workload namísto dlouhodobých tokenů.
• Vyžadujte podpisy artefaktů a původ.
• Skenujte na tajemství a škodlivé závislosti.
• Sestavujte z čistého prostředí bez sdílených měnitelných cache.
• Ověřte, že artefakt odpovídá revidovanému zdroji.
• Udržujte rychlý proces rollbacku balíčků nebo rozšíření.
• Testujte obnovu záloh a snímků.

Během reakce na incident

• Ukončete dotčenou relaci agenta.
• Izolujte runnera nebo pracovní stanici.
• Zrušte všechna pověření dostupná agentovi.
• Zrušte pověření dostupná nástrojům a konektorům.
• Zachovejte logy relací, nástrojů, sítě a správy verzí.
• Zkontrolujte commity, issue, pull requesty, komentáře a publikace balíčků.
• Zkontrolujte cache a instalační skripty.
• Porovnejte publikované artefakty s důvěryhodným zdrojem.
• Vyhledejte neoprávněné odchozí destinace.
• Zkontrolujte perzistentní paměť a konfigurační soubory.
• Informujte dodavatele repozitářů, registrů balíčků a nástrojů.
• Znovu otočte pověření po forenzní analýze, pokud mohla být vystavena.
• Zaznamenejte, zda nějaká data opustila schválené prostředí.

Navrhované dohody o úrovni služeb bezpečnosti (SLA)

Toto jsou navrhované cíle nasazení, nikoli univerzální průmyslové standardy. Organizace by je měly přizpůsobit své toleranci k riziku.

Pro vysoce citlivá prostředí by nejdůležitější dohoda o úrovni služeb měla být nula úspěšných exfiltrací kritické cesty, spíše než průměrná míra detekce. Jedna úspěšná krádež vydávacího tokenu může být ničivější než tisíce neškodných zablokovaných pokusů.

Auditní artefakty, které by mělo produkovat každé nasazení

Vyspělé nasazení by mělo být schopno po události odpovědět na otázky:

• Kdo spustil agenta?
• Jaké uživatelské a servisní identity byly zapojeny?
• Jaký repozitář a commit byly použity?
• Která verze modelu a agenta běžela?
• Které instrukce byly aktivní?
• Jaký externí obsah vstoupil do kontextu?
• Které nástroje byly k dispozici?
• Které nástroje byly skutečně volány?
• Jaké argumenty byly odeslány?
• Jaké soubory byly čteny nebo změněny?
• Jaké síťové destinace byly kontaktní?
• Která pověření byla požadována?
• Které politiky povolily nebo zamítly každou akci?
• Jaká lidská schválení byla získána?
• Jaký artefakt byl vyprodukován?
• Jaký artefakt byl publikován?
• Jaké bylo konečné řešení?

Udržujte alespoň tyto artefakty:

1. Záznam inventáře agenta
2. Model hrozeb a diagram toku dat
3. Manifest schopností a oprávnění
4. Inventář nástrojů a konektorů
5. Záznam verze modelu, promptu a politiky
6. Obraz kontejneru a seznam závislostí (bill of materials)
7. Síťová politika a log odchozího provozu
8. Zpráva o expozici a redakci tajemství
9. Stopa relace a volání nástrojů
10. Záznam lidského schválení
11. Hodnocení bezpečnosti a zpráva red-teamu
12. Původ vydání a podpis artefaktu
13. Původ paměti a záznam rollbacku
14. Test reakce na incident a obnovy
15. Bezpečnostní doporučení dodavatele a záznam patchů

Logy by měly být zabezpečené proti manipulaci, s řízeným přístupem a uchovávané podle citlivosti dat. Běžné vývojářské relace mohou vyžadovat devadesátidenní uchování, zatímco relace, které přistupují k vydávacím systémům, regulovaným datům nebo repozitářům s vysokou hodnotou, mohou vyžadovat jeden rok nebo déle.

OpenAI popisuje interní monitorování, které reviduje interakce kódovacích agentů, volání nástrojů a potenciálně podezřelé chování, zatímco GitHub zdůrazňuje logy relací, podepsané commity, atribuci a auditní záznamy. Tyto vzorce podporují širší princip: chování agenta musí být pozorovatelné nezávisle na vlastním vysvětlení agenta, co udělal. (openai.com)

První praktický krok

Nejlepším prvním krokem není nasadit agenta proti produkčnímu repozitáři.

Místo toho:

1. Vytvořte jednorázový testovací repozitář.
2. Dejte agentovi úkol pouze pro čtení.
3. Spusťte jej uvnitř čerstvého sandboxu.
4. Vypněte přístup k vývojářským pověřením.
5. Zablokujte veškerý síťový provoz kromě poskytovatele modelu.
6. Přidejte záměrně škodlivou issue, instrukci do readme, popis nástroje a konfigurační soubor.
7. Zaznamenejte každý pokus o přístup k souboru, volání nástroje, příkaz a síťový požadavek.
8. Použijte výsledky k vytvoření vašeho prvního manifestu oprávnění a dohody o úrovni služeb bezpečnosti.

Pokud agent za těchto podmínek nemůže bezpečně dokončit úkol pouze pro čtení, není připraven na přístup pro zápis, automatizaci vydání nebo produkční systémy.

Závěr

Autonomní kódovací agenti by měli být zabezpečeni jako nedůvěryhodné, identitou vybavené automatizační systémy, nikoli jako běžné vývojářské nástroje.

Rozhodující bezpečnostní otázka nezní:

„Bude model následovat správné instrukce?“

Zní:

„Co se stane, když model bude následovat špatnou instrukci, zatímco má skutečná oprávnění?“

Injekce promptu, zneužití nástrojů, krádež tajemství, otrava dat a kompromitace dodavatelského řetězce jsou různé vstupní body do stejného základního selhání: agentovi je povoleno překročit příliš mnoho hranic důvěry bez nezávislého vynucení.

Incidenty z let 2025 a 2026 ukazují, že nejúčinnější kontroly jsou architektonické:

• Držte agenty dál od tajemství.
• Používejte jednorázové sandboxy schopností.
• Vynucujte politiky mimo model.
• Oddělte vývoj od produkce.
• Považujte konfiguraci a paměť za spustitelné útočné plochy.
• Používejte kontrolovaný odchozí provoz (egress).
• Odstraňte sdílené cache z privilegovaných pracovních postupů vydání.
• Připněte a ověřte každý nástroj a artefakt.
• Fázujte všechny zápisy.
• Vyžadujte nezávislé schválení pro nezvratné akce.
• Zachovejte detailní, proti manipulaci zabezpečené auditní záznamy.

Autonomie může být užitečná a bezpečná, ale pouze pokud je systém navržen tak, aby zmatený, zmanipulovaný nebo kompromitovaný agent měl omezenou autoritu, omezený dosah, omezený čas a jasně obnovitelný režim selhání.