Většina rad k zabezpečení agenta spočívá ve vkládání instrukcí do system promptu. Tenhle přístup bere bezpečnost jako sadu chování - v podstatě agenta žádá, ať určité věci nedělá. To je zásadně chybné, protože instrukce je žádost, ne technická hranice. Žádost se dá přehlasovat, ignorovat nebo obejít sofistikovaným vstupem.
Prompt je instrukce, ne hranice. To znamená, že spoléhat se na to, že se agent bude držet pravidel, dělá návrh zranitelný vůči nepřátelskému vstupu. Bezpečnostní model se proto musí přesunout od řízení instrukcí k vynucování ověřitelných technických omezení toho, kam agent fyzicky dosáhne nebo co může spustit.
Proč prompt není hranice
Aktuální vydání OWASP Top 10 pro aplikace s velkými jazykovými modely, zveřejněné 4. srpna 2026, tenhle zásadní problém zdůrazňuje. Prompt Injection zůstává na pozici LLM01, první položce seznamu. Zároveň výrazně stoupla Excessive Agency, ve vydání 2026 na LLM03, oproti šesté pozici ve vydání 2025. Tahle kombinace signalizuje zásadní posun rizika: vstupu se nedá věřit a oprávnění udělená agentovi se stávají hlavním vektorem nebezpečí.
Tohle riziko umocňuje sama povaha dat. Text vložený do záznamu - ať už v dokumentu, e-mailu, popisu ticketu nebo na webové stránce - jsou data, nikdy autorizace. Agenta, který bere obsah jako instrukci, dokáže řídit kdokoli, kdo umí zapisovat do jakéhokoli systému, který agent čte. Technické oddělení dat od příkazu musí být vynucené na architektonické úrovni, ne spoléhané na to, že agent správně interpretuje záměr.
Tři věci, které to skutečně vynucují
Vynucená izolace vyžaduje ošetřit tři odlišné, ověřitelné technické vrstvy. Jsou to přihlašovací údaje, rozsah přístupu a runtime.
Přihlašovací údaje
Princip zní, že agent musí mít vlastní, vyhrazenou sadu přihlašovacích údajů, a ty se nikdy nesmí sdílet. Pokud agent nedrží potřebný token nebo klíč, nemůže se u systému autentizovat, bez ohledu na to, co se mu řekne. Jeden architektonický vzor je brána, která drží přihlašovací údaje a při každém volání vloží požadovanou identitu. Tím agent nikdy nedrží syrový token sám, což omezuje jeho schopnost autentizační materiál zneužít nebo vynést ven.
Ověřit si to ve vlastním systému lze tak, že se pokusíte agenta donutit autentizovat se přihlašovacími údaji, pro které nebyl výslovně navržený. Pokud se systém nepodaří autentizovat nebo identitu odmítne, hranice přihlašovacích údajů drží.
Rozsah přístupu
Rozsah přístupu stanovuje přesné hranice oprávnění a zajišťuje, že se oprávnění udělují záměrně a úzce, ne plošně. Je zásadní rozpoznat, že technická schopnost zapisovat do systému není totéž co oprávnění zapisovat. Oprávnění udělená plošně - technické skupině, nebo feature flagem, který dostane každý - jsou konfigurační dluh, ne mandát.
Ověření spočívá v testování agenta proti zdroji, který technicky vidí, ale neměl by ho moci upravit. Pokud systém akci správně odmítne, úzký rozsah je vynucený.
Runtime
Runtime definuje prostředí, ve kterém proces běží, a co z tohoto bodu fyzicky dosáhne. Agent je jen tak omezený, jako prostředí, ve kterém běží. Tahle vrstva zajišťuje, že i když se agenta podaří přelstít ke spuštění příkazu, operační systém nebo kontejnerové prostředí omezí rozsah tohoto spuštění.
Ověřit se to dá tak, že se pokusíte přimět agenta komunikovat se zdrojem nebo službou, která je fyzicky mimo jeho vyhrazené runtime prostředí. Systém musí požadavek odmítnout kvůli prostorovému omezení, ne kvůli internímu pravidlu nebo instrukci v promptu.
Containment dřív než schopnosti
O containmentu se musí rozhodnout dřív, než se agent postaví. Nedá se přidat dodatečně, protože každá dřív udělená schopnost už má kolem sebe postavený návrh. Pokud nejdřív postavíte funkčnost a pak se ji snažíte zabalit do bezpečnostních vrstev, jde o dodatečnou úpravu a výsledná architektura ponese vlastní zranitelnosti.
Systém navíc musí být navržený tak, aby se odebrání oprávnění dosáhlo jednou změnou na jednom místě, která zavře všechny dveře najednou. Tenhle jediný bod kontroly zajišťuje, že změny bezpečnostní politiky jsou okamžité a úplné, místo aby vyžadovaly ruční aktualizace napříč více oddělenými komponentami.
Co záměrně netvrdíme
Tenhle návrhový přístup je inženýrské uspořádání, ne certifikát shody. Netvrdíme soulad s žádnou konkrétní normou ani auditním požadavkem. Zaměřujeme se čistě na technické principy izolace a ověřitelného odmítnutí.
Zásadní je, že žádná z těch tří vrstev - přihlašovací údaje, rozsah přístupu, runtime - neodpovídá na otázku, jestli má agent vůbec existovat. Architektonické rozhodnutí agenta nasadit zůstává obchodním a rizikovým rozhodnutím, odděleným od technických kontrol. K téhle otázce víc v textu agent, kterého jsme se rozhodli nestavět.
Otázky a odpovědi
Jak zabráníte tomu, aby byl AI agent obelstěn prompt injection?
Jen přes prompty to zastavit nejde. Obrana musí být architektonická. Vyžaduje to vynucení technických hranic přes přihlašovací údaje, rozsah přístupu a runtime izolaci. Tyhle vrstvy zajišťují, že i když se agenta podaří přelstít k přijetí škodlivé instrukce, samotný systém tu akci odmítne.
Stačí system prompt na zabezpečení agenta?
Ne. System prompt je jen sada instrukcí, které jsou doporučující a dají se obejít. Bezpečnost musí být zavedená přes ověřitelné technické kontroly. Hranice musí být fyzické a výpočetní, ne jazykové.
Jaká oprávnění by měl AI agent mít?
Agent by měl mít jen oprávnění, která jsou záměrně a úzce udělená pro konkrétní úkoly. Nikdy neudělujte oprávnění plošně. Veškeré technické schopnosti musí být oddělené od skutečné autorizace.
Co se stane, když je agent kompromitovaný?
Cílem návrhu je zajistit, aby kompromitace zůstala lokalizovaná. Vynucením přísných přihlašovacích údajů, úzkého rozsahu přístupu a omezeného runtime se škoda, kterou útočník způsobí, omezí na nejmenší možnou provozní oblast.
Zásadní návrhová otázka, kterou se musí řídit každé nasazení agenta, nezní: co všechno bude umět? Musí znít: jaký technický mechanismus vynutí jeho izolaci, pokud ho někdo obrátí proti nám? Soustředění na hranice, ne na schopnosti, je to, co takové uspořádání drží pohromadě.