AI Security 2026: Bezpečný vývoj s AI agenty

Přednášku pro Vás aktuálně připravujeme a dáváme si na tom hodně záležet.

O čem to bude? Reálná zkušenost s řízeným nasazením AI do firmy s cca 300 vývojáři a analytiky – co je nutné si odehrát jako prerekvizitu, jaký tooling pro to bylo potřeba nasadit resp. vytvořit a napsat, jakým způsobem je řešena bezpečnost interakce uživatele/vývojáře s AI a následná integrace na existující bezpečnostní nástroje (v tomto případě Sentinel / SIEM + Purview / DLP. A můžeme přidat i reálnou zkušenost s nedávným incidentem nad supply chain útokem skrze PyTorch Lightning AI. 

Většina vývojářů dneska používá AI jako chytřejší autocomplete. Napíšete prompt, dostanete kód, zkontrolujete, commitnete. To funguje. Ale co když chcete jít dál? Co když chcete, aby agent pracoval sám, vybíral si úkoly, implementoval změny, procházel review procesem a reagoval na zpětnou vazbu? Bez toho, aby mu někdo stál za zády?
Přesně tohle jsme zkusili. A ukázalo se, že rozdíl mezi copilotem a autonomním agentem není v kvalitě modelu. Je ve všem okolo. Kontejnery, CI, správa secrets, síťová izolace, stavový management — nic z toho není nové. Používáme to roky. Nové je, jak to celé slepit dohromady tak, aby uprostřed mohl fungovat agent, kterému nemusíte důvěřovat.

• Agentovi se nedá věřit - žádný system prompt ho nezabezpečí. Prompt injection není teoretická hrozba, je to problém, se kterým musíte počítat. Vždycky se dá najít cesta kolem instrukcí. Proto bezpečnost nemůže být v promptu — musí být v infrastruktuře. Tu agent přemluvit nemůže.
• Stav přežívá agenta - autonomní agent nemá kontext mezi běhy. Musíte vyřešit, kde žije stav, jak se obnoví po selhání a jak agent ví, kde minule skončil.
• Feedback loop místo one-shotu - skutečná hodnota přichází, když agent reaguje na code review, opravuje CI a učí se z toho. Jednorázové generování kódu je jen začátek.
• Škálování není kopírování - když to funguje pro jeden tým, neznamená to, že přidáte druhý tým a pojede to. Sdílená infrastruktura, izolace kontextů a různé projekty přinášejí vlastní problémy.

Na konkrétním projektu ukážu cestu od "zkusíme to" po systém, který běží v produkci na OpenShift — a co jsme se cestou naučili o tom, kde AI generuje hodnotu a kde jen generuje náklady.

Tato přednáška vám ukáže, že autonomní agenti nemusí být bezpečnostní hrozbou, pokud k jejich návrhu od začátku přistoupíme s principy nulové důvěry (Zero Trust). Odnesete si konkrétní koncepty, které vám umožní pustit AI agenty do reálné produkce s čistým svědomím.

• Typologie použití jako základ bezpečnosti – Jak styl fungování agenta a potenciální business dopad přímo definují technické požadavky na zabezpečení a míru lidského dohledu.
• Paradox zranitelnosti – Proč jsou LLM agenti náchylnější na manipulaci než lidé a jak se proti tomu bránit na úrovni systémového designu.
• Koncept delegované identity – Jak vyřešit to, aby agent jednal pouze v rámci striktně vymezeného průniku svých oprávnění a práv přihlášeného uživatele.
• Lidský dohled za běhu (JIT Consent) – Jak navrhnout mechanismus, který pozastaví běžící autonomní workflow při rizikové operaci a vyžádá si autorizované schválení uživatelem.
• Observability bez úniku dat – Jak efektivně trasovat a logovat rozhodovací procesy agentů pro potřeby auditu a jak vyřešit maskování citlivých údajů v promptech

Rozebereme si, jak koncepčně vyřešit autorizaci a propagaci identit, aby měl agent k dispozici vždy jen bezpečný průnik práv přihlášeného uživatele, své vlastní role a politik cílového systému. Probereme návrh mechanismů pro Just-In-Time schvalování rizikových operací a ukážeme si, jak trasovat a logovat „myšlenkové pochody“ agentů napříč infrastrukturou, aniž bychom v logách ukládali citlivá data.

Cílem je bezpečná software factory — prostředí, kde agent nedělá náhodné změny podle promptu, ale pracuje jako řízená vývojová jednotka: pochopí úkol, připraví plán, upraví kód, spustí validace, opraví chyby a doloží, proč je změna připravená k review.

• Zadání a kontext aplikace — agent potřebuje specku, acceptance criteria, architektonický kontext, ADR, dokumentaci, PR historii a známé výjimky. Bez toho neví, proč systém vypadá tak, jak vypadá, a snadno opraví symptom místo skutečného problému.
• Připravené vývojové prostředí — agent musí mít vlastní branch, sandbox, omezený shell, ephemerální credentials a způsob, jak aplikaci spustit. Potřebuje lokální služby, testovací data, mocky nebo ephemeral environment. Bez běžícího prostředí jen hádá nad kódem.
• Testy a validace jako součást práce — agent musí mít přístup k unit, integration, contract, E2E i security testům podle typu změny. Nestačí vygenerovat diff. Musí prokázat, že změna funguje, nerozbila regresi a pokrývá rizika ze zadání.
• Feedback loop pro iteraci — největší hodnota agenta není první návrh kódu, ale schopnost iterovat: spustit testy, přečíst chybu, pochopit příčinu, opravit řešení a validaci zopakovat. Bez rychlé zpětné vazby je agent jen generátor změn, ne vývojářská jednotka.
• Autonomie řízená dopadem — malé změny s nízkým rizikem může agent dokončit sám. Změny business logiky, API nebo větší diff jdou přes QA či senior review. Migrace, auth, permissions, CI/CD, infrastruktura a produkční data vyžadují architekta, security nebo vlastníka systému.

Budoucnost vývoje s AI nebude o tom, že agent napíše kus kódu. Bude o tom, kdo mu dokáže připravit prostředí, ve kterém může bezpečně stavět, testovat, učit se ze zpětné vazby a dodávat změny s důkazy kvality.

Zaměstnanci dnes nasazují AI nástroje bez vědomí IT a security týmů — coding agenty, IDE pluginy, MCP servery, SaaS integrace s LLM nebo browser extensions s přístupem k firemnímu kódu a datům. Shadow AI se stává novým shadow IT, jen s rychlejší adopcí a závažnějšími dopady na bezpečnost firemních dat.

V přednášce ukážu praktické přístupy k discovery, detekci a response na AI-related incidenty. Nejprve jak pomocí EDR telemetrie, síťových logů a OAuth app review zjistit, co ve vašem prostředí běží a jaká data mají tyto nástroje k dispozici. Pak jak vystavět detekční logiku pro konkrétní scénáře — exfiltrace firemního kódu do externího LLM, MCP server nebo plugin s širšími oprávněními než je nutné, zneužití AI agenta s přístupem k produkčním systémům, nebo prompt injection útok přes nedůvěryhodný kontext.

Třetí část pokryje incident response specifika pro AI incidenty: jak dohledat, co agent skutečně vykonal, jak rekonstruovat jeho akce z dostupných logů, kde jsou slepá místa v auditovatelnosti dnešních AI nástrojů, a jak tyto incidenty triage-ovat a eskalovat.