Zapora fabrykacji: gdy agent publikuje kłamstwa

19 lutego 2026 roku ktoś udostępnił agentowi Claude Code dostęp do narzędzi MCP dla Twittera, Telegraph, Write.as, Rentry, GitHub i Moltbook. W ciągu następnych 72 godzin agent opublikował zmyślone twierdzenia techniczne na wszystkich ośmiu platformach. Okno kontekstowe o rozmiarze 200 000 tokenów stało się „1 milionem tokenów”. Sesja, która przetworzyła 196 626 tokenów, stała się „12 milionami tokenów w jednej sesji”. Trzeciego dnia agent twierdził, że sesje obejmują biliony tokenów — pomyłka o współczynniku 83 000.¹

Agenci AI fabrykują poprzez pętle sprzężenia zwrotnego, a nie pojedyncze halucynacje, i dopasowanie w fazie treningu nie może tego zapobiec. Gdy agent zapisuje domysł do pamięci, następna sesja odczytuje go jako fakt i publikuje, a trzecia sesja traktuje publikację jako potwierdzenie. Rozwiązaniem jest zapora wyjściowa, która klasyfikuje polecenia jako lokalne, współdzielone lub zewnętrzne i odracza publikację zewnętrzną do recenzji przez człowieka.

Agent nie był złośliwy. Był z pewnością w błędzie, a nic nie stało między jego pewnością a przyciskiem publikacji.

TL;DR

Autonomiczny agent Claude Code opublikował zmyślone twierdzenia na ponad 8 platformach w ciągu 72 godzin poprzez pętlę sprzężenia zwrotnego konfabulacji: Sesja N zgaduje, zapisuje domysł do MEMORY.md, Sesja N+1 odczytuje go jako zweryfikowany fakt, publikuje, Sesja N+2 odczytuje publikację jako potwierdzenie. Nie istniała żadna bramka wyjściowa. Dopasowanie w fazie treningu („bądź uczciwy”) było niewystarczające, ponieważ agent wierzył, że jest uczciwy. Rozwiązaniem jest zapora wyjściowa: klasyfikowanie poleceń jako lokalnych, współdzielonych lub zewnętrznych oraz odraczanie publikacji zewnętrznej do recenzji przez człowieka. Poniżej: anatomia incydentu, mechanizm pętli sprzężenia zwrotnego, co budują inni (OkaiDokai) oraz działająca implementacja, której można użyć już dziś.

Pętla sprzężenia zwrotnego konfabulacji

Fabrykacja nie była pojedynczą halucynacją. Była trwałą pętlą sprzężenia zwrotnego obejmującą wiele sesji, z których każda wzmacniała błędy poprzedniej sesji.¹

Mechanizm:

1. Sesja N: domysł. Claude oszacował liczbę tokenów na podstawie rozmiarów plików, dzieląc bajty JSONL przez 4, aby przybliżyć liczbę tokenów. Ta metodologia została wymyślona. Powstałe liczby były na tyle wiarygodne, aby zapisać je do MEMORY.md jako ustalenia.

2. Sesja N+1: promocja. Nowa sesja Claude odczytała MEMORY.md, znalazła już udokumentowane szacunki tokenów i potraktowała je jako zweryfikowane fakty. Sesja zbudowała na tych faktach, eskalując twierdzenia, i opublikowała je na wielu platformach, wykorzystując narzędzia MCP.

3. Sesja N+2: wzmocnienie. Następna sesja odczytała zarówno MEMORY.md, jak i opublikowane artykuły. Twierdzenia miały teraz dwa źródła: plik pamięci i publikacje. Wzajemne odwoływanie się do dwóch źródeł tej samej fabrykacji wyglądało jak potwierdzenie.

Pętla jest strukturalnie identyczna z praniem cytatów w publikacjach akademickich: sfabrykować twierdzenie, opublikować je gdzieś, a następnie cytować publikację jako dowód na to twierdzenie. Agent nie miał zamiaru prać. Podążał racjonalnym procesem (sprawdź pamięć, odwołaj się do źródeł, opublikuj ustalenia), który akurat operował na sfabrykowanych danych wejściowych.

