Agent programistyczny może zwykle przestrzegać instrukcji repozytorium, a mimo to mieć więcej uprawnień, niż wymaga zadanie. Mozilla AI wskazuje tę lukę: pisemna intencja i technicznie wymuszone prawa to różne rzeczy. Lepszy model poprawia decyzje, ale nie tworzy automatycznie granicy, która przetrwa błędną decyzję.
Argument Mozilli dotyczy agentów przeglądających repozytoria, zmieniających pliki, wykonujących polecenia i testy oraz przygotowujących pull requesty. Delegowanie ściska pojedyncze kontrole człowieka w pętlę obserwacji, działania i poprawiania. Pytanie dotyczy więc nie tylko ilości pracy, lecz tego, co system powstrzyma, zapisze i potrafi odzyskać.
Instrukcje mają rolę, ale nie stanowią granicy wykonania
Trzeba oddzielić trzy odpowiedzialności: instrukcja opisuje zachowanie, model ją interpretuje, infrastruktura określa możliwe działania. Najpierw dając szeroki dostęp, a później prosząc o umiar, odwracamy hierarchię. Wykonawca staje się własnym głównym kontrolerem.
AGENTS.md rozwiązuje koordynację, umieszczając komendy budowania, testy, konwencje i kontekst bezpieczeństwa obok kodu. W opisywanym okresie strona formatu podawała ponad 60 000 projektów open source. Wspólne, wersjonowane wskazówki są przenośne między produktami, a zagnieżdżone pliki opisują wymagania usług w dużych repozytoriach.
Agent nadal musi znaleźć plik, rozstrzygnąć nakładanie reguł, zastosować je i pamiętać długo. Braki, ucięty kontekst, sprzeczne instrukcje podrzędne albo zbyt szeroki wyjątek osłabiają łańcuch. Sam Markdown nie ogranicza powłoki, sieci, konta chmurowego, rejestru pakietów ani produkcyjnej bazy.
„Nie publikuj z gałęzi funkcji”, „zmiana uwierzytelniania wymaga zgody” czy „czytaj tylko ten katalog” wyrażają zamiar. Granice plików, reguły sieci i usługi zatwierdzania egzekwują ograniczenia. Nie umniejsza to instrukcjom: wiele decyzji potrzebuje kontekstu niewyrażalnego prostą regułą systemu plików. Warstwy mają inne zadania.
Użyteczna autonomia zwiększa skutki zwykłej pomyłki
Naprawa testu integracyjnego może prowadzić do plików środowiskowych, uruchomienia usług, instalacji zależności i nowych snapshotów. Niejasne zadanie rozszerza zakres. Nie potrzeba złej woli: niszczące czyszczenie może wyglądać jak konserwacja, poświadczenie jak jednorazowe, a tekst zgłoszenia lub zależności jak zaufana wskazówka.
Prompt injection zaostrza problem, ukrywając wrogie instrukcje w danych. Ostrzeżenia językowe pomagają, lecz ten sam model ocenia zaufanie do innego tekstu. Zewnętrzna granica ogranicza skutki błędnego osądu.
Architektura piaskownicy przywołana w źródle oddziela zaufany harness od środowiska poleceń sterowanych przez model. Zgody, ślady, odzyskiwanie i stan mogą pozostać poza kontenerem. Wykonawca nie dziedziczy automatycznie wszystkich poświadczeń i zasobów organizacji.
Dokumentacja nie wymaga kluczy publikowania pakietów, naprawa jednej usługi obcych repozytoriów, a testy dostępu do bazy produkcyjnej. To dozwolone zdolności środowiska i osiągalne zasoby, nie tylko dobór promptu. Lokalny laptop również może przechowywać kod, sesje przeglądarki, chmurę, dokumenty prywatne i klucze podpisu. Jedno nadmierne poświadczenie wystarczy bez praw administratora.
Jakość kontroli staje się częścią produktu, nie ukrytym szczegółem. Zespoły platformowe i bezpieczeństwa muszą umożliwić delegację bez nieograniczonej władzy. Dostawcy i indywidualni programiści mierzą się z tożsamością, zgodami, logami i odzyskiwaniem, na które benchmark modelu nie odpowiada.
Polityka i autoryzacja poza narracją modelu
Zaufana warstwa kontroli zarządza dostępem, routingiem, budżetem, regułami i stanem. Model proponuje, inna warstwa decyduje o wykonaniu. Tożsamości konkretnych uruchomień odróżniają agentów od człowieka i innych automatyzacji. Prawa do wskazanych plików, poleceń, usług i celów sieciowych powinny wygasać z zadaniem, nie kumulować się.
Źródłowe wytyczne bezpieczeństwa piaskownic opisują izolację, ograniczone wyjście sieciowe, rozdzielone poświadczenia i pośrednictwo. Zaufany proxy dodaje je tylko dla dozwolonych celów, więc wykonanie nie musi widzieć sekretu wielokrotnego użytku. Wypisanie środowiska nie musi ujawnić długotrwałego klucza produkcyjnego; odebranie dostępu następuje u pośrednika, nie w każdym obszarze pracy.
Pośrednictwo narzędzi sprawdza argumenty, odrzuca niebezpieczne ścieżki, ogranicza tempo i wymaga zgody. Wtyczki polityk mcpd Mozilli umieszczają uwierzytelnianie, walidację, limity i logi między agentem a serwerem. Ponieważ Model Context Protocol udostępnia pliki, bazy i zewnętrzne aplikacje, pośrednik może egzekwować spójnie bez zaufania, że każdy agent odtworzy regułę.
Zgoda potrzebuje też uprawnionej tożsamości i stanu zewnętrznego, którego model nie wymyśli. Wiadomość w kontekście może być naśladowana przez niezaufaną treść. „Oszczędzaj tokeny” jest radą; wymuszony budżet pozostaje sufitem przy długiej pętli. Podagenci mogą wydawać szybciej niż człowiek obserwujący czat, uzasadniając limity zadania, zespołu, dostawcy lub wyniku.
Nie każdy krok wymaga zgody. Odczyt i zapis w tymczasowej gałęzi mogą być rutyną, publikacja, wdrożenie, prawa i kontakt z klientami wymagać autoryzacji. Polecenie dozwolone w izolowanym teście może być zabronione produkcyjnie; dokumentacja sieciowa dozwolona, nieznane adresy blokowane. Ciągłe przerywanie małego ryzyka szkodzi delegacji, brak bramek zostawia poważne decyzje modelowi.
Audyt i odzyskiwanie muszą obsługiwać pracę nieukończoną
Wyjaśnienie agenta nie jest pełnym zapisem wejść, praw, zmian, ponowień i odmów. Audyt powinien niezależnie wiązać działanie z uruchomieniem, wersjami polityki i narzędzia, zgodą, tożsamością, wejściem oraz wynikiem. Trzy zakazane próby przed poprawną drogą to coś innego niż natychmiastowy poprawny wybór.
Po incydencie reguły lub poświadczenia mogły się zmienić. Dawny zapis pozwala odtworzyć stan, a także wykryć powtarzane interwencje, fałszywe alarmy i przekroczenia zakresu. Transkrypt czy wynik końcowy nie wystarczą do odtworzenia ówczesnej władzy.
Stan jest równie istotny. Działanie zewnętrzne może się udać przed awarią zapisu sukcesu. Ponowienie całości może powielić pull request, płatność lub wiadomość. Infrastruktura musi oddzielać ukończone kroki, bezpieczne ponowienia i potrzebę uzgodnienia stanu. Skutek zewnętrzny nie jest tym samym co powtarzalny odczyt lokalny.
Otari łączy zarządzanie z routingiem, budżetem, dostępem, wdrożeniem i przełączaniem awaryjnym między dostawcami. Routing dotyczy też prywatności, opóźnień i zdolności, nie tylko kosztu. Oddzielenie tych decyzji od rozproszonego kodu pomaga zachować reguły, ślady i stan przy zmianie modelu lub środowiska.
Wiedza informuje, polityka ogranicza, audyt zapisuje, odzyskiwanie obsługuje resztę. Agent staje się wymiennym komponentem systemu kontrolowanego przez organizację, nie jedynym magazynem jej reguł.
Otwarta własność przynosi obowiązki operacyjne
Sprawdzalny stos ogranicza uzależnienie, pozwala dodawać integracje i utrzymywać wrażliwe elementy u siebie. Szpitale, banki, urzędy i zespoły software potrzebują różnych zgód i retencji; jeden domyślny hosting nie obejmie wszystkiego. Otwartość jest modelem własności, nie automatycznym bezpieczeństwem.
Własny hosting wymaga aktualizacji, przeglądów dostępu, kopii, monitoringu i sprawdzonego odzyskiwania. Stare składniki, liberalne ustawienia, wspólne poświadczenia, niepełne logi i otwarta sieć pozostają słabościami publicznego kodu. Bogate ślady mogą zawierać kod własnościowy, dane osobowe, prompty i wyniki. Retencja ma ustalić odpowiedzialność bez trwałego kopiowania każdej wrażliwej treści.
Więcej reguł nie zawsze pomaga. Nakładające wyjątki tworzą luki, nadmierne ograniczenia pchają ku niezatwierdzonym narzędziom, niejawna polityka centralna rodzi własny problem władzy. Małe, testowalne kontrole potrzebują opiekunów, powodów i weryfikacji. Zmiany wymagają przeglądu, testów i wersjonowania; wyjątki awaryjne powinny wygasać, pozostać widoczne i mieć zrozumiałe procedury odmowy oraz odstępstwa.
Infrastruktura nie gwarantuje użytecznego kodu. Agent może przestrzegać praw i błędnie implementować lub pominąć wymóg. Testy i człowiek pozostają potrzebni, w tym prywatne albo niezależne przypadki ujawniające optymalizację pod widoczne kontrole oraz przegląd opiekunów kodu przy wrażliwych zmianach. Szczegółowy log dowodzi przebiegu incydentu, nie skutecznej prewencji.
Tezę sprawdzą tymczasowe prawa zadania, trwałe dowody działań i uprawnień oraz ich przenośność przy zmianie modeli. Liczą się też codzienne utrudnienia. Lepsze rozumowanie jest wartościowe; niezawodna delegacja potrzebuje granic, które nie znikną, gdy ono zawiedzie.
Dodatkowo: techniczne bazy wiedzy i zachowanie kontekstu inżynieryjnego.