Jak dát agentovi AI přístup a nepřijít o kontrolu

Rychlá cesta — dát agentovi administrátorský přístup a detaily vyřešit později — vytváří přesně ten rozsah dopadu, na kterém si týmy spálí prsty. Tady je vrstvený model, který se tomu vyhýbá, ověřený řádek po řádku podle toho, co je skutečně v produktu hotové.

Nejrychlejší způsob, jak připojit agenta AI ke skutečnému systému, je dát mu stejný přístup, jaký byste dali novému kolegovi první den: plného administrátora, každý nástroj, detaily později. Pořádně omezit přístup zabere čas — někdo musí rozhodnout, kterých nástrojů se agent smí dotknout, jaká data smí číst a co smí dělat, aniž by se nejdřív zeptal. V malém týmu, který je už tak na hraně, nikdo nechce být ten, kdo to zpomalí. Výchozí stav se proto stane „prostě mu dej přístup“ a všichni jdou dál.

Ten instinkt je chybný a důvod nemá nic společného s tím, jestli agent dnes působí důvěryhodně. Jde o to, co se stane v den, kdy nebude. Agent s dosahem na úrovni administrátora, který udělá rutinní chybu, dostane podstrčenou instrukci ukrytou v dokumentu, který měl přečíst, nebo si je prostě jistý a mýlí se v tom, co volání nástroje udělá, má teď dosah administrátora. Selhání není špatná odpověď chatbota, nad kterou se dá mávnout rukou — je to rozsah dopadu kompromitovaného administrátorského účtu, jenže může jednat rychlostí stroje, napříč každým systémem, kterého se dotkne, a nikdo se v reálném čase nedívá, aby to zachytil dřív, než se škoda navrší.

Soubor vrstev, který rozsah dopadu skutečně udrží

Dobrý návrh přístupu pro agenta AI není jeden přepínač. Je to šest samostatných rozhodnutí naskládaných na sebe, kde každá vrstva existuje proto, aby zastavila konkrétní způsob, jakým se první chyba změní v mnohem větší. Vynecháte-li vrstvu, nic jste nezjednodušili — jen jste posunuli bod selhání někam, kde je hůř vidět.

Žádná z těchto šesti vrstev není exotická. Každá zavírá díru, kterou vrstva nad ní nechává dokořán — identita sama nezastaví příliš široký přístup k nástrojům a seznam povolených nástrojů sám nezastaví tichou, nevratnou akci. Fungují jen naskládané.

Identita: jedno přihlášení, ne stínové

Začněte identitou, protože všechno nad ní z ní vychází. Je-li přístup agenta vázaný na přihlášení, o jehož existenci IT neví, na pozdějších vrstvách nezáleží — nemůžete odvolat oprávnění, o kterém jste nevěděli. Plán Enterprise ve FabricLoop napojí pracovní prostor na poskytovatele identity organizace přes SSO a SAML, stejný mechanismus, který už řídí přihlášení k e-mailu a zbytku firemního softwaru. To má význam právě pro přístup agentů, protože spojení AI a běžný přístup ke spolupráci spadají pod jeden model identity místo dvou. Když IT u poskytovatele identity někoho deaktivuje, tahle jediná akce odstraní jeho přístup do FabricLoop a s ním i všechna spojení MCP vázaná na jeho přihlášení — místo aby po něm zůstal osiřelé přihlašovací údaje agenta, který nikdo neuklidí.

Oprávnění na osobu, oběma směry

Spojení AI ve FabricLoop běží dvěma směry a stejná zásada — žádné sdílené přihlašovací údaje pro celý tým — platí pro oba.

Příchozí je situace, kdy se vnější nástroj jako Cursor, Claude nebo ChatGPT připojí do FabricLoop jako klient MCP, aby mohl číst nebo zapisovat úkoly, poznámky a zprávy s oprávněními konkrétního člověka. Vlastní pokyny k nastavení FabricLoop výslovně říkají, že jde o proces, který probíhá pro každého zvlášť: každý otevře obrazovku souhlasu na app.fabricloop.com/oauth/consent, vybere pracovní prostor a schválí konkrétní rozsahy nástrojů, které ten klient dostane — ne přepínač pro celý pracovní prostor, který administrátor jednou přepne pro všechny. Doporučení pro týmy přímo pojmenovává selhání, kterému to má zabránit: nesdílejte přístupový token jedné osoby napříč týmem, protože každý má dokončit vlastní souhlas. Výsledkem je seznam připojených klientů viditelný na osobu a odvolatelný na osobu, ne přístupový token zakopaný v konfiguračním souboru, který přežije důvod, proč vznikl.