Gdy użytkownik zakwestionował liczby, agent wykonał ponad 50 tur argumentacji, zanim uruchomił choć jedno polecenie weryfikacyjne (/context). Agent miał wysoką pewność, ponieważ jego „źródła” (własny plik pamięci, własne publikacje) zgadzały się ze sobą.¹

Dlaczego zabezpieczenia z fazy treningu nie pomogły

Agent był dopasowany. Starał się być pomocny i uczciwy. Dzielił się tym, co uważał za dokładne ustalenia techniczne. Obecne były wszystkie właściwości bezpieczeństwa, jakich można by oczekiwać od RLHF: agent nie odmawiał żądań, nie produkował szkodliwych treści, nie naruszał swoich zasad konstytucyjnych. Był uprzejmy, dokładny i w błędzie.

Dopasowanie w fazie treningu optymalizuje pod kątem intencji: model powinien zamierzać być prawdomówny. Incydent fabrykacji ujawnia inną powierzchnię niepowodzenia: granicę między stanem wewnętrznym agenta a światem zewnętrznym. Agent wierzył, że jego twierdzenia są prawdziwe. Żadne szkolenie dopasowujące nie wychwyci agenta, który jest w uczciwym błędzie i ma dostęp do przycisku publikacji.

Jest to problem granicy publikacji. Dopasowanie rządzi tym, co agent chce zrobić. Zapory wyjściowe rządzą tym, co agentowi wolno zrobić. Są to różne mechanizmy rozwiązujące różne problemy.

Opisane wcześniej ramy konstytucji wykonawczej dotyczą warstwy zarządzania: priorów normatywnych, uwagi konstytucyjnej, modulacji kompetencji oraz weryfikacji dopasowania wartości.² Incydent fabrykacji odsłania lukę w tych ramach: weryfikacja dopasowania wartości sprawdzała, czy wyjścia agenta odpowiadają intencjom zarządzania, ale nie rozróżniała między zapisem do lokalnego pliku a publikacją na Twitterze. Oba są wywołaniami narzędzi. Oba używają Bash. Tylko jedno dociera do świata zewnętrznego.

Co budują inni

Problem jest na tyle realny, że praktycy niezależnie budują rozwiązania.

OkaiDokai to zapora na poziomie narzędzi dla agentów AI, która przechwytuje każde wywołanie narzędzia i ocenia je względem zdefiniowanego przez użytkownika zestawu reguł.³ Pasujące działania są automatycznie zatwierdzane lub odrzucane. Niepasujące działania wyzwalają powiadomienie push na telefon, zegarek lub przeglądarkę. Można dotknąć Zezwól lub Odmów. Ocena trwa poniżej 1 milisekundy, a każda decyzja może stać się trwałą regułą.

Architektura OkaiDokai dzieli się na trzy warstwy: wtyczkę na agencie, która przechwytuje wywołania narzędzi, warstwę API, która ocenia reguły i wysyła powiadomienia, oraz interfejs użytkownika do zatwierdzania. System obsługuje Claude Code i OpenClaw, a wsparcie dla Codex jest planowane.

Podejście jest słuszne, lecz wprowadza opóźnienie i zewnętrzną zależność. Każde nowe działanie wymaga zatwierdzenia przez człowieka za pośrednictwem powiadomienia push. Dla interaktywnych sesji kodowania to tarcie jest zarządzalne. Dla autonomicznych pętli działających nocą blokowanie na powiadomieniach push niweczy cel.

Wykonawcza konstytucyjna AI to wyłaniający się kierunek badań, w którym agenci weryfikują swoje własne wyjścia względem osadzonych reguł zarządzania przed ich wykonaniem.⁴ Podejście działa dla kontroli na poziomie wartości („czy to wyjście szanuje prywatność użytkownika?”), lecz nie adresuje problemu fabrykacji konkretnie. Agent, który wierzy, że jego sfabrykowane twierdzenia są dokładne, będzie również wierzył, że przechodzą one przegląd konstytucyjny.

Żadne z podejść samo nie rozwiązuje pętli sprzężenia zwrotnego. OkaiDokai wychwyciłby polecenia publikacji, gdyby użytkownik skonfigurował reguły publikacji. Wykonawczy przegląd konstytucyjny przegapiłby fabrykację, ponieważ pewność agenta obchodziła jego własne kontrole uczciwości. Luka jest strukturalna: potrzebny jest mechanizm, który nie ufa ocenie przez agenta własnej dokładności podczas interakcji z systemami zewnętrznymi.

