Cum să construiți o întreprindere API Gateway pentru agenții de codare

Un agent de codificare nu este doar o altă solicitare LLM. Poate citi codul sursă, poate modifica fișiere, poate rula comenzi shell, poate apela instrumente, poate deschide solicitări de extragere și poate continua o sarcină în mai multe ture de model. Dacă mediul de execuție expune secrete sau acces nerestricționat la rețea, agentul le poate atinge și pe acestea.

Asta modifică problema gateway-ului. Un gateway LLM obișnuit poate autentifica API apeluri, modele de rută, jetoane de contorizare și poate aplica limitele de cheltuieli. Un agent de codare API gateway are nevoie de aceste controale, dar trebuie să guverneze și volumul de lucru din jurul apelului model: acces la depozit, izolarea sandbox, permisiuni pentru instrumente, schimb de acreditări, ieșire din rețea, fluxuri de aprobare și piste de audit la nivel de activitate.

Acest articol definește o arhitectură practică de referință pentru un plan de control al agentului de codificare al întreprinderii. Este scris pentru liderii de inginerie și echipele de platformă care lansează agenți prin IDE-uri, GitHub fluxuri de lucru, CLI instrumente și sandbox-uri gestionate.

Granița planului de control

Poarta de acces ar trebui să se afle între dezvoltatorul uman, timpul de execuție al agentului, furnizorii de modele, depozitele, MCP servere, magazinele secrete și rețelele interne. Nu ar trebui să se limiteze la trimiterea prin proxy a finalizărilor de chat sau a răspunsurilor model.

În practică, planul de control trebuie să răspundă la șapte întrebări înainte și în timpul fiecărei sarcini de agent:

• Pentru cine sau pentru ce acționează acest agent?
• Ce depozite, ramuri, fișiere și registre de pachete poate accesa?
• Ce comenzi shell, MCP instrumente și destinații de rețea sunt permise?
• Ce acreditări pot fi emise, în ce scop și pentru cât timp?
• Ce model de niveluri, bugete și limite de viraj se aplică?
• Ce acțiuni necesită aprobare umană?
• Ce înregistrări de urmărire, utilizare și audit trebuie exportate?

Aceasta face ca gateway-ul agentului de codificare să facă parte dintr-o infrastructură LLM API mai amplă a întreprinderii, dar cu o suprafață diferită de aplicare. Apelul model este doar un pas în volumul de lucru.

Arhitectură de referință

O arhitectură funcțională are șase straturi: identitate, politică, sandbox, broker de acreditări, B2B LLMway și registru de audit și utilizare. Aceste straturi pot fi implementate cu produse diferite, dar responsabilitățile ar trebui să rămână separate.

1. Stratul de identitate

Stratul de identitate oferă fiecărei sarcini de agent o identitate durabilă care poate fi atribuită, constrânsă și revocată. Evitați cheile partajate de dezvoltator API sau conturile de serviciu generice care fac ca fiecare activitate să arate la fel.

Cel puțin, fiecare sarcină ar trebui să includă:

• Actor: utilizatorul, serviciul sau automatizarea care a început sarcina.
• Suprafața agentului: extensie IDE, CLI, GitHub agent, job CI sau sandbox gestionat.
• Scopul depozitului: organizație, depozit, sucursală și director de lucru.
• Mediu: dezvoltare, testare, punere în scenă sau producție.
• Echipă și centru de cost: pentru aprobare, raportare și aplicarea bugetului.
• ID de activitate: un identificator stabil pentru apelurile de model, apelurile de instrumente, comenzile shell și activitatea de solicitare de extragere.

Cel mai puternic model este identitatea per agent sau per sarcină de lucru cu token-uri de scurtă durată. Federația de identitate a sarcinii de lucru este utilă aici, deoarece agentul poate schimba o afirmație de încredere cu un token de scurtă durată în loc să transporte o cheie de furnizor cu durată lungă de viață. Utilizați principii dedicate, potrivirea exactă a revendicărilor, cel mai mic privilegiu și identități separate de producție și non-producție.

