Sajber bezbednost
Skriveni PR komentari u Azure DevOps MCP-u mogu da preotmu AI review agente kroz vise projekata
Novo prijavljena slabost u Microsoft Azure DevOps MCP serveru pokazuje koliko brzo AI-potpomognuti developerski alati mogu da postanu bezbednosna granica. U opisanom napadnom putu contributor sakrije instrukcije u HTML komentar unutar opisa pull request-a. Covek koji radi review u web interfejsu ne vidi nista sumnjivo, ali AI review agent kroz API dobija sirovi tekst i moze da ga protumaci kao uputstvo. Kako agent radi sa pravima reviewera, posledica mogu biti pristup preko vise projekata, izvlacenje podataka i akcije koje napadac nikada ne bi mogao direktno da izvede.
Zato ovo nije samo jos jedna genericka prompt-injection prica. Operativni rizik nastaje iz pozajmljenih privilegija. Napadacu ne trebaju visoka prava. Dovoljno je da postavi tekst na mesto koje ce kasnije procitati agent korisnika sa sirom autorizacijom. Ako agent moze da cita wiki stranice, pokrece pipeline-e, otvara work item-e ili postavlja komentare, pull request postaje ulazna tacka ka mnogo osetljivijim delovima Azure DevOps okruzenja.
Zasto je ova slabost posebno bitna za enterprise DevOps
Po javno dostupnim izvestajima, Microsoft je vec dodao odbranu za neke MCP response putanje tako sto odvaja nepouzdan sadrzaj od stvarnih instrukcija, ali putanja koja vraca pull-request opis i dalje je davala sirov tekst. To je bitno jer su pull request-ovi upravo mesto gde zivi contributor-kontrolisan, potencijalno zlonameran sadrzaj. Slucaj ujedno pokazuje siri problem za AI operacije: parcijalni guardrail-i nisu dovoljni ako je dovoljan samo jedan nepokriven tool path da model dobije zive instrukcije.
- Napadac moze da sakrije instrukcije u sadrzaju koji ljudski reviewer prakticno ne vidi.
- Agent radi sa sirim pravima reviewera, a ne sa ogranicenim pristupom napadaca.
- Kretanje preko vise projekata postaje moguce ako set alata ukljucuje pipeline-e, wiki-je, repozitorijume ili work item-e van izvornog PR opsega.
- Rizik dodatno raste kada timovi automatizuju review i triazu bez ljudske provere svakog tool poziva.
Sta security i platform timovi prvo treba da promene
1) Smanjiti opseg alata i privilegija za review agente
Code-review agent ne bi smeo automatski da nasledi sve sto senior inzenjer moze da uradi u Azure DevOps-u. Tokene treba ograniciti na minimum potrebnog projektnog opsega, izbegavati siroke personal access tokene gde god je moguce i ukloniti nepotrebne sposobnosti kao sto su cross-project pipeline run-ovi, wiki citanje ili comment posting ako nisu neophodni za sam review zadatak.
2) PR tekst tretirati kao neprijateljski ulaz po difoltu
Ispravan mentalni model je da su opis pull request-a, komentari i povezani artefakti sadrzaj koji napadac moze da kontrolise. Svaki MCP alat koji ih vraca treba eksplicitno da odvoji podatke od instrukcija pre nego sto ih model vidi. Ako server stiti wiki stranice, ali ne i pull request-ove, kontrola je nepotpuna. Platform timovi treba da auditiraju svaku response putanju, ne samo ocigledne.
3) Zadrzati ljudske checkpoint-e za osetljive akcije
Rizik naglo raste kada agenti rade u auto-approve modu. Potvrda za cross-project read, pipeline execution, pristup resursima bliskim secret-ima ili outbound posting daje revieweru sansu da zaustavi ponasanje koje ne odgovara originalnom zadatku review-a. Ljudska provera nije savrsena, ali je i dalje mnogo bolja od tihog izvrsavanja alata.
Hitna response checklista
| Privilegije agenta | Napadac pozajmljuje autoritet reviewera | Koristiti least-privilege tokene i project-scoped pristup za AI review zadatke |
|---|---|---|
| Izlozenost alata | Review agent cesto ima vise mogucnosti nego sto zadatak trazi | Iskljuciti pipeline, wiki i comment akcije ako workflowu realno nisu potrebne |
| Prompt-injection odbrana | Jedna nepokrivena content putanja moze da obori siri zastitni model | Auditirati svaki MCP alat koji vraca user-controlled sadrzaj i nametnuti dosledno razdvajanje sadrzaja |
| Approval workflow | Auto-odobreni tool pozivi pustaju cudno cross-project ponasanje bez upozorenja | Uvesti confirmation gate za osetljive akcije i high-trust resurse |
| Detekcija | Uspeh zloupotrebe moze delovati kao legitimna review aktivnost | Pratiti agent trace-ove za cross-project read-ove, pipeline run-ove i komentare koje agent postavlja tokom review-a |
Zakljucak
Azure DevOps MCP problem je korisno upozorenje za svaki tim koji AI agente gura dublje u software delivery workflow-e. Problem nije samo u tome sto model moze biti prevaren skrivenim tekstom. Problem je sto model pritom nosi stvarni autoritet. Enterprise DevOps timovi treba da tretiraju review agente kao privilegovanu automatizaciju, da suze njihov domet, auditiraju svaku tool putanju koja obradjuje contributor-kontrolisan sadrzaj i zadrze osetljive akcije iza eksplicitnih checkpoint-a pre nego sto ovaj obrazac postane rutinska tehnika napada.