Jak navrhnout ohraničeného AI asistenta: nástroje, oprávnění a limity kontextu

Skutečnou hranici AI asistenta neurčuje věta v systémovém promptu, ale vykonatelná smlouva celé služby. Modelu lze přikázat, aby zprávu neposílal, avšak pokud má stále k dispozici odesílací nástroj a příliš silné přihlašovací údaje, zákaz není autorizační kontrolou. Tým proto nemá schvalovat asistenta jako jeden nedělitelný produkt. Musí samostatně vymezit každou schopnost, kterou uživatel vidí: jaké informace smí použít, pod čí identitou jedná, který úzký nástroj může zavolat, kam až smí dojít a co musí odmítnout, zastavit nebo předat odpovědnému člověku.

Co má mít asistent dovoleno dělat?

Nejprve napište jednovětou chartu služby a teprve potom ji rozdělte na konkrétní uživatelské schopnosti. Použitelná věta zní: „Pro [způsobilé uživatele] smí asistent [povolená rodina úloh] s využitím [schváleného rozsahu informací] vytvořit [povolený výsledek], nesmí však [výslovné nežádoucí výsledky nebo závažná rozhodnutí].“ Nejde o povinnou šablonu NIST či OWASP, ale o praktickou redakční syntézu jejich zásad. NIST AI RMF doporučuje dokumentovat účel, prostředí, úlohy, meze znalostí, lidský dohled i toleranci rizika.

Slovesa jako „pomáhat“ nebo „spravovat“ skrývají několik odlišných oprávnění. Vyhledání případu může vyžadovat pouze delegované čtení, zatímco úprava záznamu mění externí stav a odeslání odpovědi vytváří závazek vůči adresátovi. Každou operaci proto evidujte samostatně a před připojením nástrojů určete cílové uživatele, podporované situace, nepodporované výsledky, vlastníka služby a bod lidského dohledu. OWASP obdobně doporučuje zpřístupnit jen minimální funkce nástroje a dát úzké operaci přednost před otevřeným rozhraním.

• Nahraďte obecné „vyřídí zákaznický požadavek“ samostatným vyhledáním, shrnutím, návrhem odpovědi a odesláním.
• U každé schopnosti popište povolený výsledek i výslovný nežádoucí výsledek.
• Nezapojujte nástroj, dokud není zřejmé, kdo vlastní službu, riziko, přístup a lidské předání.

Jaké informace smí každá schopnost použít?

Limit kontextu má být informační obal, nikoli jen počet tokenů dostupných modelu. Pro každou schopnost určete schválené systémy, typy záznamů, klasifikaci, filtry objektů a období, požadovanou aktuálnost, oprávnění uživatele i data, která do kontextu nikdy nesmějí vstoupit. Výsledky funkce Map rámce NIST zahrnují dokumentované meze znalostí, cílový rozsah použití a dohled nad tím, jak lze výstup využít. Větší kontextové okno samo o sobě nepřidává autoritu ani nedokládá pravdivost odpovědi.

Externí zprávy, přílohy, dokumenty, odpovědi API a získané texty berte jako nedůvěryhodná data, která nesmějí potichu změnit instrukce služby. OWASP doporučuje tento obsah od instrukcí oddělovat. Samostatně navrhněte historii aktuální relace a trvalou paměť: co lze uložit, jak se oddělí uživatelé a relace, co se před uložením ověří, kdy položka vyprší a jak se smaže. Konkrétní velikost a dobu uchování stanovte podle služby; univerzální číslo by přehlíželo její účel, soukromí i pravidla záznamů.

• Chybějící oprávnění k důkazu vede k odmítnutí, nikoli k obejití filtru.
• Chybějící nebo zastaralý podklad musí být ve výsledku viditelný a odpověď se má omezit.
• Citlivý obsah, přihlašovací údaje a neověřené instrukce se nemají ukládat do paměti jen proto, že se objevily v konverzaci.

Jak mají hranici vymáhat identity, nástroje a oprávnění?

Autentizace, autorizace a schválení musejí zůstat třemi samostatnými rozhodnutími. Autentizace ověřuje, kdo je uživatel, klient nebo pracovní identita. Autorizace rozhoduje, zda tato identita smí provést danou operaci nad chráněným zdrojem. Schválení přijímá jeden konkrétní návrh akce. U chráněných integrací MCP tuto separaci ilustruje rozdělení klienta, chráněného zdroje a autorizačního serveru; nejde však o univerzální architekturu všech nástrojů. Podstatné je, aby oprávnění nevydával ani nevykládal samotný jazykový model.

