Primul mod în care oricine îi dă acces unui agent este cel evident: creezi o cheie API la furnizor, o lipești în configurarea agentului, gata.
Funcționează. Continuă să funcționeze exact până în momentul în care ai patru agenți, șase furnizori și nicio idee care credențial unde se află — iar până atunci, desfacerea situației este un proiect.
Ce costă de fapt modelul cu o cheie per agent
Un număr pătratic de credențiale. Patru agenți care au nevoie fiecare de cinci aplicații înseamnă douăzeci de credențiale de creat, stocat, rotit și eventual revocat. Nimeni nu întreține grila aceea; oamenii întrețin părțile pe care și le amintesc.
Credențiale în fișiere de configurare. O cheie API în .cursor/mcp.json este
o cheie aflată la un git add -A distanță de a fi comisă, la un partaj de ecran
distanță de a fi citită cu voce tare și la un laptop distanță de a fi undeva unde
nu ar trebui. Toată lumea știe asta. Toată lumea o face oricum, pentru că
alternativa înseamnă mai multă muncă exact în momentul în care vrei doar să
meargă.
Fără atribuire. O cheie API nu este o persoană. Când se întâmplă ceva surprinzător, jurnalul furnizorului spune că a făcut-o cheia. Care agent? În numele cui? La cererea cui? Cheia nu știe și nu poate spune.
Ieșirea din echipă devine arheologie. Pleacă cineva. Agenții lui continuă să funcționeze, pentru că o cheie nu știe nimic despre apartenența la spațiul tău de lucru. Găsirea fiecărui loc unde a fost lipită cheia este acum după-amiaza cuiva, iar certitudinea că le-ai găsit pe toate este imposibilă.
Permisiunile sunt oricare ar fi permisiunile furnizorului. Permisiunile de la
furnizor sunt largi prin design — gmail.modify acoperă aruncarea firelor la
coș, drive înseamnă Drive-ul tău. Dacă vrei „citește orice, nu șterge nimic”
și furnizorul nu are o permisiune de forma aceea, nu o primești. Singurul control
rămas este să rogi frumos modelul.
O rotație pe care nu o face nimeni. Rotirea unei chei înseamnă găsirea fiecărei configurări care o are, actualizarea lor împreună și nespargerea nimic între timp. Așa că nu se întâmplă, iar cheile trăiesc ani.
Ce schimbă un singur gateway
Agentul primește un singur URL și un singur credențial. Tot ce e în spate — ce furnizori, ce conturi, ce permisiuni — devine configurare într-un singur loc, nu secrete în multe.
Conectezi o dată, per aplicație, nu per agent. Autorizezi Gmail o dată, prin ecranul de consimțământ al Google. Fiecare agent care are voie să ajungă acolo, ajunge. Adaugi al cincilea agent și nu ai nimic de distribuit.
Credențiale pe care nu le atingi. Autorizarea ajunge într-un seif criptat pe care doar rolul de server îl poate decripta și este reînnoită înainte să expire. Nu există niciun token într-un fișier de configurare, pentru că nu există nimic pe care să îl țină.
Mai bine: deseori niciun credențial. Clienții care pot deschide un browser — Claude, ChatGPT, Codex — se autorizează ca tine, prin OAuth. Configurarea lor conține un URL și nimic altceva. O configurare fără secret în ea nu poate scăpa un secret.
Atribuire care supraviețuiește. Fiecare apel din jurnal poartă în numele cui a acționat, ce client l-a făcut, ce conexiune a folosit și ce a primit înapoi. Nu „a făcut-o cheia” — un nume.
Ieșirea din echipă este o singură acțiune. Apartenența este verificată la fiecare apel, deci scoaterea unei persoane îi oprește agenții la următoarea cerere. Nu când expiră un token. Nu când își amintește cineva.
Permisiuni pe care furnizorul nu le oferă. Citire, scriere și distructiv per aplicație, aplicate în gateway înainte ca apelul să plece undeva. „Agentul acesta poate citi orice și nu poate șterge nimic” este o regulă pe care chiar o poți avea, deși niciun furnizor nu vinde o permisiune de forma asta.
Una lângă alta
| O cheie API per agent | Un singur gateway | |
|---|---|---|
| Credențiale de administrat | Agenți × furnizori | Unul per persoană |
| Unde stau secretele | Fișiere de configurare, pe laptopuri | Seif criptat, sau nicăieri |
| Adăugarea unui agent | Redistribui fiecare cheie | Nimic de făcut |
| Atribuire | A făcut-o cheia | O persoană cu nume, per apel |
| Ieșire din echipă | Găsește fiecare cheie lipită | Scoți membrul |
| Granularitatea permisiunilor | Cât oferă furnizorul | Citire / scriere / distructiv, per aplicație |
| Rotație | Manuală, deci niciodată | Înlocuiești un credențial |
| Raza unei scurgeri | Acel furnizor, până observi | Delimitată și revocabilă într-un loc |
Obiecția care merită luată în serios
Un singur gateway este un singur punct de eșec, iar un singur credențial este un singur lucru de furat. Ambele sunt adevărate.
Punctul de eșec este real și merită planificat. Credențialul este o obiecție mai slabă decât pare: un credențial pe care îl poți roti într-o singură acțiune, care este legat de o persoană, care poate fi revocat central și a cărui fiecare utilizare este înregistrată, este o poziție semnificativ mai bună decât douăzeci pe care nu le poți găsi. Concentrarea este rea doar când lucrul concentrat este neadministrat.
Varianta pe care chiar am recomanda-o
Folosește fluxul din browser oriunde clientul îl suportă, ca cele mai puternice configurări să nu conțină deloc un credențial. Folosește o cheie doar unde un client nu poate deschide un browser. Setează citire/scriere/distructiv per aplicație înainte ca vreun agent să primească acces, nu după. Și citește jurnalul de activitate o dată, după prima sarcină reală — este cel mai rapid mod de a afla ce fac de fapt agenții tăi.