AI agenti jsou všude. Odpovídají zákazníkům, schvalují faktury, analyzují smlouvy, píšou kód a autonomně volají API třetích stran. Jenže zatímco 81 % technických týmů už má agenty v testování nebo produkci, pouze 14 % z nich prošlo kompletním bezpečnostním schválením. Výsledek? 88 % organizací hlásí potvrzený nebo podezřelý bezpečnostní incident spojený s AI agenty. Tento článek rozebírá, proč se to děje, kde jsou největší mezery — a hlavně co s tím.
Zpráva Gravitee State of AI Agent Security 2026, která analyzovala stovky organizací napříč odvětvími, odhalila znepokojivou propast mezi adopcí AI agentů a jejich zabezpečením. Čísla mluví jasně:
Nejvarovnější je diskonekt mezi vedením a realitou: 82 % executives si myslí, že jejich organizace je adekvátně chráněná — zatímco méně než polovina agentů je vůbec pod dohledem. To není optimismus, to je iluze bezpečnosti. A přesně tato iluze vede k tomu, že se problémy řeší až po incidentu, nikoliv preventivně.
Healthcare sektor vede statistiku s 92,7 % organizací hlásících incidenty, ale finanční služby a výroba nejsou daleko. Podle průzkumu Dark Reading 48 % bezpečnostních profesionálů věří, že agentic AI bude hlavním útočným vektorem do konce roku 2026. A americká vláda v lednu 2026 publikovala Request for Information o bezpečnosti AI agentů, protože zranitelnosti v agentních systémech mohou ohrozit kritickou infrastrukturu.
Problém není v tom, že by organizace nechtěly bezpečnost. Problém je v tom, že AI agenti jsou fundamentálně jiná technologie než cokoliv, co dosavadní bezpečnostní modely řešily. Agent není API endpoint. Agent je autonomní entita, která přijímá rozhodnutí, volá nástroje, řetězí akce a interaguje s dalšími agenty. A bezpečnostní frameworky na to nejsou připravené.
Když OWASP publikoval Top 10 for LLM Applications (aktualizace 2025), přidal mezi hlavní hrozby Excessive Agency — situaci, kdy LLM aplikace dostane příliš mnoho oprávnění a autonomie. U agentů, kteří jsou ze své podstaty navržení k autonomnímu jednání, je tohle riziko ještě výraznější. Podívejme se na konkrétní hrozby:
Vývojáři a business týmy nasazují AI agenty rychleji, než je security tým stíhá auditovat. Agent propojený s firemním CRM přes osobní API klíč zaměstnance. GPT wrapper, který má přístup k interním dokumentům přes neautorizovaný plugin. Copilot, který automaticky commituje do produkčního repozitáře. Shadow AI je nový shadow IT — jen s tím rozdílem, že agent aktivně jedná, zatímco stará SaaS aplikace pouze pasivně uchovávala data. Bez viditelnosti do toho, kolik agentů v organizaci běží, nemůžete zabezpečit ani jednoho.
Prompt injection zůstává na prvním místě OWASP Top 10 for LLMs. U agentů je ale dopad řádově horší: injektovaný prompt nemění jen textový výstup — spouští reálné akce. Agent s přístupem k emailu, databázi a platebnímu systému může po prompt injection odeslat data útočníkovi, smazat záznamy nebo autorizovat převod. Tool poisoning — situace, kdy útočník manipuluje popis nebo výstup nástroje, který agent používá — je dalším vektorem, který klasické bezpečnostní nástroje nedetekují, protože vypadá jako legitimní interakce.
Agent typicky nemá jednu akci — má řetěz akcí. Přečte email → extrahuje data → zavolá API → zapíše do databáze → pošle notifikaci. Každý krok v řetězu je potenciální bod selhání. Pokud agent v kroku 2 zpracuje manipulovaná data z kroku 1, zbylé kroky proběhnou s kontaminovaným vstupem. Microsoft Security Blog zdůrazňuje, že komponenty agenta — topics, tools a knowledge sources — definují jeho attack surface. Čím víc nástrojů agent má, tím větší je plocha útoku.
45,6 % organizací používá sdílené API klíče pro agent-to-agent autentikaci. To znamená, že kompromitace jednoho agenta dá útočníkovi přístup ke všem službám, ke kterým mají přístup všichni agenti se stejným klíčem. Klasický blast radius problém — ale v kontextu autonomních entit, které samy rozhodují, co s přístupem udělají. Princip least privilege, základní kámen Zero Trust, je u AI agentů ignorován systematicky.
Pouze 21,9 % týmů zachází s AI agenty jako s nezávislými identity-bearing entitami. Zbytek je řeší buď jako rozšíření lidského uživatele, nebo jako další mikroslužbu bez vlastní identity. Obojí je nebezpečné.
Agent, který běží pod identitou svého tvůrce (vývojáře), zdědí veškerá jeho oprávnění — často včetně admin přístupu k produkčním systémům. Agent, který nemá vlastní identitu vůbec, je neviditelný v audit logu. Když se něco pokazí, neexistuje způsob, jak zpětně zjistit, který agent co udělal a proč.
Správný přístup je jednoznačný: každý AI agent potřebuje vlastní identitu v identity management systému — stejně jako každý zaměstnanec nebo servisní účet. Tato identita musí mít:
To není akademické cvičení. V praxi to znamená, že vaše organizace musí rozšířit existující IAM (Identity and Access Management) systém o nový typ entity — „non-human identity" s atributy specifickými pro agenty: model, verze, owner, účel, povolené nástroje a maximální autonomie. Platformy jako Microsoft Entra Workload ID nebo HashiCorp Vault už tuto kategorii podporují. Otázka je, zda ji vaše organizace skutečně používá.
Většina organizací, které vůbec řeší bezpečnost AI agentů, se soustředí na build-time kontroly: code review, prompt testing, red teaming před nasazením. To je nutné — ale zdaleka ne dostatečné. Microsoft Security Blog to říká přímo: runtime security checks jsou klíčové, protože chování agenta v produkci se liší od toho, co jste viděli v testovacím prostředí.
Proč? Protože vstup agenta — uživatelské prompty, data z externích zdrojů, odpovědi z API — se mění v reálném čase. Agent, který v testovacím prostředí fungoval bezchybně, může v produkci narazit na adversarial input, který v testu nikdo nepředvídal. Build-time testování zachytí známé vzory; runtime monitoring zachytí to, co jste si neuměli představit.
Rozdíl mezi build-time a runtime security u AI agentů je analogický k rozdílu mezi statickou analýzou kódu a runtime application security (RASP) u tradičních aplikací. Potřebujete obojí. Ale pokud si musíte vybrat, runtime monitoring vám řekne pravdu o tom, co se skutečně děje — ne o tom, co se stát mělo.
Bezpečnost AI agentů není jednorázový projekt — je to rozšíření vašeho stávajícího bezpečnostního programu o novou kategorii entit. Následujících pět kroků vám pomůže začít pragmaticky, bez zbytečné paralýzy.
Než cokoliv zabezpečíte, musíte vědět, co zabezpečujete. Proveďte audit: kteří AI agenti existují, kdo je vytvořil, kde běží, k čemu mají přístup a kdo je vlastní. Zahrnujte i „neoficiální" agenty — Copilot pluginy, GPT wrappery, automatizace v Zapier/Make s LLM kroky. Shadow AI je reálný problém a bez inventáře stavíte obranu poslepu. Výstupem by měl být centrální registr agentů s klasifikací podle rizika (přístup k citlivým datům, finanční oprávnění, externí komunikace).
Rozšiřte svůj IAM systém o non-human identities pro AI agenty. Každý agent musí mít unikátní credentials, explicitně definované oprávnění (least privilege) a životní cyklus. Eliminujte sdílené API klíče — nahraďte je short-lived tokeny s automatickou rotací. Implementujte conditional access: agent smí provádět citlivé akce jen za definovaných podmínek (čas, prostředí, objem). Propojte agentní identity s vaším SIEM pro audit trail.
Implementujte webhook-based nebo middleware-based runtime checks. Každá riziková akce agenta (volání externího API, zápis do produkční databáze, odeslání dat mimo organizaci) by měla projít security gatewayem, který vyhodnotí kontext a rozhodne: povolit, zamítnout, eskalovat. Propojte s vaším observability stackem — metriky, logy a traces z agentů jsou stejně důležité jako z mikroslužeb. Definujte baseline chování a alertujte na anomálie.
Každý agent potřebuje explicitní bezpečnostní politiku: povolené nástroje, maximální počet kroků v řetězu, zakázané akce, output filtering pravidla a eskalační prahy. Využijte OWASP Top 10 for LLM Applications jako checklist: prompt injection ochrana, training data poisoning prevence, supply chain ověření nástrojů, excessive agency limity. Definujte politiky jako kód (policy-as-code), verzujte v Gitu a nasazujte přes CI/CD — stejně jako infrastrukturní politiky v Zero Trust modelu.
Zavedete pravidelný red teaming zaměřený specificky na AI agenty: prompt injection pokusy, tool poisoning, privilege escalation přes řetěz akcí, data exfiltration přes side channels. Testujte nejen jednotlivé agenty, ale i jejich interakce — multi-agent systémy mají emergentní chování, které se u jednotlivých agentů neprojeví. Automatizujte základní testy (OWASP LLM test suite) a doplňte manuálním red teamingem pro kreativní scénáře. Opakujte při každé změně modelu, nástrojů nebo oprávnění.
AI agenti jsou nejrychleji adoptovaná enterprise technologie za poslední dekádu. A zároveň nejrychleji ignorovaná z hlediska bezpečnosti. 88 % organizací s bezpečnostním incidentem není statistická anomálie — je to přirozený důsledek toho, že autonomním systémům dáváme přístup k citlivým datům a kritickým procesům bez adekvátních kontrol.
Řešení není zastavit adopci — to by bylo jako odmítnout cloud v roce 2015. Řešení je rozšířit bezpečnostní model: přidat agenty jako novou kategorii identity, zavést runtime monitoring, implementovat guardrails a testovat jako útočník. Organizace, které to udělají teď, budou mít konkurenční výhodu. Ty, které to odkládají, budou řešit incidenty.
Začněte tím nejjednodušším: zjistěte, kolik agentů ve vaší organizaci běží. Odpověď vás pravděpodobně překvapí.