Bezpieczeństwo agentów AI zaczyna się od małego oprogramowania

Matt Sephton opublikował Fits on a Floppy w kwietniu 2026 roku, przyjmując celowo absurdalne ograniczenie: użyteczne oprogramowanie powinno próbować zmieścić się w 1,44 MB, czyli pojemności standardowej dyskietki 3,5 cala.¹

Sam limit rozmiaru jest mniej ważny niż postawa, która za nim stoi. Sephton opowiada się za szybkim pobieraniem, natychmiastowym uruchamianiem, niskim zużyciem pamięci i CPU, kodem natywnym, obsługą starszych systemów oraz narzędziami, które dobrze robią jedną rzecz.¹ Oczywisty wniosek brzmi: małe oprogramowanie szanuje użytkownika. W epoce agentów wniosek idzie dalej: małe oprogramowanie daje agentom programistycznym AI mniej miejsc na ukrycie pomyłek.

Bezpieczeństwo agentów AI zaczyna się od małego oprogramowania, ponieważ małe, możliwe do sprawdzenia systemy zmniejszają przestrzeń, którą agent może źle zrozumieć, niechcący zmienić, błędnie autoryzować albo pominąć w testach. Sandboxy i monity o uprawnienia nadal są ważne. Małe oprogramowanie przesuwa jednak granicę bezpieczeństwa wcześniej, do samego kształtu artefaktu.

W skrócie

Agenci programistyczni działają najlepiej wtedy, gdy mogą przeczytać właściwe pliki, uruchomić właściwe kontrole i wyjaśnić właściwy diff, zanim kontekst zacznie się pogarszać. Wytyczne Anthropic dotyczące Claude Code wskazują, że kontekst szybko się zapełnia, a wydajność spada wraz z jego zapełnianiem; ten sam przewodnik nazywa weryfikację najcenniejszą praktyką i opisuje narzędzia CLI jako interfejsy oszczędzające kontekst.² Dokumentacja OpenAI dotycząca lokalnej powłoki ostrzega, że agenci uruchamiający polecenia powłoki potrzebują sandboxingu albo rygorystycznych list zezwoleń i blokad przed wykonaniem polecenia.³

Małe oprogramowanie nie zastępuje tych zabezpieczeń. Sprawia, że łatwiej je zastosować. Małe narzędzie ma mniej poleceń wymagających nadania uprawnień, mniej plików do sprawdzenia, mniej zależności, którym trzeba zaufać, mniej testów do uruchomienia i mniej rozgałęzień, w których może ukryć się błędne założenie. Dawna lekcja Unix się nie zestarzała: McIlroy wywodził zasadę „rób jedną rzecz” z wczesnych ograniczeń rozmiaru, a potem wyjaśniał, dlaczego strumienie tekstowe stały się użytecznymi uniwersalnymi interfejsami zarówno dla programów, jak i dla ludzi.⁴ Systemy agentowe odkrywają ten sam wzorzec na nowo, ponieważ agenci potrzebują powierzchni możliwych do sprawdzenia i komponowania.

Najważniejsze wnioski

Dla twórców agentów: - Zanim doda się szerokie API albo duże schematy narzędzi, warto wybierać małe narzędzia z jawnymi wejściami, jawnymi wyjściami i artefaktami w zwykłych plikach. - Ścieżki plików, diffy, logi i testy należy traktować jak powierzchnie bezpieczeństwa. Może je sprawdzić agent, może je sprawdzić recenzent, a automatyzacja może objąć je bramką jakości.

Dla zespołów tworzących oprogramowanie: - Małe oprogramowanie obniża koszt przeglądu. Recenzent może zrozumieć 400-wierszowe narzędzie i jego testy za jednym podejściem; rozrośnięty framework wymusza zaufanie tam, gdzie powinny istnieć dowody. - Zakres uprawnień powinien być blisko działania. Małe polecenie może działać tylko do odczytu, zapisywać jeden katalog albo mieć zablokowany dostęp do sieci. Ogólne polecenie zwykle prosi o szersze uprawnienia, niż wymaga zadanie.

Dla liderów produktu: - Małe oprogramowanie nie jest nostalgią. To wzorzec zarządzania w świecie, w którym maszyny potrafią produkować zbyt dużo kodu zbyt szybko. - Poprzeczka powinna przesunąć się z pytania „czy agent potrafi to zbudować?” na „czy zespół potrafi to zweryfikować, utrzymać i wycofać?”.

Dlaczego małe oprogramowanie znów stało się istotne

Rozrost oprogramowania kiedyś wyglądał przede wszystkim na problem UX: wolne pobieranie, duże zużycie pamięci, opóźniony start, rozładowane baterie i porzucone starsze urządzenia. Fits on a Floppy pokazuje tę krytykę przez celowo fizyczny standard. Odznaka 1,44 MB zamienia powściągliwość w test zrozumiały dla użytkownika.¹