Odchozí je zrcadlový případ: FabricLoop se připojuje ven k aplikaci třetí strany ve vlastním katalogu MCP, třeba ke sledování projektů nebo kalendáři. Rozdělení je tu záměrné. Administrátor aplikaci povolí pro celý pracovní prostor — rozhodnutí, jestli nástroj v organizaci smí vůbec existovat — a pak si každý, kdo ji chce použít, připojí vlastní účet. Přepnutí toho přepínače administrátorem nepředá aplikaci identitu každého zaměstnance; jen zpřístupní možnost a každý se stále musí ověřit jako on sám, než spojení cokoli udělá.

Rozsah: jen pro čtení, nebo seznam povolených — ne všechno, nebo nic

Identita odpovídá na to, kdo. Oprávnění na osobu odpovídají na to, čí účet. Ani jedno neodpovídá na otázku, která skutečně určuje velikost chyby: co spojení umí, jakmile je živé. To je práce třetí vrstvy.

Na obrazovce detailu jakékoli připojené aplikace může administrátor nastavit zobrazovaný název, zapnout režim Jen pro čtení a zvolit zásady pro nástroje — buď každý dostupný nástroj, nebo konkrétní seznam povolených. To je rozdíl mezi „tento agent umí číst naši nástěnku úkolů“ a „tento agent umí číst naši nástěnku úkolů a také mazat záznamy, měnit vlastníky a psát do každého kanálu“. Většina spojení druhou verzi nepotřebuje a většina příběhů o tom, jak přístup agenta selže způsobem, kterého se lidé bojí, začíná spojením, kterému se ve výchozím stavu dal každý nástroj, protože nikoho nenapadlo zaškrtnout pole, které ho omezí.

Bezpečnostní stránka FabricLoop popisuje vzniklá oprávnění jako „omezená rozsahem“ a výslovně jako „ne trvalý, neviditelný přístup“ — auditovaná a odvolatelná, stejným jazykem, který firma používá na stránce vysvětlující Legibility, myšlenku, že přístup AI má být něco, co umíte pojmenovat a prohlédnout, ne neformální znalosti o tom, který starý token bota ještě funguje.

Chování za běhu: agent připraví návrh, člověk odešle

Všechno nad touto vrstvou řídí, kam agent dosáhne. Tahle řídí, co smí udělat, jakmile tam je — a právě tuhle vrstvu většina týmů přeskočí, protože působí nejpomaleji.

Vestavěný asistent FabricLoop, Loop, je postavený kolem omezení, které firma otevřeně uvádí ve vlastní dokumentaci produktu: „Loop připraví návrh; vy odešlete. Sám do kanálu nepíše a nikoho neupozorní.“ Požádejte ho, ať shrne vlákno, a shrne ho. Požádejte ho, ať napíše aktualizaci, a napíše návrh — a člověk ho stále musí zkontrolovat a odeslat, než ho uvidí kdokoli jiný. Stejný vzorec platí pro agenty, kteří žijí v kanálu jako členové týmu: když některý z nich čeká na rozhodnutí člověka, nehádá a nejde dál. Objeví se pod „Čeká na vás“ na kartě Aplikace a agenti toho kanálu — přesně na místě, které tým už kontroluje, ne v samostatné konzoli, na jejíž existenci nikdo nepamatuje.

To je praktický podoba toho, čemu literatura o agentních rámcích říká vzorec ask_human / resume: agent se zastaví v bodě, kde je potřeba úsudek, zeptá se a pokračuje, teprve až člověk odpoví. FabricLoop tu základní myšlenku formuluje jako Míra lidského zásahu — ne „jak často agent potřebuje člověka“ brané jako selhání, které se má odstranit, ale číslo, které má každý tým provozující agenty skutečně měřit a počítat s ním při návrhu, místo aby ho poprvé objevil během incidentu.

Jistič: limit útraty, který běhy skutečně zastaví

Řízení přístupu není jen o tom, co agent umí číst nebo měnit. Je také o tom, co to může stát — a agent, který se vymkl kontrole, nemusí sáhnout na nic citlivého, aby nadělal skutečnou škodu, když v nikým nesledované smyčce dělá drahá volání modelu.

