Un utilizator Vercel a raportat o problemă care părea extrem de înfricoșătoare. O bază de cod necunoscută GitHub OSS este implementată în echipa lor. Desigur, am luat raportul extrem de în serios și am început o investigație. Securitate și inginerie infrastructurală angajate. Se pare că Opus 4.6 *a halucinat un ID de repository public* și a folosit API-ul nostru pentru a-l implementa. Din fericire pentru acest utilizator, depozitul era inofensiv și aleatoriu. Sarcina JSON arăta astfel: "gitSource": { "type": "github", "repoId": "913939401", // ⚠️ halucinați "ref": "principal" } Când utilizatorul i-a cerut agentului să explice eșecul, acesta a mărturisit: Agentul nu a verificat niciodată ID-ul depozitului GitHub prin API-ul GitHub. Nu există niciun apel API GitHub în sesiunea dinaintea primei implementări neautorizate. Numărul 913939401 apare pentru prima dată la linia 877 — agentul l-a fabricat în întregime. Agentul știa ID-ul corect al proiectului (prj_▒▒▒▒▒▒) și numele proiectului (▒▒▒▒▒▒), dar a inventat un ID numeric de repo care părea plauzibil, în loc să îl caute. Câteva concluzii: ▪️ Chiar și cele mai inteligente modele au moduri de defecțiune bizare, foarte diferite de ale noastre. Oamenii fac multe greșeli, dar cu siguranță nu inventează un ID de repo-uri la întâmplare. ▪️ API-urile puternice creează riscuri suplimentare pentru agenți. API-ul există pentru a importa și implementa cod legitim, dar nu dacă agentul decide să halucineze ce cod să implementeze! ▪️ Astfel, este probabil ca agentul să fi avut rezultate mai bune dacă nu ar fi decis să folosească API-ul și ar fi rămas la CLI sau MCP. Acest lucru întărește angajamentul nostru de a face din Vercel cea mai sigură platformă pentru ingineria agentică. Prin integrări mai profunde cu instrumente precum Claude Code și protecții suplimentare, suntem încrezători că securitatea și confidențialitatea vor fi respectate. Notă: ID-ul repository-ului de mai sus este randomizat din motive de confidențialitate.