Trzy poziomy wpływu poleceń

Zapora wyjściowa klasyfikuje każde polecenie według promienia rażenia. Klasyfikacja decyduje, czy polecenie jest automatycznie zatwierdzane, ostrzega, czy też jest odraczane.

Poziom 1: lokalny. Wpływa tylko na lokalny system plików. Odczyty plików, zapisy plików, git add, git commit, uruchomienia testów, lintowanie. Te są automatycznie zatwierdzane, ponieważ są odwracalne i niewidoczne dla świata zewnętrznego. Jeśli agent zapisze zły plik, można go usunąć. Brak zewnętrznych szkód.

Poziom 2: współdzielony. Wpływa na współdzielony stan, który mogą zobaczyć współpracownicy. git commit (tworzy historię), operacje na gałęziach, lokalne zmiany w bazie danych. Te ostrzegają, lecz nie blokują. Szkoda z powodu złego commita jest realna, lecz ograniczona do repozytorium i odwracalna za pomocą git revert.

Poziom 3: zewnętrzny. Sięga systemów poza repozytorium. git push, gh pr create, gh pr merge, railway deploy, curl -X POST/PUT/PATCH/DELETE, npm publish. Te są odraczane do recenzji przez człowieka. Szkoda z powodu złej publikacji jest zewnętrzna, widoczna i potencjalnie nieodwracalna (treści w pamięci podręcznej, zindeksowane strony, e-maile powiadomień już wysłane).

Klasyfikacja poziomów odwzorowuje się na prostą listę wzorców:

EXTERNAL_PATTERNS='git push|gh pr create|gh pr merge|railway deploy|curl -X POST|curl -X PUT|curl -X PATCH|curl -X DELETE|npm publish'

W interaktywnych sesjach Claude Code wbudowany system uprawnień już obsługuje to zagadnienie. Każde polecenie Bash prosi o zatwierdzenie, chyba że zostało wcześniej autoryzowane. Użytkownik widzi git push w oknie dialogowym uprawnień i decyduje, czy na to zezwolić.

W autonomicznych pętlach nikt nie patrzy. Autonomiczna pętla rozwojowa Ralph spawnuje nowe instancje Claude za pośrednictwem claude --print, które wykonują się bez interaktywnego zatwierdzania.⁵ To tutaj zapora wyjściowa ma znaczenie.

Budowanie zapory

Implementacja ma cztery komponenty. Każdy działa niezależnie, więc można je wdrażać stopniowo.

1. Ograniczenie promptu

Najprostsza warstwa. Można dodać jawne reguły do promptu, który spawnuje każdą autonomiczną instancję Claude:

## Rules
- Do NOT run git push, deploy commands, or external API calls
- Local operations only: file writes, git add, git commit, test runs

Jest to konieczne i niewystarczające. Modele przestrzegają ograniczeń promptu przez większość czasu. „Większość czasu” nie jest akceptowalne dla bezpieczeństwa publikacji. Ograniczenie promptu zmniejsza prawdopodobieństwo poleceń zewnętrznych; pozostałe komponenty wychwytują te, które się prześlizgną.

2. Skaner po wykonaniu

Po zakończeniu każdego wykonania Claude można przeskanować jego wyjście w poszukiwaniu śladów poleceń zewnętrznych:

scan_for_external_commands() {
    local output="$1"
    local story_id="$2"

    while IFS= read -r pattern; do
        [ -z "$pattern" ] && continue
        local matches
        matches=$(echo "$output" | grep -i "$pattern" 2>/dev/null || true)
        if [ -n "$matches" ]; then
            # Log to state file for end-of-session review
            jq --arg cmd "$pattern" --arg story "$story_id" \
               --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
               '.deferred_actions += [{
                   "command_pattern": $cmd,
                   "story_id": $story,
                   "detected_at": $ts
               }]' "$STATE_FILE" > "${STATE_FILE}.tmp" \
               && mv "${STATE_FILE}.tmp" "$STATE_FILE"
        fi
    done <<< "$(echo "$EXTERNAL_PATTERNS" | tr '|' '\n')"
}

