MCP guardrails: permisiuni sigure pentru agenții AI

Un token MCP e parola contului tău, cu un API atașat. Dă-l unui agent și ai un utilizator care nu obosește niciodată, citește fiecare pagină web spre care îl îndrepți și face exact ce spunea ultima instrucțiune din contextul lui. De cele mai multe ori, asta vrei. Pagina de față e despre restul timpului.

Tot ce urmează a fost verificat pe serverul live la data de sus: lista uneltelor vine din tools/list pe https://mcp.eqvps.com/mcp, limitele din API-ul însuși. Dacă ești nou pe server, începe cu conectarea unui client MCP și tokenurile API, apoi revino.

Modelul de amenințare: ce merge de fapt prost

Trei lucruri, în ordinea în care le vedem:

1. Agentul înțelege greșit. „Curăță mașina de test” devine reinstalarea serverului greșit. Fără rea-voință, doar un model care umple un gol din instrucțiune.
2. Prompt injection. Agentul citește un text pe care nu l-ai scris tu (un README, un răspuns de la suport, o pagină colectată) și acel text îi spune să facă ceva. Dacă agentul are un token cu drepturi depline, le are și instrucțiunea injectată.
3. Tokenul se scurge. Ajunge într-un istoric de shell, într-un repo public, într-o configurație MCP dată altora sau într-o linie de log.

Serverul MCP verifică dacă tokenul e valid și dacă serverul aparține acelui cont (sau îi e delegat). Nu știe ce ai vrut să spui. Fiecare guardrail de mai jos lucrează pe o singură întrebare: câtă pagubă e posibilă când instrucțiunea e greșită?

Fiecare unealtă MCP, pe niveluri de risc

Un token de client vede 45 de unelte (serverul MCP 1.6.0). Un token de reseller (rk_…) vede un set separat de 30 de unelte pentru reselleri și niciuna dintre acestea, așa că endpointul are 75 în total. Clientul tău primește din tools/list doar propriul set.

Pagina asta ordonează uneltele după risc. Pentru parametrii fiecărei unelte și exemple de apeluri, vezi referința de parametri; toate uneltele pe câte un rând, inclusiv cele 30 pentru reselleri, sunt în lista completă.

Nu livrăm încă adnotări pentru uneltele MCP (readOnlyHint, destructiveHint), așa că clientul tău nu le poate ordona singur. Folosește nivelurile de mai jos ca să setezi aprobările manual.

Nivelul 0 — publice, fără token (5)

Nivelul 1 — citirea contului, fără efecte secundare (15)

Nivelul 2 — schimbă starea, nu cheltuie nimic (17)

Nivelul 3 — cheltuie bani, distruge date sau oferă acces (8)

Jurnalul schimbărilor setului de unelte

Versiunea care rulează e publică: curl -s https://mcp.eqvps.com/healthz. Când se schimbă, se schimbă și tabelul.

Soldul e plafonul de cheltuieli

EQVPS e preplătit. Nu există card salvat, linie de credit sau descoperit de cont, așa că maximul pe care îl poate cheltui vreodată un agent e cât stă în sold. Trei unelte cheltuie: order_vps, change_plan și create_sandbox. Reînnoirile serverelor existente ies din același sold.

Agentul poate crea cereri de bani, dar nu le poate plăti. topup_balance și pay_invoice returnează un link de checkout cripto, iar un link nu face nimic fără un portofel în spate. Nu există nici endpoint de retragere: banii din sold pot cumpăra servicii în contul tău și nu pot fi trimiși în afară. Și banii pentru timpul nefolosit, la o anulare imediată, se întorc tot în sold.

O precizare, și e una reală. Dacă ții soldul foarte mic ca să limitezi agentul, propriile reînnoiri încep să eșueze și serverele intră în perioada de grație. Regula noastră practică: un ciclu de reînnoire pentru ce rulezi deja, plus bugetul sarcinii curente a agentului. Ghidul bugetului pentru agenți arată cum îl dimensionezi. Iar dacă îi dai agentului propriul portofel alimentat, acel portofel devine un al doilea plafon la care trebuie să fii atent.

Privilegiul minim: nu există (încă) token doar de citire

Răspunsul direct: fiecare token de client are aceleași drepturi ca, în panou, contul. Numele și durata de viață ale tokenurilor se pot configura; domeniile de acces, nu.

Cel mai îngust lucru disponibil azi e delegarea. Îi dai agentului propriul cont, cu sold zero, și îi delegi un server:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

Același lucru prin REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

Invitația trebuie acceptată fiind autentificat cu acel e-mail (accept_delegation), iar expires_days poate fi între 1 și 365. Pas cu pas, cu capturi de ecran: delegarea accesului și accesul în documentație.

Observă ultimele două rânduri din stânga. Un delegat nu-ți poate cheltui banii, dar poate șterge acel server. Pornește backup-urile pe orice server pe care un agent îl poate reinstala.

Igiena tokenurilor

Un token pentru fiecare agent, cu un nume. Creează-l în Panou → Setări → Tokenuri API pentru agenți sau:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

Tokenul e afișat o singură dată. Durata de viață e între 1 și 1825 de zile, 365 dacă nu o setezi. Pentru agenți am alege 90.