Nástrojová brána a cílový systém mají na skutečné jednající identitě vynutit povolená slovesa, zdroje, objekty, pole, cíle, dobu platnosti přihlašovacích údajů a zamýšleného příjemce tokenu. Tým musí výslovně zvolit delegovanou autoritu uživatele, nebo řízenou pracovní identitu; nesmí nepozorovaně převzít privilegovaný účet správce. OWASP doporučuje minimální navazující oprávnění, zachování uživatelského autorizačního kontextu a kontrolu každého požadavku v cílovém systému. Prompt či přirozeně formulovaná zábrana tento mechanismus nenahrazuje.

• Zpřístupněte například „načíst způsobilý případ“, nikoli obecný přístup do databáze.
• Validujte parametry před vykonáním a odmítněte nepovolené zdroje, pole i cíle.
• Limity rychlosti, opakování, řetězení, dávky, času, nákladů a pojistek určujte podle konkrétní služby.
• Pro vratné zápisy zajistěte idempotenci nebo možnost návratu a pro poruchy skutečnou podmínku zastavení.

Konverzace může působit souvisle, její pravomoc však musí být rozdělena na malé, nezávisle vymáhané schopnosti.

Jak velký zásah smí jednotlivá schopnost provést?

Každá schopnost potřebuje výslovný strop zásahu a s rostoucím dopadem také silnější nezávislé kontroly. Praktická redakční stupnice začíná odpovědí nebo shrnutím, pokračuje doporučením, návrhem, konceptem a ohraničeným vratným zápisem a končí závažnou externí akcí nebo zakázaným rozhodnutím. Stupnice není normou NIST, NCSC ani OWASP; převádí jejich zásady nejmenších oprávnění, omezení akcí a externích pojistek do návrhu služby. Koncept nesmí být zaměněn za odeslání a návrh za odpovědné rozhodnutí.

Před významnou akcí ukažte člověku kontrolovatelný náhled a schválení spojte s aktérem, nástrojem, cílovým zdrojem, normalizovanými parametry, okamžikem a dobou platnosti. Před vykonáním znovu ověřte autorizaci i shodu návrhu; změna adresáta nebo obsahu vyžaduje nový cyklus. Schválení nikdy nedodá chybějící oprávnění, nerozšíří trvalý přístup a nezmění zakázané rozhodnutí na povolené. Platby, přidělení přístupu, destruktivní operace, produkční změny, významné externí závazky a odborná rozhodnutí s vysokým dopadem proto musejí zůstat pod odpovídající lidskou a deterministickou kontrolou.

• Odpověď či shrnutí pouze čte způsobilé informace a při chybějícím podkladu se zastaví.
• Koncept vzniká v nefinálním prostoru, má určeného kontrolora a nevytváří externí závazek.
• Vratný zápis používá úzkou operaci, validaci, auditní událost a službou určené provozní limity.
• Závažná externí akce vyžaduje přesný náhled, platnou autorizaci, vázané schválení a nezávislou prováděcí politiku.

Co se má stát, když asistent narazí na hranici?

Odmítnutí, bezpečná dílčí pomoc, lidské předání a bezpečnostní eskalace mají být výslovné výsledky služby se skutečnou podmínkou zastavení. Důvod může být mimo rozsah úlohy, nezpůsobilá informace, nedostatečná autorizace, chybějící schválení, zastaralý důkaz, potřeba odborného úsudku, nedostupná závislost, překročený provozní limit nebo bezpečnostní signál. Asistent má hranici sdělit srozumitelně, ale bez odhalování citlivých podrobností zásad. Nesmí tvrdit, že nástroj, kontrola zdroje, schválení nebo zápis proběhly, jestliže neproběhly.

Bezpečnou dílčí pomocí může být koncept, kontrolní seznam nebo žádost o chybějící informace, nikoli skryté pokračování akce. Předání má obsahovat původní cíl, relevantní necitlivý kontext, použitou schopnost, důvod, dostupné či chybějící důkazy, navržený další krok a trasovací identifikátor. Běžná uživatelská podpora, obchodní schválení a bezpečnostní incident nejsou stejná cesta, i když mohou sdílet část evidence. NCSC doporučuje incidentní plány s reakcí, eskalací, nápravou, připravenými pracovníky a kvalitními auditními záznamy.