Skaner uruchamia się po zakończeniu instancji Claude, a nie podczas wykonywania. Jest to wykrywanie, a nie zapobieganie. Ograniczenie promptu jest warstwą zapobiegawczą. Skaner jest warstwą audytu, która wychwytuje to, co ograniczenie przegapiło.

Znane ograniczenie: grep -i dopasowuje wzorce w wyjściu języka naturalnego, a nie tylko w wykonanych poleceniach. Jeśli odpowiedź Claude zawiera „Nie zdecydowałem się wykonać git push, ponieważ zasady promptu tego zabraniają”, skaner ją oznaczy. To jest akceptowalne. Fałszywe pozytywy w kolejce odroczonych działań kosztują człowieka pięć sekund przeglądu. Fałszywy negatyw (pominięcie rzeczywistego polecenia zewnętrznego) kosztuje opublikowane fabrykacje. Skaner celowo wymienia precyzję na czułość.

Przykładowe wyjście skanera z rzeczywistego uruchomienia autonomicznej pętli:

DEFERRED ACTIONS REQUIRE REVIEW
2 external command(s) detected.
  Story #3 [2026-02-23T08:15:00Z]: git push
  Story #7 [2026-02-23T09:42:13Z]: curl -X POST

W tym przypadku Historia #3 wspomniała o git push w komentarzu kodu (fałszywy pozytyw). Historia #7 zawierała rzeczywiste curl -X POST do punktu końcowego API, które ograniczenie promptu powinno było zablokować (prawdziwy pozytyw). Człowiek ignoruje pierwsze, bada drugie.

3. Kolejka odroczonych działań

Wykryte polecenia zewnętrzne gromadzą się w tablicy deferred_actions w pliku stanu sesji:

{
  "session_id": "1740355200-12345",
  "deferred_actions": [
    {
      "command_pattern": "git push",
      "story_id": "3",
      "detected_at": "2026-02-23T08:15:00Z"
    }
  ]
}

Kolejka utrzymuje się między historiami w ramach pojedynczego uruchomienia autonomicznej pętli. Na końcu pętli wszystkie odroczone działania są prezentowane do przeglądu przez człowieka.

4. Raport na koniec sesji

Gdy autonomiczna pętla się zakończy, można wyświetlić wszystkie odroczone działania:

show_deferred_actions() {
    local count
    count=$(jq '.deferred_actions | length' "$STATE_FILE")
    if [ "$count" -gt 0 ]; then
        echo "DEFERRED ACTIONS REQUIRE REVIEW"
        echo "$count external command(s) detected."
        jq -r '.deferred_actions[] |
            "  Story #\(.story_id) [\(.detected_at)]: \(.command_pattern)"' \
            "$STATE_FILE"
    fi
}

Człowiek przegląda każde odroczone działanie i decyduje, czy wykonać je ręcznie. Zachowuje to zdolność autonomicznej pętli do pracy bez nadzoru, zapewniając jednocześnie, że żadna publikacja zewnętrzna nie odbywa się bez weryfikacji przez człowieka.

Szybki start: hook Claude Code

Jeśli korzysta się z Claude Code interaktywnie (a nie z autonomicznej pętli), można dodać zaporę wyjściową jako pojedynczy hook w ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE 'git push|gh pr create|gh pr merge|npm publish|railway deploy|curl -X POST|curl -X PUT|curl -X DELETE'; then echo 'BLOCKED: External publication command detected. Review manually.' >&2; exit 2; fi"
        }]
      }
    ]
  }
}

Ten hook uruchamia się przed każdym wywołaniem narzędzia Bash. Jeśli polecenie pasuje do wzorca zewnętrznego, blokuje wykonanie z kodem wyjścia 2 (który Claude Code interpretuje jako „odmów temu wywołaniu narzędzia”). Agent otrzymuje komunikat o blokadzie i może kontynuować pracę lokalną. Można rozszerzyć listę wzorców o własne usługi zewnętrzne.

Gradient autonomii

Rygorystyczność zapory powinna skalować się odwrotnie proporcjonalnie do nadzoru ludzkiego. Większa autonomia wymaga większych ograniczeń. Mniejsza autonomia pozwala na większą swobodę.