Agenci programistyczni AI zmieniają powód, dla którego ta powściągliwość ma znaczenie. Maszyna potrafi produkować pliki szybciej, niż człowiek jest w stanie je czytać. Ta szybkość osłabia jakość, gdy otaczający system uznaje objętość za postęp. Funkcja na 2 000 wierszy z czterema nowymi zależnościami może wyglądać imponująco w zapisie rozmowy, a mimo to zwiększać powierzchnię defektów bardziej niż wartość produktu.

Małe oprogramowanie daje agentowi trudniejszy cel, a recenzentowi lepszy. Polecenie może wymagać jednego pliku wykonywalnego, jednego formatu danych, jednego pliku testów i jednej ścieżki wycofania. Wynik ma mniej stopni swobody. Model nadal może popełnić błąd, ale błąd ma mniej miejsca, by się zamaskować.

Niklaus Wirth opublikował artykuł A Plea for Lean Software w 1995 roku, na długo zanim agenci programistyczni weszli do przepływu pracy.⁵ Tytuł nadal działa, bo przetrwała ta sama podstawowa porażka: zespoły zużywają sprzęt, zależności i warstwy abstrakcji, aby uniknąć trudnych decyzji projektowych. Agenci obniżają cenę dodawania kodu, więc odmowa dodania kodu staje się cenniejsza.

Kontekst to budżet bezpieczeństwa

Bezpieczeństwo agentów często przedstawia się jako problem uprawnień: które polecenia agent może uruchamiać, które pliki może edytować, które sekrety może zobaczyć, które wywołania sieciowe może wykonać. Te pytania są ważne. Nie obejmują jednak pierwszego ograniczenia, na które agent trafia podczas pracy: kontekstu.

Przewodnik Anthropic po dobrych praktykach Claude Code mówi, że okno kontekstu mieści rozmowę, wiadomości, przeczytane pliki i wynik poleceń, a pojedyncze debugowanie może zużyć dziesiątki tysięcy tokenów.² Przewodnik ostrzega też, że Claude może zacząć zapominać wcześniejsze instrukcje albo popełniać więcej błędów, gdy okno kontekstu się zapełnia.²

To ostrzeżenie zmienia rozmiar we właściwość bezpieczeństwa. Mała baza kodu pozwala agentowi przeczytać istotną powierzchnię bez zalewania pracy nieistotnymi plikami. Małe narzędzie pozwala utrzymać jednocześnie w polu widzenia funkcję, testy, model uprawnień i przypadki brzegowe. Mały diff pozwala recenzentowi znaleźć faktyczną zmianę, zamiast przeczesywać stertę wygenerowanego ruchu.

Budżet kontekstu ma trzy praktyczne ograniczenia:

Duże systemy nadal mogą być bezpieczne. Potrzebują mocniejszego podziału. Jeśli baza kodu nie może być mała, mała powinna być powierzchnia widoczna dla agenta: jeden pakiet, jeden ograniczony podsystem, jedno publiczne polecenie, jeden cel testowy, jeden katalog pod wyraźną odpowiedzialnością.

Zwykłe pliki wygrywają z ukrytym stanem

Historia mówiona McIlroya nadaje starej lekcji ostre praktyczne znaczenie. Opisywał „rób jedną rzecz” jako zasadę zrodzoną z braku miejsca na robienie więcej niż jednej rzeczy, a potem mówił, że zespoły trzymały się tego wzorca także po zniknięciu pierwotnego ograniczenia.⁴ Wyjaśniał również, dlaczego strumienie tekstowe miały znaczenie: dane czytelne dla człowieka ułatwiały debugowanie, a rozwijanie pól tekstowych wymagało mniej pracy niż zmienianie stałych układów binarnych.⁴

Agenci potrzebują powierzchni tego samego rodzaju. Plik można wylistować, przeszukać, porównać diffem, przeczytać zakresami, zatwierdzić w Git, wycofać, sprawdzić linterem i zrecenzować. Ukryty stan IDE, nieprzejrzyste lokalne bazy danych i szerokie narzędzia hostowane mogą być użyteczne, ale zmuszają agenta i recenzenta do zaufania powierzchni, której nie da się łatwo sprawdzić.

Artykuł z arXiv ze stycznia 2026 roku łączy uniksową abstrakcję pliku z agentowymi systemami AI. Autor twierdzi, że abstrakcje podobne do plików i specyfikacje oparte na kodzie sprowadzają różnorodne zasoby do spójnych, komponowalnych interfejsów i mogą pomóc systemom agentowym stać się łatwiejszymi w utrzymaniu, audytowalnymi i solidnymi operacyjnie.⁶ Analiza Oracle dotycząca pamięci agentów wprowadza pokrewne rozróżnienie: interfejsy systemu plików działają dobrze, bo modele już rozumieją powierzchnie naturalne dla programistów, takie jak repozytoria, foldery, Markdown, logi i interakcje CLI, natomiast trwałe przechowywanie danych nadal może należeć do bazy danych.⁷

