Vercel Security Checkpoint: Ce se strică atunci când agenții dau de ziduri anti-bot
Crawler-ul nostru IRIS a lovit un zid luna aceasta: un articol VentureBeat despre agenții de reconciliere ai Morgan Stanley a returnat o pagină Vercel Security Checkpoint (Code 21) în loc de HTML.
Vercel Security Checkpoint: Ce se strică atunci când agenții dau de ziduri anti-bot
Crawler-ul nostru IRIS a lovit un zid luna aceasta: un articol VentureBeat despre agenții de reconciliere ai Morgan Stanley a returnat o pagină Vercel Security Checkpoint (Code 21) în loc de HTML. Ironia se scrie singură — un articol despre autonomia agenților, invizibil pentru agenții autonomi. Acest mod de eșec este acum cel mai frecvent non-2xx pe care îl logăm pe media enterprise și merită un răspuns de inginerie, nu un workaround.
Ce face de fapt checkpoint-ul
Checkpoint-ul Vercel este un managed challenge injectat la edge de layer-ul de firewall al platformei, descris în documentația Vercel Firewall și configurabil per proiect. Când traficul primește un scor suspect — fingerprint de UA headless, extensii TLS lipsă, reputație ASN — edge-ul returnează un 200 OK cu un interstitial care execută un handshake de verificare JavaScript înainte de a seta un cookie semnat. Abia după ce acel cookie este prezent răspunde origin-ul cu resursa cerută. Fetcher-ele HTTP standard văd o pagină intitulată „Verifying you are human”; feed reader-ele stricte nu văd nimic utilizabil.
Nu este un comportament nou. Urmează pattern-ul pe care Cloudflare l-a formalizat în challenge-ul Turnstile și abordarea bazată pe semnale de risc descrisă în IETF RFC 9110 §15.5.4 pentru răspunsurile 403. Particularitatea e că Vercel returnează 200, nu 403, așa că logica de retry bazată pe status code reușește silențios în timp ce capturează body-ul greșit.
2026-07-02T09:14:03Z iris.fetch url=venturebeat.com/orchestration/...
2026-07-02T09:14:03Z iris.fetch status=200 bytes=4812 title="Verifying..."
2026-07-02T09:14:03Z iris.classifier verdict=CHECKPOINT code=21 action=abort
2026-07-02T09:14:03Z iris.pipeline fallback=archive.org url=web.archive.org/...Consecința pentru designul agenților
Două lucruri decurg de aici pentru oricine construiește agenți content-aware. Primul: status-ul HTTP nu mai este un semnal fiabil de succes — clasificarea conținutului trebuie să ruleze înainte de extracție. Al doilea: răspunsul corect la un checkpoint este escaladarea pe o cale conformă, nu evaziunea. Tooling-ul de bypass încalcă obligațiile de evaluare a riscurilor din Art. 34 al EU Digital Services Act când operatorul este o platformă și încalcă ToS-ul majorității publisherilor indiferent de context.
Poziția noastră în pilonul IRIS a fost consecventă: agenții care accesează conținut terț au nevoie de o topology în care refuzul este un prim-cetățean, nu o excepție. Este aceeași formă argumentată în abordarea noastră privind siguranța agentic AI și disciplina de graniță descrisă în modelul de amenințări AEGIS — fiecare fetch este o decizie de politică, nu un apel de instalații.
Ce face CAI diferit
Rutăm fiecare fetch extern printr-un classifier care scorează cinci rezultate — succes, checkpoint, paywall, ratelimit, hard-fail — înainte ca extractorul să ruleze vreodată. Checkpoint-urile declanșează o căutare în feed-uri licențiate (briefing-ul ENISA 2024 privind peisajul amenințărilor documentează de ce căile de scraping nelicențiate degradează încrederea în analiza downstream) și, în caz de eșec, un ticket uman. Zero capturi silențioase. Zero body-uri fabricate. Dacă sursa este inaccesibilă, articolul nu se publică — cel pe care îl citiți acum este excepția care confirmă regula.
Dacă vreți tabela de decizie a classifier-ului și matricea de fallback, notele noastre de inginerie IRIS le publică pe amândouă.