16. 8. 2026 · Miharu Edge

Firmy chrání kód před AI. Někdy tím chrání i jeho chyby

U standardních malých a středních aplikací může být kontrolované zpracování sanitizované kopie repozitáře menším rizikem než dlouhodobý provoz známých chyb. Rozhodující není obecný zákaz, ale citlivost konkrétního kódu, izolace agentního prostředí a schopnost udržet architektonické standardy.

AI agent pracuje se sanitizovanou kopií zdrojového kódu oddělenou od původního repozitáře

Firmy často posuzují programovací agenty jedinou otázkou: opustí náš zdrojový kód vlastní infrastrukturu? Otázka je legitimní, ale neúplná. Neříká, zda repozitář obsahuje produkční data, tajné přístupové údaje nebo skutečně unikátní know-how. A ignoruje riziko, které podnik přijímá tím, že nechá chybnou aplikaci v provozu.

Běžný kód je často přeceňovaný. Data a identity nikoli

Zdrojový kód může být cenným duševním vlastnictvím. U velké části běžných podnikových aplikací ale jeho nejcitlivější složkou nejsou controllery, formuláře ani standardní integrační vrstvy. Větší hodnotu mívají produkční data, přihlašovací údaje, hranice mezi tenanty, neveřejná obchodní pravidla a provozní znalost toho, jak je systém skutečně používán.

Není proto rozumné chránit běžnou React komponentu stejným režimem jako cenotvorbu, detekci podvodů nebo kryptografickou implementaci. Současně ani generický kód není bez rizika. Může odhalit útokovou plochu, použité komponenty a chybné bezpečnostní předpoklady. Smyslem není hodnotu kódu popřít, ale rozdělit ji přesněji.

Co je v repozitáři a co skutečně hrozí

Obsah	Převládající riziko	Doporučený režim
Produkční data a logy	Soukromí, regulace, přímý dopad na zákazníka	Do externího agentního prostředí nepatří
Tajné údaje, certifikáty a servisní účty	Okamžitá kompromitace dalších systémů	Odstranit a nahradit neplatnými testovacími hodnotami
Unikátní algoritmy a obchodní pravidla	Konkurenční a smluvní riziko	Individuální klasifikace a schválený režim
Standardní frameworkový kód	Znalost útokové plochy, obvykle nižší unikátnost	Sanitizovaná kopie může být přijatelná
Architektonické konvence	Budoucí náklady na změny a provoz	Vynucovat testy a pravidly v CI

Manažerské shrnutí

01Pro AI není každý kód stejně citlivý. Při rozhodování, co lze zpřístupnit AI nástrojům, vyžadují části pracující s produkčními daty, identitami a unikátními firemními pravidly přísnější režim než běžné React komponenty a standardní integrační kód.

02Cloud může mít velmi odlišné režimy. Stejný dodavatel nabízí prostředí s odlišnou retencí, použitím dat k trénování, síťovým přístupem a prací se secrets. Bezpečnostní posouzení proto patří konkrétnímu produktu a jeho konfiguraci, ne značce jako celku.

03Velký problém je nový nestandard. Agent může splnit zadání a projít testy, ale současně zavést další způsob logování, validace nebo práce s daty.

Vzkaz autora: Ano, s tímto vám mohu pomoct :)

Doporučení pro vedení

Neschvalujte obecně „zdrojový kód v AI“. Schvalujte konkrétní repozitář podle čtyř otázek: co odhaluje, jaká data obsahuje, kam se z agentního prostředí lze připojit a jak snadno lze změnu ověřit.

„Dát kód OpenAI“ není jeden bezpečnostní režim

Stejný dodavatel nabízí výrazně odlišné datové a provozní režimy. U firemních produktů a API OpenAI standardně nepoužívá vstupy a výstupy k trénování. U služeb pro jednotlivce může obsah k trénování použít, pokud uživatel příslušné volby nevypne. U API mohou standardně vznikat protokoly pro sledování zneužití s retencí až 30 dní, zatímco způsobilí zákazníci mohou žádat o režimy Modified Abuse Monitoring nebo Zero Data Retention.

Codex cloud pracuje v izolovaných kontejnerech spravovaných OpenAI. Secrets použité v setup fázi nejsou po jejím dokončení předány agentovi. Agentní fáze běží ve výchozím stavu bez síťového přístupu. Pokud jej organizace povolí, rozšíří útokovou plochu o prompt injection z načteného obsahu, exfiltraci kódu a secrets a kompromitované závislosti. Síťový přístup proto patří pouze k nezbytným doménám a metodám.

Nákupní pravidlo

Neschvalujte „OpenAI pro vývoj“. Schvalujte konkrétní produkt, typ účtu, nastavení trénování, retenční režim, přístup k repozitářům, internetovou politiku a způsob práce s tajnými údaji.

Mimo vlastní infrastrukturu neznamená mimo zabezpečení