To rozróżnienie jest istotne. „Używać plików” nie znaczy „trzymać wszystko na zawsze w luźnym tekście”. Bezpieczniejszy wzorzec rozdziela interfejs agenta od warstwy przechowywania:

Agent powinien widzieć najmniejszy użyteczny interfejs. Produkt może mieć pod spodem mocniejszą warstwę przechowywania.

Mniej narzędzi oznacza mniej uprawnień

Artykuł o autoryzacji MCP pokazał lekcję autoryzacji wprost: sprawdzenie tokena bearer nie dowodzi, że użytkownik może wywołać każde narzędzie za serwerem.⁸ Małe oprogramowanie stosuje tę samą ideę wcześniej, już na etapie projektu. Mniejsze narzędzie prosi o węższe uprawnienia.

Dokumentacja OpenAI dotycząca lokalnej powłoki mówi o ryzyku jasno: uruchamianie dowolnych poleceń powłoki może być niebezpieczne, a twórcy powinni sandboxować wykonanie albo dodać rygorystyczne listy zezwoleń i blokad przed przekazaniem poleceń do powłoki systemowej.³ Przewodnik Anthropic dotyczący Claude Code podaje praktyczny przykład w większej skali: przy rozdzielaniu pracy na wiele plików należy stosować ograniczenia dozwolonych narzędzi, aby uruchomienia bez nadzoru nie mogły zrobić więcej, niż wymaga zadanie.²

Małe polecenie łatwiej ograniczyć:

Szerokie narzędzia mają skłonność do gromadzenia szerokich uprawnień. Ogólne polecenie „publish” może dotykać treści, tłumaczeń, wierszy bazy danych, czyszczenia pamięci podręcznej, logów wdrożenia i analityki. Czasem polecenie wydania jest potrzebne. Bezpieczniejszy wzorzec buduje wydanie z mniejszych poleceń, z jawnymi bramkami między nimi, a dopiero potem automatyzuje sekwencję, gdy każdy krok ma dowody.

Celem nie jest spowalnianie pracy. Celem jest uczynienie uprawnień widocznymi.

Testy powinny pasować do narzędzia

Pierwsza sekcja dobrych praktyk Anthropic mówi użytkownikom, aby dali Claude sposób weryfikacji pracy: testy, zrzuty ekranu, oczekiwane wyniki i kontrole poleceń.² Małe oprogramowanie czyni tę radę konkretną. Małe narzędzie może mieć mały kontrakt weryfikacyjny.

Dla oprogramowania zbudowanego przez agenta taki kontrakt powinien mieścić się na jednym ekranie:

Wejścia:
- jedna ścieżka źródłowa
- jedna ścieżka wyjściowa
- jedna opcjonalna flaga

Dozwolone skutki:
- odczyt ścieżki źródłowej
- zapis ścieżki wyjściowej
- brak sieci, chyba że obecna jest flaga --verify-sources

Dowody:
- testy jednostkowe parsowania
- test fikstury dla wyniku
- wynik dry-run dla dokładnego pliku
- git diff ograniczony do posiadanych ścieżek

Kontrakt jest ważny, bo agenci zbyt łatwo spełniają niejasne prośby. „Ulepsz pipeline” zaprasza do architektonicznego przemeblowania. „Dodaj flagę dry-run do tego jednego polecenia i udowodnij, że wynik nie zapisuje plików” tworzy ścieżkę dowodową.

Testy też stają się szybsze, gdy narzędzia pozostają małe. Szybkie testy zmieniają zachowanie agenta. Agent uruchamia je częściej, widzi awarie, gdy właściwy kod nadal mieści się w kontekście, i naprawia przyczyny źródłowe, zanim zapis rozmowy odpłynie. Wolne testy popychają model w stronę zgadywania albo opowiadania, co by uruchomił.

Małe nie znaczy niedobudowane

Małe oprogramowanie może zawodzić w przewidywalny sposób:

Odznaka dyskietki mierzy rozmiar. Bezpieczeństwo agentów potrzebuje innej miary: czy recenzent potrafi zrozumieć zachowanie, zakres uprawnień i ścieżkę dowodową przed zatwierdzeniem zmiany?