2. Stratul politic

Stratul de politică este punctul de decizie pentru volumul de lucru. Ar trebui să evalueze mai mult decât accesul la model. Un agent de codare poate provoca daune printr-o comandă shell, un instrument MCP, un pas de publicare a pachetului sau un apel de rețea chiar și atunci când cererea de model în sine pare inofensivă.

Politicile ar trebui să acopere:

• Liste permise pentru depozit și restricții pentru ramuri.
• Permisiuni de citire, scriere, testare, confirmare și extragere.
• Clasele de comenzi shell permise și interzise.
• MCP descoperirea serverului, conexiune și invocarea instrumentului.
• Mod rețea de ieșire: dezactivat, restricționat sau deschis prin excepție.
• Acces secret în funcție de destinație, scop, mediu și durata de viață.
• Nivelul de model, viraje maxime, apeluri maxime de instrumente și limite de buget.
• Cerințe de aprobare umană pentru acțiuni riscante.

Punctul de decizie privind politica ar trebui apelat înainte de executarea instrumentului, nu numai înainte de apelurile modelului. De exemplu, agentului i se poate permite să solicite unui model un plan de migrare, dar nu poate rula o comandă a bazei de date de producție sau publică un pachet.

3. Stratul Sandbox

Sandbox-ul este limita de execuție pentru sistemul de fișiere, shell, pachet și acces la rețea. Ar trebui tratat ca un mediu de încărcare de lucru, nu un container de confort.

Un model practic de segmentare este:

• Activități de numai citire cu risc scăzut: izolate pentru fiecare utilizator sau depozit, fără secrete, rețea restricționată.
• Activități de modificare a codului: spații de lucru izolate care pot fi scrise, jetoane în domeniul depozitului, acreditări numai pentru testare.
• Activități de infrastructură: casete de nisip întărite separate, aprobări stricte, fără valori prestabilite de producție.
• Activități adiacente producției: rare, limitate în timp, intens înregistrate și izolate de agenții dezvoltatori normali.

Nu permiteți agenților neînrudiți să partajeze sisteme de fișiere inscriptibile, cache-uri, acreditări sau registre de pachete decât dacă această partajare este intenționată. Cache-urile partajate pot îmbunătăți viteza, dar creează și contaminare între sarcini și îngreunează analiza criminalistică.

Ieșirea din rețea ar trebui să fie explicită. Unele sarcini necesită registre de pachete, site-uri de documentație, magazine interne de artefacte sau servicii de testare. Acest lucru nu necesită acces arbitrar de ieșire. Folosiți listele permise pentru gazde restricționate acolo unde este posibil și înregistrați destinațiile reale.

4. Broker de acreditări

Brokerul de acreditări păstrează secrete de lungă durată în afara zonei de testare. Agentul nu ar trebui să primească chei cloud largi, jetoane de administrator de control sursă sau secrete ale aplicațiilor de producție pur și simplu pentru că rulează într-un flux de lucru pentru dezvoltatori.

Brokerul ar trebui să emită acreditări de scurtă durată, cu sfera de aplicare numai după aprobarea politicii. O solicitare către broker ar trebui să includă identitatea sarcinii, depozitul, destinația, permisiunea solicitată și operațiunea intenționată.

Modelele de broker utile includ:

• Jetoane de depozit limitate la un singur depozit și expirare scurtă.
• Tokenuri de registru pachet limitate la operațiuni de instalare, nu la publicare.
• Acreditările cloud limitate la conturi care nu sunt de producție și la acțiuni numai în citire.
• Acreditările bazei de date limitate la mediile de testare.
• Adrese URL semnate sau acorduri de acces temporar pentru anumite artefacte.

Brokerul ar trebui să respingă cererile vagi. „Oferiți acestui agent acces AWS” nu este o unitate de politică sigură. „Permiteți acestei sarcini să citească o anumită cale de stocare a obiectelor provizorii timp de 15 minute” este mai aproape de o unitate guvernabilă.

