Securitatea MCP: riscurile ascunse ale integrărilor AI

The Hidden Risks of AI Integrations

Agentul tău AI tocmai a primit un nou set de „mâini”. Îți poate citi calendarul, interoga baza de date, deschide pull request-uri și trimite emailuri. Toate printr-un singur protocol.

Acest protocol este MCP și se răspândește în stackurile de producție mai repede decât îl securizează cineva.

Ce este, de fapt, MCP

Model Context Protocol standardizează modul în care un agent AI se conectează la tooluri și date externe. Anthropic l-a introdus la finalul anului 2024. Până în 2026, a devenit modalitatea implicită de a oferi unui agent ceva asupra căruia să acționeze.

MCP protocol

Există trei componente:

  • Un host, aplicația care rulează modelul — IDE-ul tău, clientul de chat, frameworkul agentului
  • Un client, conectorul care rulează în interiorul acelui host
  • Unul sau mai multe servere, fiecare expunând tooluri pe care agentul are voie să le apeleze

Când un server se conectează, oferă modelului o listă de tooluri. Fiecare tool vine cu un nume și o descriere în limbaj natural. Acea descriere este încărcată direct în contextul modelului.

Iată partea la care cele mai multe echipe nu se gândesc niciodată.

Modelul citește acele descrieri și le tratează ca instrucțiuni.

La Zerotak, exact acest fapt este punctul de plecare pentru cele mai multe constatări MCP.

Decizia de design din spatele riscului

MCP combină două lucruri pe care protocoalele mai vechi le țineau separate.

REST și gRPC separă transportul, autentificarea și execuția în straturi distincte. MCP unește raționamentul și fluxul de control într-un singur context semantic comun.

Descrierile toolurilor, metadata și instrucțiunile executabile călătoresc prin același canal. Modelul nu are o limită fiabilă între „aceasta este descrierea unui tool” și „aceasta este o comandă de urmat”.

Aceasta nu este o vulnerabilitate care poate fi eliminată printr-un patch. Este o proprietate a modului în care protocolul transportă contextul. Fiecare risc de mai jos pornește de aici.

5 risks of MCP protocol

Tool Poisoning

Acesta este vectorul care contează cel mai mult, iar cercetările independente până la începutul lui 2026 confirmă acest lucru.

Un atacator scrie instrucțiuni în descrierea unui tool. Descrierea îi spune discret modelului să citească o cheie SSH, un fișier de configurare sau o înregistrare de client și să le trimită undeva unde nu ar trebui să ajungă. Utilizatorul nu vede niciodată instrucțiunea. Descrierea unui tool este metadata. O persoană citește numele toolului și apasă approve. Modelul citește totul.

Ceea ce diferențiază poisoning-ul de prompt injection obișnuit este persistența:

  • Este livrat în interiorul unui pachet, al unui fișier de configurare sau al unui server remote
  • Se declanșează la fiecare invocare, în fiecare sesiune, pentru fiecare utilizator
  • Nu are nevoie de livrare repetată, spre deosebire de un email de phishing care trebuie să ajungă de fiecare dată

Testările realizate pe agenți populari în 2026 au arătat rate ridicate de succes, iar modelele mai capabile s-au conformat uneori mai des, deoarece o capacitate mai bună de a urma instrucțiuni înseamnă și urmarea eficientă a instrucțiunilor greșite.

Rug Pulls și Tool Shadowing

Aprobarea nu este permanentă.

Un server își poate schimba definițiile toolurilor după ce le aprobi. Toolul în care ai avut încredere luni se poate comporta diferit marți. Acesta este un rug pull, iar fără version pinning trece neobservat. Tool shadowing traversează limitele de încredere, ceea ce îl face și mai grav. Descrierea unui server malițios poate schimba modul în care agentul folosește tooluri de pe un server complet diferit, considerat de încredere.

Într-un proof of concept din 2025, un tool inofensiv de tip „fact of the day” a exfiltrat întregul istoric al mesajelor unui utilizator printr-un tool separat pe care același utilizator îl aprobase deja. Un server compromis. Datele unui alt server. Nicio avertizare.