• Při čekání na člověka se související provedení zastaví.
• Změněný návrh se po předání znovu validuje a nesmí automaticky zdědit staré schválení.
• Podezření na obcházení schválení, zvýšení oprávnění, vyvedení dat, otrávení paměti nebo nekontrolované řetězení patří do bezpečnostní cesty.
• Modelová míra jistoty nesmí být jediným spouštěčem odmítnutí, schválení ani eskalace.

Jak převést hranice do provozního návrhu?

Tým má vyplnit jeden řádek návrhového plátna pro každou uživatelsky viditelnou operaci a každý řádek napojit na vynutitelné kontroly, evidenci, testy, provozní metriky a odpovědného vlastníka. Zapište způsobilého aktéra a autentizaci, informační obal, pravidla relace a paměti, úzkou operaci nástroje, jednající identitu, rozsah zdrojů, strop zásahu, schválení, provozní limity, odmítnutí, auditní události, hodnoticí scénáře a eskalaci. Takové plátno je praktická redakční metoda podpořená kontrolními principy zdrojů, nikoli povinný formulář některé z citovaných institucí.

1. Začněte přesným požadavkem uživatele a pozorovatelnou definicí úspěchu.
2. Připojte datový a nástrojový rozsah ke skutečné identitě a cílovému systému.
3. Ke každému povolenému scénáři přidejte hraniční, odmítací, útočný a poruchový scénář.
4. Určete signál, podle něhož vlastník pozná odchylku, a pravomoc schopnost pozastavit, změnit nebo vyřadit.

U interního asistenta podpory mohou souhrn případu, koncept odpovědi a schválené odeslání sdílet jednu konverzační plochu, nikoli však automaticky stejná data a oprávnění. Oddělení čtení, přípravy a odeslání vychází z doporučení OWASP používat minimální funkce nástrojů a minimální navazující oprávnění. Záznamy mají umožnit zjistit použitou schopnost, zásady, zdroje, nástroj, autorizaci, schválení a výsledek, přičemž tajné a nepotřebné citlivé údaje se nemají uchovávat.

Jaké důkazy jsou nutné pro vydání a další provoz?

Vydání vyžaduje důkaz, že povolená služba i očekávaná odmítnutí fungují v podmínkách podobných skutečnému nasazení. Vedle běžných úloh testujte přístup k cizímu účtu, nepovolený nástroj, zastaralý důkaz, škodlivou instrukci ve vyhledaném obsahu, zakázaná data, obejití schválení, změněné parametry, duplicitní opakování, výpadek závislosti, pokus o vyvedení dat a nekontrolované řetězení. NIST AI RMF zahrnuje testování podobné nasazení, produkční monitorování, bezpečné selhání a pravidelné bezpečnostní hodnocení; NCSC doporučuje před vydáním bezpečnostní posouzení a sdělení známých omezení.

• Záznam má umožnit rekonstruovat žadatele, schopnost, verzi zásad, třídu zdroje a nástroje, autorizaci, schválení, výsledek akce a aktivní verze.
• Neukládejte tajné údaje ani neomezený citlivý kontext jen pro případ, že se někdy mohou hodit.
• Sledujte neočekávané použití nástrojů, opakovaná odmítnutí, autorizační chyby, změny schválení, neobvyklé sekvence, latenci, spotřebu, selhání a odchylky.
• Oddělte vlastníky chování služby, přístupových oprávnění, obchodních předání a bezpečnostních incidentů a dejte jim pravomoc schopnost pozastavit.

Podstatná změna modelu, promptu, získávání informací, paměti, nástroje, oprávnění, zásad, dat, poskytovatele nebo provozního prostředí znovu otevírá dotčené testy a podklady k vydání. NCSC výslovně upozorňuje, že změny dat, modelů a promptů mohou změnit chování systému, a doporučuje sledovat náhlé i postupné bezpečnostně významné odchylky s ohledem na soukromí. Začněte nejmenší užitečnou schopností a autoritu rozšiřujte jen jako kontrolovanou změnu. U citlivých dat, trvalé paměti, privilegovaného přístupu, destruktivních změn nebo incidentů zapojte odpovědné vlastníky bezpečnosti, identit, soukromí, záznamů, rizik a služby.