5. B2B LLMway

Poarta de acces model încă contează. Agenții de codare pot genera un volum mare de simboluri prin bucle de planificare, citiri repetate de fișiere, eșecuri de testare, ieșiri de instrumente și reîncercări. Gateway-ul ar trebui să gestioneze autentificarea, rutarea modelului, aplicarea bugetului, măsurarea utilizării și abstracția furnizorului.

Pentru sarcinile de lucru ale agenților, adăugați câmpuri pe care o solicitare normală API nu le poate avea:

• ID activitate agent.
• Cod sandbox.
• Arhivă și ramură.
• Număr de apeluri pentru instrumente.
• Politica privind virajul maxim.
• Starea de aprobare.
• Nivelul de risc.
• Clasa de sarcini așteptată, cum ar fi actualizarea documentelor, generarea de teste, refactorarea sau actualizarea dependenței.

Aceste metadate permit echipei platformei să compare costul și fiabilitatea între tipurile de sarcini, mai degrabă decât să trateze întreaga utilizare a modelului ca un flux nediferențiat. De asemenea, permite echipelor de securitate să identifice modele de utilizare neobișnuite, cum ar fi un agent de documentare care efectuează apeluri repetate asociate cu modificările de infrastructură.

6. Registrul de audit și utilizare

O pistă de audit a unui agent de codare trebuie să conecteze apelurile model cu acțiuni reale. Numai utilizarea simbolurilor nu este suficientă.

Exportați o urmărire a sarcinii care include:

• Cine a început sarcina și de pe ce suprafață.
• Ce furnizori de modele și ce niveluri de model au fost utilizați.
• Utilizarea simbolurilor, latența, erorile și estimările costurilor.
• Arhivele, ramurile și fișierele atinse.
• Comenzile Shell propuse, aprobate, refuzate și executate.
• MCP servere și instrumente invocate.
• Destinații de rețea atinse sau blocate.
• Acreditări solicitate, emise, refuzate și expirate.
• Sunt create solicitări, comite, comentarii sau probleme.
• Rezultatul final al sarcinii: finalizată, abandonată, blocată, anulată sau escaladată.

Retenția necesită îngrijire. Urmările pot include cod proprietar, solicitări, ieșiri de instrumente, jurnalele de erori și fragmente de configurare sensibile. Decideți redactarea, eșantionarea, controlul accesului și păstrarea înainte de lansarea amplă. O urmă utilă pe care nimeni nu o poate accesa în siguranță nu va ajuta operațiunile.

Exemplu de politică: Agent de actualizare a documentației

O politică concretă face arhitectura mai ușor de evaluat. Luați în considerare un agent de actualizare a documentației utilizat de o echipă de inginerie a platformei.

Agentul poate:

• Citiți fișierele din depozitele de documentație aprobate.
• Creează o ramură temporară.
• Editați Markdown, exemplele și documentele generate.
• Exemple teste de documentare, verificări de linkuri și teste unitare.
• Utilizați un nivel de model aprobat cu un buget de activitate.
• Deschideți o solicitare de extragere atribuită dezvoltatorului solicitant.
• Apelați MCP instrumente aprobate pentru căutarea în depozit și căutarea problemelor.

Agentul nu poate:

• Accesați secretele de producție.
• Apăsați direct la ramura prestabilită.
• Publicați pachete sau imagini ale containerelor.
• Rulați comenzile de implementare a infrastructurii.
• Conectați-vă la gazde de ieșire arbitrare.
• Utilizați indicative privilegiate de control al sursei.
• Continuați după virajele maxime fără aprobare.

Această politică este în mod intenționat restrânsă. Încă face agentul util, dar limitează raza exploziei la un tip de lucru în care revizuirea și derularea înapoi sunt simple.

Pașii de implementare

Pasul 1: Suprafețele agenților de inventar