DMZ je pro tento způsob práce nepřesné a potenciálně zavádějící označení. NIST ji definuje jako perimetrální nebo neutrální síťový segment mezi důvěryhodnější interní a méně důvěryhodnou externí sítí. Pro cloudového programovacího agenta je přesnější mluvit o izolovaném jednorázovém pracovním prostředí nebo sanitizované vývojové enklávě.

Cílem není poslat celý interní vývojový svět ven. Cílem je vytvořit úzký pracovní balíček, z něhož agent připraví diff nebo pull request, který se vrátí do interního validačního řetězce. Agent má pracovat mimo produkci, nikoli mimo zabezpečení.

Pouhé přejmenování endpointů není bezpečnostní kontrola. Adresa služby není tajemství. I kdyby agent znal skutečný produkční endpoint, nesmí mít platnou identitu, síťovou cestu ani oprávnění, s nimiž by jej mohl použít. To je praktická aplikace zero trust. NIST nestaví důvěru na umístění v síti, ale na explicitní autentizaci a autorizaci přístupu ke konkrétnímu zdroji.

Kontrolovaný řetězec změny

Interní repozitář → čistý export → izolované pracovní prostředí → diff nebo pull request → interní CI a bezpečnostní kontroly → staging.

Bezpečnostní hranice

Produkční endpointy nahraďte mocky nebo stuby. Skutečnou ochranu vytváří absence přihlašovacích údajů, síťové cesty a produkčních oprávnění, nikoli změněný název hostu.

Syntetická data musí být užitečná, ne jen falešná

Pro vývoj a opravy není nutné předávat kopii produkční databáze. A divili byste se, kolik vývojářů to stále dělá. Agent potřebuje data, která zachovají schéma, referenční vazby, povinné a nepovinné hodnoty, více tenantů a okrajové případy, na nichž aplikace v minulosti selhala. Dobrá syntetická sada je proto spíše spustitelnou specifikací než náhodně vygenerovaným obsahem.

Slovo „syntetická“ samo o sobě nezaručuje soukromí. NIST upozorňuje, že řada metod pro generování syntetických dat neposkytuje diferenciální soukromí ani jinou formální záruku.

Anonymizace, pseudonymizace a neanonymizovaná data

Neanonymizovaná data obsahují přímé nebo nepřímé identifikátory. Pseudonymizace identifikátory oddělí nebo nahradí a může výrazně snížit riziko, sama o sobě ale z dat nedělá anonymní soubor. Evropský sbor pro ochranu osobních údajů v roce 2025 zdůraznil, že pokud lze záznam spojit s člověkem pomocí doplňující informace, stále jde o osobní údaj. Soudní dvůr EU později doplnil, že u předaných dat se posuzují také reálné možnosti konkrétního příjemce identitu obnovit. Pro správce, který drží převodní tabulku, klíč nebo jiný prostředek k opětovnému přiřazení, proto pseudonymizace není anonymizací a povinnosti ochrany osobních údajů pokračují.

Pokud data vznikají učením z reálných záznamů, je nutné posoudit riziko rekonstrukce nebo opětovného přiřazení ke konkrétní osobě. Pro běžné testování bývá bezpečnější začít z obchodních pravidel a ručně definovaných scénářů.

Doporučení pro testovací data

Generujte testovací data z pravidel a incidentních scénářů, nikoli kopírováním produkce. Syntetická sada musí pokrýt hraniční stavy, oddělení tenantů a chybové větve. Jinak vytvoří bezpečný, ale málo užitečný test.

Kde agent přináší 90 procent: standardní a testovatelná práce

V mé praxi programovací agenti schopně provádějí opravy a standardní změny v aplikacích o přibližně čtyřech milionech znaků zdrojového kódu. Počet znaků není standardním měřítkem složitosti ani univerzálním limitem. Dává ale orientační představu o rozsahu systémů, u nichž lze při dobré struktuře, testech a jasném zadání udržet práci agenta pod kontrolou.

U vymezených oprav a běžných funkcí se může čistý čas implementace zkrátit až o 90 procent. Neznamená to o 90 procent rychlejší celý produktový vývoj. Analýza požadavku, architektonické rozhodnutí, review, bezpečnostní kontrola a odpovědnost za nasazení zůstávají. Zrychluje se především převod jasného záměru do otestovaného diffu.

Frontend je ideální pouze s design systémem

React a další frontendové frameworky jsou pro agenty vhodné, pokud aplikace používá schválené komponenty, jednotnou validaci, jeden stavový model a stabilní API kontrakty. Agent pak skládá známé prvky a výsledek lze rychle ověřit testem v prohlížeči, vizuální regresí a kontrolou přístupnosti.

Bez design systému ale stejný agent pouze rychleji násobí výjimky: další variantu formuláře, lokální CSS, jiný způsob práce s chybami nebo nový model správy stavu. Frontend není automaticky jednoduchý. Je pouze velmi rychle vidět, když jeho standardy neexistují.

Metrika pro vedení

Neměřte počet řádků nebo tokenů vytvořených AI. Měřte čas od schváleného zadání ke zkontrolovanému sloučení změny, podíl vrácených změn, vady uniklé do produkce a porušení architektonických pravidel.

