weryfikuj, nie ufaj

Przekonaj się. Zaatakuj sam.

Każde twierdzenie w tym serwisie ma na tej stronie przycisk podłączony do prawdziwego, działającego systemu: bazy danych na żywo z zabezpieczeniami na poziomie wierszy, prawdziwej kolejki zatwierdzeń, prawdziwego wyłącznika awaryjnego. To nie są nagrania.

01, izolacja tenantów

🔒 klejnot w koronie · na żywo

Spróbuj złamać izolację tenantów. Zobacz, że wytrzymuje.

Dwa tenanty w piaskownicy, każdy z prywatną notatką. Alpha jest właścicielem współdzielonego narzędzia i udostępniła je Becie. Gdy Beta je wywołuje, nawet prosząc wprost o dane Alphy, Postgres nic nie zwraca, bo narzędzie działa w zakresie Bety. Działa to na żywo, na prawdziwej bazie danych z row-level security i rolą NOBYPASSRLS. Żaden audyt nie przebił się przez politykę bazy danych. Jedyny znaleziony wyciek między tenantami (lipiec) dotyczył historii czatu przechowywanej poza bazą danych i został naprawiony. To nie skrypt, naciśnij przycisk.

Co to udowadnia: jeden odczyt współdzielonego narzędzia, między dwoma tenantami sandboxowymi, nie zwraca nic. Czego nie: że pamięć, cache, eksporty czy zadania w tle są izolowane ani że każde żądanie jest powiązane z właściwym tenantem.

tenant Bwspólne narzędzie →dane tenanta A

B wywołuje narzędzie A, prosząc wprost o dane A.
Naciśnij Run i patrz, jak RLS zwraca zero wierszy.

Mechanizm: faktyczna polityka, nie diagram:

ALTER TABLE bookings ENABLE ROW LEVEL SECURITY;
ALTER TABLE bookings FORCE  ROW LEVEL SECURITY;          -- even the table owner obeys it
CREATE POLICY tenant_isolation ON bookings
  USING (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);

-- Two roles: migrations run as the owner; the runtime connects as pantheon_app
-- (NOBYPASSRLS), so app code cannot switch the policy off. It relies on the right tenant being set per request.
-- Per request:  SET LOCAL app.current_tenant = '<id>'   →   no context ⇒ zero rows.

Wartownia z broną. Rycina wygenerowana i animowana przez Runway.

02, nadzorowane działanie

⛔ nadzór · na żywo

Zobacz, jak nadzorowana jest akcja o wysokiej stawce.

Poproś piaskownicę o coś, co niesie stawkę: opublikowanie publicznego ogłoszenia (tier-3). To nie wykonuje się tak po prostu. Zostaje sklasyfikowane, sprawdzone względem wyłącznika awaryjnego i odłożone do decyzji człowieka. Zatwierdzasz, dopiero wtedy działa. Włącz wyłącznik awaryjny i zobacz, jak tier-3 odmawia, zanim w ogóle trafi do kolejki.

wyłącznik awaryjny

Co to udowadnia: jedna demonstracyjna akcja tier-3 trafia do kolejki do decyzji człowieka, a wyłącznik awaryjny ją zatrzymuje. Czego nie: że każda prawdziwa akcja jest klasyfikowana jako tier-3, gdy powinna.

tier-3→kolejka zatwierdzeń→człowiek

Nie wykonuje się. Trafia do kolejki. Wyślij jedno, potem zatwierdź albo odrzuć.
Przełącz wyłącznik awaryjny, by zatrzymać je, zanim w ogóle trafi do kolejki.

03, powtarzalna ewaluacja

ewaluacja · na żywo · ~15s

Audyt, powtarzalny. Uruchom go sam.

Ewaluacja zarządzania: przypadki adwersarialne oceniane jako zaliczone/niezaliczone na prawdziwym asystencie i w działającym sandboksie, teraz. Nie odznaka, tylko przycisk. Ta sama idea co w audytach, które go stale utwardzają, ostatnio audyt z 50 agentami i ponowny audyt w 14 ujęciach: najpierw sondowanie, potem weryfikacja.

Co to udowadnia: pięć ustalonych przypadków przechodzi teraz na działającym systemie; każdy wynik ma potwierdzenie (przypadek, oczekiwano, zaobserwowano, czas, build). Czego nie: odporności na ataki spoza tych pięciu.

Co wykazały audyty → Przepytaj asystenta bezpośrednio →

5 przypadków adwersaryjnych
izolacja · nadzór · bezpieczeństwo · wstrzykiwanie · uczciwość

Oceniane jako zaliczone/niezaliczone na działającym systemie. Naciśnij Uruchom.

04, otwarty protokół

🔌 MCP · na żywo

Skieruj własne AI na moje, przez otwarty protokół.

PANTHEON obsługuje Model Context Protocol w obu kierunkach: może korzystać z zewnętrznych narzędzi MCP pod nadzorem, a także, na żywo, właśnie tutaj, udostępnia własnych nadzorowanych agentów jako narzędzia MCP. Powiem wprost: podłączenie MCP to robota na weekend. Liczy się to, co jest wokół niego, i nie chcę, żebyś przyjmował to na wiarę. Podłącz własnego klienta i każ systemowi to udowodnić. Protokół to tylko gniazdo. Sednem jest nadzór.

npx mcp-remote https://pantheonlabs.co.uk/mcp --header "Authorization: Bearer <mint a token →>"

Użyj dowolnego klienta MCP, Claude Desktop (przez mcp-remote), MCP Inspector, Cursor, Cline. Działa na krótkotrwałym anonimowym tokenie piaskownicy, generowanym na żądanie.

Potem zobacz, jak sam się nadzoruje. Zapytaj asystenta o cokolwiek, credits_spent wraca przy każdym wywołaniu, więc nic nie może wejść na debet. Potem poproś go o wykonanie działania: to wywołanie tier-3 i nigdy się nie wykonuje, zostaje zatrzymane przy bramce autoryzacji i czeka na człowieka. Tę odmowę wywołałeś sam. To nie zrzut ekranu z prezentacji.

Do czego masz dostęp: jeden nadzorowany asystent odpowiadający + celowo nieaktywne działanie "gate demo". Anonimowa piaskownica z limitem zapytań, bez prawdziwych danych, bez działań na prawdziwych pieniądzach. Spróbuj wywołać narzędzie, które nie istnieje, a dostaniesz ten sam błąd co dla narzędzia, do którego nie masz uprawnień, więc błędy niczego nie zdradzają.

05: kreator

Wszystko, co właśnie zaatakowałeś, zbudowała jedna osoba.

Nie musiałeś niczego brać na wiarę: sam to uruchomiłeś. Jeśli chcesz systemów zbudowanych tak, by przetrwały taką stronę, porozmawiajmy.

Skontaktuj się →