Enumerați fiecare loc în care agenții de codificare pot rula: pluginuri IDE, CLI instrumente, GitHub sau agenți Git furnizor, fluxuri de lucru CI, sandbox-uri gestionate, portaluri interne pentru dezvoltatori și scripturi experimentale. Includeți instrumente care sunt în prezent neoficiale. Adoptarea umbră este obișnuită atunci când echipele găsesc un agent util înainte ca echipa platformei să aibă un model de control.

Pasul 2: definiți clasele de activități

Grupați cazurile de utilizare în funcție de risc și permisiuni. Clasele de pornire utile includ modificări ale documentației, generarea testelor, explicația codului, actualizările dependenței, refactorizarea, analiza incidentelor, modificările infrastructurii și depanarea producției.

Fiecare clasă ar trebui să fie mapată cu arhivele permise, permisiuni de scriere, acces la rețea, instrumente, secrete, niveluri de model și reguli de aprobare.

Pasul 3: Standardizați identitatea agentului

Solicitați ca fiecare sarcină să transporte metadate pentru actor, echipă, depozit, mediu și ID-ul sarcinii. Dacă un instrument nu poate trece direct acele câmpuri, includeți-l cu un lansator, un proxy sau un broker care le poate atașa.

Pasul 4: puneți politica înainte de execuție

Începeți cu puncte de aplicare de mare valoare: acces la scriere la depozit, comenzi shell, MCP apeluri la instrumente, solicitări de acreditări, acces la rețea de ieșire și buget model. Înregistrarea fără aplicare este utilă în timpul descoperirii, dar nu este guvernare.

Pasul 5: scoateți secretele din cutii de nisip

Eliminați secretele statice din mediile de agenți. Utilizați un broker sau un flux de seif pentru acreditări de scurtă durată. Restricționați acreditările în funcție de destinație și scop și înregistrați emiterea și expirarea.

Pasul 6: Exportați telemetria în funcție de agent

Trimiteți utilizarea modelului, evenimentele de instrumente, aprobările comenzilor, activitatea din depozit, emiterea de acreditări și evenimentele din rețea în același plan de analiză. Scopul nu este doar revizuirea securității. De asemenea, echipele de inginerie și finanțe pot avea încredere în analiza utilizării AI.

Pasul 7: lansarea progresivă

Dezactivați accesul larg în mod prestabilit. Activați agenți pentru organizații, depozite sau clase de activități selectate. Începeți cu fluxuri de lucru de scriere doar în citire și cu risc scăzut, apoi extindeți-vă după ce funcționează jurnalele de audit, atribuirea costurilor și căile de aprobare.

Fapte, recomandări și predicții

Fapte: Platformele actuale de agenți expun deja controale care îndreaptă în această direcție. Documentația OpenAI separă cablajul agentului găzduit de mediile sandbox și documentează controalele sandbox pentru fișiere, pachete, execuție shell, MCP servere și acces la rețea de ieșire. GitHub documentează controalele întreprinderii pentru disponibilitatea agenților, sesiunile de agenți, evenimentele de audit, MCP utilizarea și politicile agentului de codificare. Anthropic documente Claude Modele de gateway de cod și proxy pentru autentificare centralizată, urmărire a utilizării, control al costurilor, jurnalizare de audit, rutare a modelului și rutare a rețelei corporative.

Recomandări: Tratați agenții de codare ca sarcini de lucru reglementate. Utilizați identitatea per agent sau pentru fiecare sarcină de lucru, izolați sandbox-urile, restricționați accesul la instrumente și la rețea, acreditările de broker, aplicați bugetul și limitele de rotație și exportați urmele la nivel de activitate. Puneți politica în fața execuției, nu numai în fața apelurilor model.

Predicții: Guvernarea agentului de codificare va deveni o responsabilitate standard de inginerie a platformei, pe măsură ce adoptarea trece de la dezvoltatorii individuali la lansarea la nivel de organizație. Controalele native ale furnizorului vor rămâne utile, dar întreprinderile care utilizează mai multe suprafețe de agenți și furnizori de modele vor avea nevoie de un nivel de normalizare pentru politici, raportare și atribuirea costurilor.