Agent může uzavřít zadání a současně zhoršit aplikaci

U heterogenních aplikací nad přibližně deset milionů znaků zdrojového kódu nedoporučuji plošné agentní zásahy napříč systémem. Není to tvrdá technická hranice a problémem není pouze kontextové okno. Velké systémy mají skryté vazby, historické výjimky a několik navzájem odlišných způsobů, jak řešit stejnou věc.

Agent pak může vytvořit lokálně správnou změnu, která projde funkčními testy, ale zavede čtvrtý způsob logování, další vrstvu validace nebo nový přístup k databázi. Zadání je uzavřené. Architektura je horší.

Výzkum tento mechanismus začíná měřit. SlopCodeBench nechal 15 programovacích agentů opakovaně rozšiřovat vlastní řešení ve 36 úlohách a 196 kontrolních bodech. Žádný agent nedokončil jedinou úlohu od začátku do konce; nejlepší prošel 14,8 procenta kontrolních bodů. Strukturální eroze rostla v 77 procentech trajektorií a redundance v 75,5 procenta. Instrukce zaměřené na kvalitu zlepšily počáteční stav, ale nezastavily další degradaci.

Předběžný benchmark Theory of Code Space navíc ukazuje, že schopnost udržovat mapu architektury se mezi modely výrazně liší a některé při průběžném zkoumání zapomínají dříve nalezené komponenty. Autoři sami výsledky označují za předběžné, ale problém přesně odpovídá praxi velkých repozitářů: najít soubor není totéž jako udržet konzistentní model celého systému.

Také randomizovaná studie METR z roku 2025 zjistila, že zkušení správci pracující na vlastních vyspělých open source repozitářích byli s tehdejšími AI nástroji v průměru o 19 procent pomalejší. Následná celková kontrola upozornila, že agenti často vytvořili funkčně správný kód, který nebyl snadno použitelný kvůli testům, lintingu, formátování nebo obecné kvalitě. Výsledky nelze zobecnit na veškerý vývoj, ale dobře ukazují, proč rozhoduje typ úlohy a stav kódu.

Co z toho plyne

AI nezrychluje software obecně. Dramaticky zrychluje konkrétní změny v konkrétních, dostatečně standardizovaných systémech.

Limit autonomie

Pokud repozitář obsahuje tři způsoby, jak řešit stejný problém, agent bez strojově vynucených pravidel pravděpodobně vytvoří čtvrtý.

Kde agenta použít a kde jej omezit

Typ systému	Doporučený režim	Podmínka
Standardní malá nebo střední aplikace	Široké využití pro opravy a běžné funkce	Čistý export, dobré testy, jednotné konvence
Velký, ale modulární systém	Práce pouze v jednom jasně vymezeném modulu	Jasný kontrakt, vlastníci kódu a architektonické testy
Heterogenní monolit nad 10 milionů znaků	Bez plošných autonomních změn	Nejdříve standardizace, modularizace a mapa závislostí
Repozitář s produkčními daty nebo tajnými údaji	Externí cloudový postup neschvalovat	Nejdříve sanitizace a oddělení testovacího prostředí
Frontend bez design systému	Agent pouze na vymezené komponenty	Nejdříve sjednotit komponenty, stavy a validaci

Pět bezpečnostních bran před sloučením změny

Brána	Co musí prokázat
1. Čistý vstup	Kontrola tajných údajů v pracovním stromu i historii; žádná produkční data, certifikáty ani CI/CD tokeny.
2. Funkční důkaz	Regrese, integrační testy a explicitní akceptační kritéria pro požadovanou změnu.
3. Test úniku	Negativní testy autorizace a oddělení tenantů; kontrola logů, chybových hlášek a odchozí komunikace.
4. Architektonický důkaz	Pravidla závislostí, linting, kontraktní testy, pravidla design systému a zákaz nového vzoru bez schválení.
5. Řízené nasazení	Diff nebo pull request, lidské review, staging, návrat změny a dohledatelná verze modelu i agentního prostředí.

Nezakazovat agenty. Zpřesnit hranice

Strach o data nemá zmizet. Má se stát přesnějším. Plošný zákaz může udržovat zranitelnosti, technický dluh a drahou ruční práci. Plošné nadšení naopak urychlí architektonickou entropii. Vhodným prvním cílem je standardní, testovatelná aplikace, z níž lze odstranit nenahraditelná data a identity a jejíž změny lze spolehlivě ověřit.

Největší příležitostí programovacích agentů na této úrovni není generovat další aplikace. Je jí systematicky opravovat ty stávající. Největším rizikem u velkých systémů pak nemusí být, že agent odnese zdrojový kód. Může jím být, že velmi rychle a zcela úspěšně přidá další výjimku.

Co si odnést

Dobře ohraničený agent nad sanitizovanou kopií může být menší riziko než produkční systém, jehož ochrana stojí na tom, že nikdo neuvidí jeho kód.

Zdroje14