To pytanie pozwala narzędziu przekroczyć 1,44 MB. Odrzuca to, co naprawdę istotne: przypadkowy zakres. Bezpieczna, nudna aplikacja natywna o rozmiarze 20 MB może być lepsza niż skrypt 200 KB, który przez powłokę uruchamia niezrecenzowany instalator. Małe oprogramowanie służy bezpieczeństwu tylko wtedy, gdy powściągliwość obejmuje rzeczywistą ścieżkę wykonania.

Karta oceny małości dla pracy agentów

Zanim agent zbuduje albo zmodyfikuje narzędzie, warto ocenić pracę w pięciu wymiarach. Nie chodzi o karanie dużych systemów. Chodzi o znalezienie powierzchni, które trzeba podzielić, zanim agent zacznie pisać.

Czerwone pole nie znaczy, że praca ma się zatrzymać. Znaczy, że agent potrzebuje mniejszej jednostki pracy. Bezpieczeństwo rośnie, gdy kształt zadania ułatwia udowodnienie właściwego zachowania.

Praktyczny wzorzec

Najbezpieczniejsze systemy budowane przez agentów, którym ufam, mają wspólny kształt:

1. Jedno wąskie polecenie wykonuje jedno zadanie.
2. Zwykłe pliki przenoszą wejścia, wyjścia, logi, plany i pakiety do przeglądu.
3. Uprawnienia odpowiadają rzeczywistym skutkom polecenia.
4. Testy są na tyle szybkie, że agent może ich używać podczas pracy.
5. Diff pozostaje na tyle mały, że człowiek może go zrecenzować.
6. Ścieżka wydania składa małe polecenia, zamiast ukrywać szerokie uprawnienia za jednym przyciskiem.

Manifest bez procesu build: wysyłanie bez bundlera opisywał tę samą preferencję od strony stosu webowego: mniej warstw build, mniej wygenerowanych artefaktów i mniejszy dystans między źródłem a środowiskiem wykonawczym.⁹ Wersja dotycząca bezpieczeństwa agentów mówi to samo, tylko z myślą o innym czytelniku. Każda dodatkowa warstwa daje maszynie kolejne miejsce na wytworzenie wiarygodnie wyglądającej pracy, której człowiek nie może szybko zweryfikować.

Małe oprogramowanie zamienia powściągliwość w infrastrukturę. Węższy moduł poprawia dopasowanie do kontekstu. Prostszy plik poprawia audytowalność. Szybszy test poprawia informację zwrotną. Mniejszy zestaw uprawnień poprawia kontrolę promienia rażenia. Mniejszy diff wzmacnia ludzki osąd.

FAQ: małe oprogramowanie i bezpieczeństwo agentów

Czy małe oprogramowanie sprawia, że agenci programistyczni AI są bezpieczni?

Nie. Małe oprogramowanie zmniejsza obszar, który agenci mogą źle zrozumieć albo uszkodzić. Zespoły nadal potrzebują sandboxingu, list zezwoleń i blokad, testów, przeglądu kodu, granic poświadczeń i bramek wydania. Małe oprogramowanie sprawia, że te zabezpieczenia łatwiej zastosować i trudniej przypadkowo obejść.

Jak małe powinno być narzędzie widoczne dla agenta?

Użytecznym limitem jest możliwość przeglądu, nie liczba bajtów. Dobre narzędzie widoczne dla agenta ma jedno zadanie, mały kontrakt wejścia/wyjścia, jasny profil uprawnień, szybkie testy i diff, który recenzent potrafi zrozumieć za jednym podejściem.

Czy pamięć agenta powinna używać plików czy bazy danych?

Plików należy używać jako interfejsu wtedy, gdy agent musi sprawdzać, wyszukiwać, porównywać diffem i zapisywać artefakty. Bazy danych należy używać wtedy, gdy produkt potrzebuje współbieżności, indeksowania, kontroli dostępu, trwałości albo stanu między użytkownikami. Bezpieczniejsza architektura oddziela interfejs widoczny dla agenta od warstwy przechowywania.⁷

Gdzie pasuje MCP?

MCP pasuje tam, gdzie agent potrzebuje typowanego mostu do zewnętrznych narzędzi albo danych. MCP nie usuwa potrzeby małych poleceń, zawężonych uprawnień i autoryzacji na poziomie działania. Serwer nadal musi zdecydować, czy konkretny podmiot może wykonać konkretne działanie.⁸

Zakończenie

AI czyni kod tanim. Tani kod podnosi wartość odmowy.

Małe oprogramowanie nadaje odmowie formę, której maszyna może przestrzegać: jedno polecenie, jedno wyjście, jedna granica uprawnień, jedna ścieżka testów, jeden diff. Forma nie gwarantuje jakości. Sprawia jednak, że słaba praca staje się bardziej widoczna.

Dyskietka nie jest już ograniczeniem. Ograniczeniem jest możliwość sprawdzenia.

Źródła