Administrátoři na placených plánech FabricLoop nastaví měsíční limit útraty za použití agentů v Usage & Billing a mohou zapnout tvrdé zastavení, které automaticky pozastaví novou práci agentů, jakmile útrata dosáhne toho čísla. Je to skutečný jistič, ne monitorovací nástěnka: rozdíl mezi tím, že si na konci měsíce všimnete, že účet byl vysoký, a tím, že se nové běhy agentů samy zastaví v okamžiku, kdy překročí číslo, které někdo nastavil. Bezplatné pracovní prostory dolarový limit nedostanou, protože není produkční útrata, kterou by šlo omezit — běží na zahrnutých kreditech jen pro testy, což je samo o sobě limit rozsahu, jen vynucený jinak. Na placeném plánu je zvýšení limitu jediný způsob, jak po spuštění tvrdého zastavení pokračovat, a přesně to tření v tu chvíli chcete: někdo musí aktivně rozhodnout, že utratí víc, místo aby se systém tiše vrátil k neomezenému výchozímu stavu.

Audit a odvolání: jedna osoba, nebo všichni najednou

Poslední vrstva počítá s tím, že prvních pět někde, pro někoho, nakonec selže, a ptá se, co bude dál.

FabricLoop odděluje dva druhy odvolání a ten rozdíl je důležitý. „Odvolat mé spojení“ má k dispozici kdokoli a okamžitě odpojí jen přístup té osoby — nástroj pro ni přestane fungovat, aniž by se dotkl kohokoli dalšího v týmu, kdo je také připojený. „Vypnout aplikaci pro pracovní prostor“ je jen pro administrátory a je to širší akce: aplikaci celou archivuje a odvolá každé spojení k ní najednou, pro případ, kdy problém není účet jedné osoby, ale samotná aplikace. Stejné rozdělení je na příchozí straně, kde kdokoli může okamžitě odvolat klienta MCP, kterého připojil, z Nastavení → AI / MCP.

Nic z toho nehraje roli bez viditelnosti toho, co se stalo, než se někdo rozhodl vytáhnout zástrčku. Auditní protokoly Enterprise ve FabricLoop nejsou jen historie přihlášení — firma je popisuje jako pokrývající aktivitu administrátorů a agentů a vlastní materiály ke konceptu Legibility uvádějí „auditní události MCP“ konkrétně jako něco, co mohou bezpečnostní týmy zkontrolovat, ne jen odvodit z kontextu. To je rozdíl mezi tím, že se bezpečnostní tým zeptá „dotkl se toho někdo?“ a dostane skutečnou odpověď, a skládáním časové osy ze starých zpráv a něčí vzpomínky na to, co agent to odpoledne zdánlivě dělal.

Co podle FabricLoop zatím neplatí

Každé tvrzení výše je něco, co FabricLoop skutečně spustil. Stojí za to být stejně otevřený ohledně toho, co zatím hotové není, protože firma, která vám řekne jen první polovinu, žádá, abyste jí věřili naslepo — a slepá důvěra není to, co znamená transparentní bezpečnostní postoj.

Vlastní bezpečnostní stránka FabricLoop uvádí, co platí dnes, a pak samostatnou část, nadepsanou přímo „Zatím nezavedeno“, která jmenuje tři konkrétní mezery: certifikaci SOC 2 nebo ISO 27001, penetrační test třetí strany a automatické zřizování uživatelů přes SCIM. Pojetí stránky je na bezpečnostní stránku dodavatele nezvykle přímý: místo aby vyjmenovala každou certifikaci, kterou mají jiní dodavatelé, říká: tady je přesně to, co platí právě teď — a co zatím není zavedeno, protože firma to raději řekne napřímo, než aby to zákazník zjistil později.

Pro tým, který zvažuje, jestli agenta připojit ke skutečným firemním datům, to nejsou mlhavá rizika — jsou to tři pojmenované, ověřitelné body, které můžete vznést v bezpečnostní revizi, sledovat a vrátit se k nim před obnovením. Uvedený seznam mezer má větší cenu než mlhavé ujištění, že je všechno v pořádku, právě proto, že se dá ověřit. To je stejný argument za Legibility jako koncept: přístup a postoj, které umíte pojmenovat a ověřit, mají větší váhu než přístup a postoj, kterým máte prostě věřit.