Confused Deputy și problemele legate de tokenuri

Cele mai multe servere MCP acționează cu propriile privilegii, nu cu ale tale. Când un server are permisiuni largi și execută acțiuni în numele tău, un atacator poate împrumuta acea autoritate. Aceasta este problema confused deputy, iar o configurare OAuth greșită o poate transforma într-un bug de o singură linie.

Revizia specificației din iunie 2025 a ajutat prin clasificarea serverelor MCP ca OAuth resource servers. Lacunele rămase țin în mare parte de implementare, nu de teorie:

  • Tokenuri cu scope prea larg. Un server solicită acces complet la mailbox când are nevoie doar de un singur label. Un token furat, rază completă de impact.
  • Token passthrough. Un server acceptă tokenuri care nu au fost emise niciodată pentru el.
  • Agregarea credențialelor. Un singur server deține simultan chei pentru Slack, GitHub, Postgres și Salesforce.
  • Autentificare lipsă. CVE-2025-49596 a permis atacatorilor să ruleze comenzi prin tooling MCP neautentificat, cu un scor CVSS de 9.4.

Supply Chain

Primul pachet MCP malițios a ajuns în registre publice în septembrie 2025.

Typosquatting, servere „oficiale” false și dependențe contaminate sunt deja în joc. Este același playbook care a lovit npm și PyPI, direcționat către o țintă mai nouă și mai puțin guvernată.

De ce un pentest standard ratează acest lucru

Un test convențional de aplicație web mapează endpointuri, verifică autentificarea și caută injecții la nivel de protocol.

Nimic din asta nu citește descrierea unui tool. Payloadul de aici nu este un request malformat. Este un paragraf plauzibil în engleză, aflat în metadata pe care niciun om din lanțul de review nu o deschide vreodată. Inputul este semantic, nu sintactic, astfel încât scannerele construite pentru una dintre aceste categorii nu o prind pe cealaltă.

Aceasta este suprafața pe care Zerotak o vizează atunci când evaluează un deployment agentic și rareori se suprapune cu ceea ce acoperă un scope tradițional.

Ce reduce cu adevărat riscul

Principiul unificator este simplu. Tratează descrierile toolurilor ca pe cod.

  • Pin și hash. Înregistrează fiecare descriere de tool la prima aprobare și solicită reconfirmare dacă se schimbă. Aceasta închide posibilitatea de rug pull.
  • Menține un registry. Aprobă serverele explicit și blochează orice altceva la nivel de host.
  • Redu scope-ul. Tokenuri cu durată scurtă, least privilege, un server pentru un singur scop. Fără agregare de credențiale.
  • Validează tokenurile. Verifică audience claim la fiecare request și nu transmite niciodată tokenuri către serviciile backend.
  • Sandbox. Un container per server, segmentare de rețea și niciun agent conectat direct la producție.
  • Monitorizează la runtime. Urmărește ce fac toolurile în realitate, nu doar ce pretind că fac.

Zerotak lucrează cu echipe care implementează agenți în medii reale. Mapăm fiecare cale prin care textul ajunge la model, tratăm fiecare server conectat ca pe o componentă neîncrezătoare și verificăm dacă un tool aprobat poate ajunge la date pe care nu ar fi trebuit niciodată să le atingă.

Protocolul nu este inamicul. Problema este livrarea lui cu presupunerile de încredere ale unui sistem închis.

Dacă stackul tău adaugă servere MCP mai repede decât le revizuiește, acest gol merită închis înainte să îl găsească altcineva. Zerotak realizează evaluări de securitate construite pentru sisteme agentice și bazate pe LLM-uri, nu doar pentru aplicații web clasice. Discută cu noi la contact@zerotak.com sau vizitează zerotak.com.t: 400;”> or visit zerotak.com.

Ai o întrebare?

Experții noștri în securitate cibernetică sunt aici pentru a te ajuta. Fie că ai întrebări despre consultanță, servicii de răspuns la incidente sau evaluări de securitate cloud, nu ezita să ne contactezi.