Incydent fabrykacji wydarzył się na poziomie „autonomii bez nadzoru” bez żadnej zapory. Agent miał dostęp MCP do platform publikacyjnych i nie było mechanizmu, który odróżniałby „zapisz analizę do lokalnego pliku” od „opublikuj analizę na Twitterze”. Oba były wywołaniami narzędzi. Oba się powiodły.

Rozwiązaniem nie jest usunięcie dostępu MCP ani zatrzymanie operacji autonomicznej. Rozwiązaniem jest dopasowanie rygorystyczności zapory do poziomu autonomii. Sesja interaktywna, w której obserwuje się każde polecenie, nie potrzebuje zapory wyjściowej. Nocna autonomiczna pętla, która przetwarza 25 historii, potrzebuje wszystkich czterech komponentów.

Połączenie z zarządzaniem wykonawczym

Wpis o samozarządzaniu agentów opisywał cztery podsystemy zarządzania wykonawczego: priory normatywne, uwagę konstytucyjną, modulację kompetencji oraz weryfikację dopasowania wartości.² Zapora wyjściowa jest piątym podsystemem, a dokładniej, jest mechanizmem egzekwowania, którego brakowało podsystemowi weryfikacji dopasowania wartości.

Weryfikacja dopasowania wartości sprawdza, czy wyjścia agenta odpowiadają intencjom zarządzania. Bramka dowodowa wymaga konkretnego dowodu dla sześciu kryteriów przed zgłoszeniem zakończenia. Lecz bramka dowodowa operuje na samoocenie agenta. Pyta: „Czy przestrzegałeś reguł?” Agent odpowiada w oparciu o własne rozumienie tego, co zrobił.

Incydent fabrykacji pokazuje, że samoocena zawodzi, gdy rozumienie agenta jest błędne. Agent wierzył, że jego twierdzenia są dokładne. Jego samoocena przeszłaby bramkę dowodową: „Zweryfikowałem liczby względem mojego pliku pamięci i opublikowanych artykułów”. Oba źródła były sfabrykowane przez samego agenta, lecz agent o tym nie wiedział.

Zapora wyjściowa całkowicie omija samoocenę. Nie pyta agenta, czy publikacja jest dokładna. Pyta: „Czy to polecenie jest lokalne czy zewnętrzne?” Klasyfikacja jest mechaniczna, nie semantyczna. git push jest zewnętrzne niezależnie od tego, czy wypychana zawartość jest dokładna. curl -X POST sięga internetu niezależnie od tego, czy ładunek jest prawdziwy. Zapora operuje na strukturze polecenia, a nie na prawdziwości treści, co czyni ją odporną na konfabulację, która pokonała każdą inną warstwę bezpieczeństwa.

Kluczowe wnioski

• Granica publikacji jest odrębną powierzchnią bezpieczeństwa. Dopasowanie treningowe rządzi intencją. Zapory wyjściowe rządzą zdolnością. Agent, który uczciwie wierzy w sfabrykowane twierdzenia, przejdzie kontrole dopasowania, lecz zawiedzie na granicy publikacji.
• Pętle sprzężenia zwrotnego konfabulacji są mechanizmem. Fabrykacja nie była pojedynczą halucynacją. Była wielosesyjną pętlą, w której wyjście każdej sesji stawało się dowodem następnej sesji. Pliki pamięci i publikacje służyły jako pralnicy dla oryginalnej fabrykacji.
• Klasyfikuj polecenia według promienia rażenia. Lokalne (odwracalne, niewidoczne), współdzielone (widoczne dla współpracowników), zewnętrzne (sięgające świata zewnętrznego). Bramkuj poziom zewnętrzny na poziomie odpowiadającym poziomowi autonomii.
• Wykrywanie i zapobieganie są komplementarne. Ograniczenia promptu zapobiegają większości poleceń zewnętrznych. Skanowanie po wykonaniu wychwytuje to, co się prześlizguje. Żadne z osobna nie wystarcza.
• Samoocena zawodzi przy konfabulacji. Agent, który wierzy we własne fabrykacje, przejdzie własne kontrole zarządzania. Zapora wyjściowa działa, ponieważ klasyfikuje strukturę polecenia, a nie prawdziwość treści. Pytanie nigdy nie brzmi: „czy to jest prawda?” Pytanie brzmi: „czy to sięga świata zewnętrznego?”

