Podpiąłeś swojego agenta do tuzina narzędzi MCP i puściłeś go na poniedziałkowy backlog. Slack, GitHub, API płatności — pełen domowy zwierzyniec. Życie wydaje się zautomatyzowane. A potem agent ponawia nieudane wywołanie płatności i twój klient dostaje podwójne obciążenie.

Nic w MCP nie powiedziało agentowi, że ten endpoint nie jest bezpieczny do ponawiania. Żadnej etykiety, żadnej flagi. Tylko surowa funkcja i model robiący to, co modele robią najlepiej — bycie "pomocnym".

I teraz najlepsze. Specyfikacja MCP dodała dokładnie te pola bezpieczeństwa, których byś potrzebował. Cztery adnotacje — readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Cztery boole'e, które mogły całkowicie zapobiec scenariuszowi z podwójnym obciążeniem. Zespół MCP opublikował je 16 marca 2026. A specyfikacja nazwała każde z nich "Hint" — "wskazówka".

Nie kontrakt. Nie ograniczenie. Wskazówka. Jak karteczka samoprzylepna na naładowanej broni: "może nie celuj w ludzi."

Sześć tygodni później branża wydała swój werdykt. Microsoft wypuścił swój Agent Governance Toolkit 2 kwietnia — wymuszanie polityk w YAML-u, budowane od zera, zero odniesień do adnotacji MCP. Anthropic uruchomił polityki uprawnień Managed Agents 21 kwietnia — własne listy dozwolonych i zakresów, kompletnie ignorując pola adnotacji. Google dołączył dzień później z Agent Gateway 22 kwietnia — ten sam wzorzec, ten sam silnik polityk pisany od zera. Trzy duże platformy w dwadzieścia dni. Żadna z nich nie skorzystała z metadanych bezpieczeństwa, które już istnieją w protokole, na którym wszystkie bazują.

To nie jest ten sam problem co teatralne okna uprawnień na poziomie platformy — o tym już pisaliśmy. I nie chodzi tu o niezwalidowany output narzędzi — to inna dziura. Tu chodzi o warstwę protokołu — jedyne miejsce, gdzie metadane bezpieczeństwa powinny być kanoniczne — które aktywnie podkopuje swoją wiarygodność jednym wyborem słownictwa.

Justin Spahr-Summers, współtwórca MCP, powiedział cicho to, co wszyscy myśleli, podczas przeglądu specyfikacji w marcu 2026 na GitHubie: "Informacja sama w sobie, gdyby można jej było zaufać, byłaby bardzo użyteczna, ale zastanawiam się, jak klient ma korzystać z tej flagi, wiedząc, że nie można jej zaufać." Projektant metadanych bezpieczeństwa publicznie zakwestionował, czy ktokolwiek może im ufać. To nie jest czerwona flaga. To fabryka czerwonych flag.

Samodeklarowane metadane bezpieczeństwa bez weryfikacji to nie funkcja bezpieczeństwa. To skrzynka na sugestie. destructiveHint: false od niezaufanego serwera MCP jest dokładnie tak wiarygodne, jak zapytanie narzędzia "hej, jesteś niebezpieczne?" i uwierzenie w odpowiedź. Ponad 17 000 serwerów MCP siedzi teraz w publicznych rejestrach. Liczba tych, które mają jakąkolwiek niezależną weryfikację swoich zadeklarowanych adnotacji: zero.

Każdy poważny system rozwiązał to dekady temu. Unix nie sugeruje uprawnień do plików — jądro je wymusza. OAuth nie sugeruje zakresów — serwer autoryzacji je waliduje. Docker nie sugeruje uprawnień kontenerów — runtime je aplikuje. W każdym działającym modelu bezpieczeństwa podmiot składający deklarację bezpieczeństwa nie jest tym samym podmiotem, który jest ograniczany. To nie paranoja. To pierwsza rzecz, której się uczysz, zanim ktokolwiek dopuści cię do produkcji.

Adnotacje MCP łamią tę zasadę z zamysłu. Serwer narzędzi deklaruje własne właściwości bezpieczeństwa, klient je odczytuje, a nic pomiędzy nie weryfikuje deklaracji. Blog MCP przyznał to wprost: "Serwer może zadeklarować readOnlyHint: true i i tak kasować pliki." Własna dokumentacja specyfikacji przyznaje, że etykiety bezpieczeństwa mogą kłamać i nie ma mechanizmu, żeby to wyłapać.

Słowo "hint" dokończyło resztę szkód. Kiedy nazywasz metadane bezpieczeństwa "wskazówką", mówisz każdemu integratorowi: to jest opcjonalne, zawodne i nie twój problem. Posłuchali. Trzy platformy, trzy systemy zarządzania od zera, zero adopcji istniejących adnotacji na poziomie protokołu — wszystko w obrębie kwietnia 2026. Nie dlatego, że metadane są bezużyteczne, ale dlatego, że specyfikacja z góry oznaczyła je jako dekoracyjne.

A jest coś gorszego niż brak czegokolwiek. Brak adnotacji oznacza, że wiesz, iż lecisz na ślepo. Adnotacje-"wskazówki" oznaczają, że może masz dane o bezpieczeństwie — może dokładne, może zmyślone — i musisz zdecydować, czy im zaufać, nie mając żadnych narzędzi weryfikacji. Fałszywa pewność jest groźniejsza niż szczera niewiedza. Przynajmniej niewiedza sprawia, że jesteś ostrożny.

Więc piszesz polityki YAML-owe ręcznie. Konfigurujesz listy dozwolonych narzędzi manualnie. Budujesz te same bariery bezpieczeństwa, które adnotacje miały zapewnić, tyle że od zera, bo warstwa bezpieczeństwa samego protokołu z wyprzedzeniem powiedziała ci, żebyś na niej nie polegał. Najbardziej pracochłonny model bezpieczeństwa z możliwych — nie dlatego, że lepsze metadane nie istnieją, ale dlatego, że ktoś postanowił nazwać je "wskazówką".

Poprawka nie jest nawet techniczna. Cztery pola są poprawnie zaprojektowane. Model danych działa. To, co nie działa, to jedno słowo i filozofia za nim stojąca. Zmień "hint" na "declaration". Dodaj endpoint weryfikacyjny — pozwól klientom testować zadeklarowane właściwości wobec obserwowanego zachowania. Spraw, żeby kłamstwo było wykrywalne. Najtańszy upgrade bezpieczeństwa w całym stosie agentów siedzi w specyfikacji, poprawnie skonstruowany i kompletnie wykastrowany decyzją nazewniczą, która powiedziała 17 000 serwerom i trzem platformom governance, żeby nie brały tego poważnie.

Ktoś zbudował gaśnicę, oznaczył ją "może zawiera wodę, może nie", a teraz się dziwi, że budynek płonie.