Ține-l într-un fișier pe care doar tu îl poți citi, nu în repo, nu în prompt, nu într-o variabilă de shell pe care o lipești peste tot:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # expect -rw-------

Apoi încarcă-l în serviciul agentului cu EnvironmentFile= (systemd) sau set -a; . ~/.config/eqvps/agent.env; set +a.

Rotește-l înainte să expire. Unealta refresh_token sau POST /auth/tokens/{id}/refresh emite un token nou cu același nume și îl revocă imediat pe cel vechi. Dacă clientul tău MCP are tokenul scris direct în configurație, actualizează-l imediat după, altfel următoarea sesiune primește 401.

Verifică cine folosește ce: GET /auth/tokens listează fiecare token cu numele, expirarea și last_used_at. Un token pe care nu-l recunoști sau unul folosit după ce ai oprit agentul e semnalul tău.

Dacă se scurge un token

În ordinea asta:

1. Revocă-l. Panou → Setări → Tokenuri API pentru agenți → Revocă sau curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Nu mai merge de la următoarea cerere.
2. Caută tokenuri noi pe care nu le-ai creat și revocă-le și pe ele.
3. Verifică suprafața pagubei: Istoricul serviciului fiecărui server, facturile și soldul și list_delegations pentru acces pe care nu l-ai oferit.
4. Schimbă parolele root pe fiecare server pe care îl putea vedea tokenul. get_vps_status cu reveal: true dă parola root, așa că un token scurs e o parolă root scursă. Verifică și ~/.ssh/authorized_keys cât ești acolo.
5. Închide ușa parolei. Dacă contul tău n-a avut niciodată o parolă, cine avea tokenul putea seta una cu set_password. Autentifică-te cu un cod pe e-mail și schimb-o.

Prevenția pentru pasul 5 e ieftină: setează-ți chiar acum o parolă de cont, iar set_password va returna 409 pentru oricine după tine.

Omul în buclă

Ce impune serverul:

• reinstall_vps, reset_password și cancel_service cu type: immediate cer confirm egal cu numele de host exact (DELETE merge și pentru reinstalare și resetare).
• change_plan cere confirm: true.
• Anularea implicită e end_of_period: serverul rulează până la sfârșitul perioadei plătite, iar undo_cancel o întoarce.
• Limite de rată pe cont: reinstalare 4/min, resetarea parolei 6/min, pornire/oprire 20/min, comenzi 20/min. Destul cât să oprească o buclă să facă asta de cincizeci de ori, nu destul cât să oprească un singur apel greșit.

Fii lămurit ce e confirm. Oprește un agent să acționeze pe „curăță tot”. Nu oprește un atacator, pentru că numele de host e la un apel get_vps_status distanță. Pasul real de aprobare stă în clientul tău MCP. Majoritatea clienților pot întreba înaintea fiecărui apel de unealtă; lasă nivelurile 0 și 1 să ruleze liber și pune nivelul 3 să întrebe mereu. În clienții cu permisiuni pe unealtă, cum e settings.json din Claude Code (serverul înregistrat ca eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

Adaugă și un rând în instrucțiunile agentului. Nu e un control de securitate în sine, dar taie cazurile de neînțelegere:

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

Dacă agentul se autentifică printr-un cod pe e-mail în loc să țină un token de lungă durată, vezi autentificarea agentului prin MCP.

Auditul: ce poți vedea după aceea

• Lista tokenurilor (GET /auth/tokens sau Setări → Tokenuri API pentru agenți): nume, creare, expirare, last_used_at. De aceea contează să dai câte un nume tokenului fiecărui agent.
• Istoricul serviciului (panou, pagina serverului): porniri, opriri și reporniri, reinstalări, resetări de parolă, schimbări de plan, plăți, fiecare cu ora și cu autorul: tu, suportul sau automat. Nu-ți spune ce token sau delegat a acționat, doar că a venit din partea ta.
• Facturile și soldul: fiecare taxare și fiecare sumă întoarsă în sold.
• list_delegations: cine are acces la ce și până când.

Golul din Istoricul serviciului e limita cinstită a auditului pe server, azi. Dacă trebuie să știi ce agent a făcut ce, loghează pe partea agentului fiecare apel de unealtă, cu argumentele lui (fără secrete).

Configurarea pe care am folosi-o noi

Pentru un agent care administrează un server de producție:

1. Un cont separat pentru agent, cu sold zero, cu serverul delegat cu expires_days: 90.
2. Tokenul tău de proprietar rămâne la tine, în nicio configurație de agent.
3. Backup-uri pe acel server, pentru că un delegat poate reinstala.
4. Uneltele de nivelul 3 pe „ask” sau „deny” în client.
5. Tokenul agentului într-un fișier 600, reîmprospătat înainte să expire.

Pentru un agent care trebuie să comande servere sau să ruleze sandboxuri, delegarea nu ajunge, pentru că are nevoie de sold. Acolo soldul e plafonul tău: alimentează-l pentru fiecare sarcină, dă un nume tokenului și citește last_used_at o dată pe săptămână. Dacă un token doar de citire ți-ar schimba felul în care pui agenții în producție, spune-ne la suport: genul ăsta de feedback decide ce construim mai departe.