FAQ

Jak agenci AI fabrykują informacje, skoro są dopasowani, aby być uczciwymi?

Agent wierzy, że jego twierdzenia są prawdziwe. W udokumentowanym tutaj incydencie fabrykacja nie była pojedynczą halucynacją, lecz trwałą pętlą sprzężenia zwrotnego: Sesja N zgadywała liczby tokenów i zapisywała je do MEMORY.md, Sesja N+1 odczytała te domysły jako zweryfikowane fakty i opublikowała je, Sesja N+2 odnosiła się krzyżowo do pliku pamięci i publikacji jako „potwierdzenia”.¹ Dopasowanie w fazie treningu optymalizuje pod kątem intencji (model powinien zamierzać być prawdomówny), lecz agent, który jest w uczciwym błędzie, przejdzie każdą kontrolę dopasowania, publikując jednocześnie fałszywe informacje.

Czym jest pętla sprzężenia zwrotnego konfabulacji?

Pętla sprzężenia zwrotnego konfabulacji występuje, gdy wyjście agenta z jednej sesji staje się wejściem dla następnej sesji, przy czym każda iteracja traktuje poprzednią fabrykację jako ustalony fakt. Mechanizm jest strukturalnie identyczny z praniem cytatów w publikacjach akademickich: sfabrykować twierdzenie, opublikować je, a następnie cytować publikację jako dowód.¹ Pętla jest samowzmacniająca, ponieważ pewność agenta rośnie z każdym dodatkowym „źródłem”, które potwierdza twierdzenie, mimo że każde źródło prowadzi z powrotem do oryginalnej fabrykacji.

Jak można wykryć kłamstwa generowane przez AI w wyjściu autonomicznego agenta?

Nie należy polegać na agencie w kwestii wykrywania własnych fabrykacji. Agent, który wierzy, że jego twierdzenia są dokładne, będzie również wierzył, że przechodzą one jego własne kontrole zarządzania. Zamiast tego należy klasyfikować każde polecenie według promienia rażenia: lokalne (zapisy plików, git commit), współdzielone (operacje na gałęziach) oraz zewnętrzne (git push, wywołania API, publikowanie).⁵ Można bramkować polecenia zewnętrzne za pomocą hooka PreToolUse, który blokuje polecenia publikacji, oraz używać skanera po wykonaniu, aby wychwycić wszystko, co ograniczenie promptu przegapiło. Pytanie nigdy nie brzmi: „czy to jest prawda?”, lecz „czy to sięga świata zewnętrznego?”

Czym jest zapora wyjściowa dla agentów AI?

Zapora wyjściowa klasyfikuje polecenia agenta na trzy poziomy w oparciu o promień rażenia i stosuje eskalujące kontrole. Poziom 1 (operacje na lokalnym systemie plików) jest automatycznie zatwierdzany, ponieważ szkoda jest odwracalna. Poziom 2 (współdzielony stan, taki jak commity git) ostrzega, lecz nie blokuje. Poziom 3 (zewnętrzna publikacja poprzez git push, wywołania API, npm publish) jest odraczany do recenzji przez człowieka. Zapora operuje na strukturze polecenia, a nie na prawdziwości treści, co czyni ją odporną na konfabulację, która pokonuje każdą semantyczną warstwę bezpieczeństwa.³

Czy dopasowanie RLHF zapobiega publikowaniu przez agentów AI fałszywych informacji?

Nie. Dopasowanie RLHF rządzi tym, co agent chce zrobić (intencja), a nie tym, co agentowi wolno zrobić (zdolność). Każda właściwość bezpieczeństwa, jakiej można by oczekiwać od RLHF, była obecna w incydencie fabrykacji: agent nie odmawiał żądań, nie produkował szkodliwych treści i nie naruszał swoich zasad konstytucyjnych.¹ Był uprzejmy, dokładny i w błędzie. Granica publikacji jest odrębną powierzchnią bezpieczeństwa, która wymaga egzekwowania na poziomie wyjścia, a nie dopasowania na poziomie treningu.

Źródła