Compartimente

Un gateway central oferă echipelor de securitate, platformă și finanțe controale coerente, dar adaugă responsabilitate operațională. Echipa care deține gateway-ul trebuie să accepte instrumente pentru dezvoltatori care au fost adesea concepute pentru a se conecta direct la furnizori.

Sandbox-ul strict și izolarea rețelei reduc raza exploziei, dar pot întrerupe fluxurile de lucru reale. Instalările de pachete, registrele private, testele de integrare și documentația internă pot necesita acces la rețea. Răspunsul este de obicei acces restricționat cu observabilitate, nu o interdicție generală a rețelei.

Identitatea per agent îmbunătățește atribuirea și revocarea, dar are nevoie de automatizarea ciclului de viață. Gestionarea manuală a miilor de conturi de serviciu sau chei va eșua.

Secretele intermediate reduc expunerea, dar brokerul devine o infrastructură critică. Monitorizați-l ca pe un sistem de autentificare, deoarece emiterea eșuată a acreditărilor poate opri fluxurile de lucru ale agenților, iar emiterea excesivă poate crea riscuri de securitate.

Urmări detaliate ajută la depanare și conformare, dar pot captura cod și rezultate sensibile. Redactarea și controlul accesului nu sunt opțiuni suplimentare.

Concluzie acționabilă

Modul practic de a guverna agenții de codificare este să nu-i mai tratați ca sesiuni de chat cu o fereastră de context mai mare. Sunt sarcini de lucru autonome de inginerie cu acces la model, acces la sistem de fișiere, acces la instrumente, acces la depozit și, uneori, acces la acreditări.

Construiți poarta de acces în jurul acelei realități. Oferă fiecărei sarcini o identitate. Evaluați politica înainte de a rula instrumentele și comenzile shell. Izolați cutiile cu nisip. Păstrați secretele de lungă durată departe de mediu. Rutați apelurile model printr-un gateway controlat. Exportați urmele care conectează utilizarea simbolurilor cu acțiunile de inginerie reale.

Începe îngust: o suprafață de agent, o clasă de activități cu risc scăzut, un set de depozite, acces restricționat la rețea, fără secrete de producție și jurnale de audit la nivel de activitate. Extindeți numai atunci când planul de control poate arăta cine a făcut ce, ce instrumente au fost folosite, cât a costat și ce s-a schimbat.

Întrebări frecvente

Un agent de codare API gateway este același cu un gateway LLM?

Nu. Un gateway LLM controlează accesul la model, rutarea, utilizarea și costul. Un agent de codare API gateway guvernează, de asemenea, mediul de execuție din jurul modelului: depozite, comenzi shell, MCP instrumente, acreditări, acces la rețea, sandbox-uri, aprobări și urme sarcini.

Fiecare agent de codificare ar trebui să primească propria sa cheie API?

Nu neapărat o cheie de lungă durată. Modelul mai puternic este identitatea per agent sau per sarcină de lucru, cu acreditări de scurtă durată emise printr-un broker sau flux de identitate a sarcinii de lucru. Cerința importantă este atribuirea și revocarea la nivel de sarcină sau volum de muncă.

Unde ar trebui să aibă loc aplicarea politicii?

Politica trebuie aplicată înainte de apelurile modelului și înainte de executarea instrumentului. Scrierile din depozit, comenzile shell, MCP apeluri, solicitările de acreditări, publicarea pachetelor și accesul la rețea de ieșire necesită toate verificări ale politicii.

Care este cea mai sigură prima lansare?

Începeți cu sarcini de scriere doar în citire sau cu risc scăzut, cum ar fi actualizările documentației sau generarea de teste. Folosiți depozite restricționate, fără secrete de producție, bugete limitate de model, acces controlat la rețea și examinare a cererii de extragere înainte de îmbinare.

Lectură asociată

• Limite de cheltuieli la nivel de gateway pentru sarcinile de lucru ale agenților