Hvordan bygge en bedrifts API-gateway for kodingsagenter

En kodeagent er ikke bare en annen LLM-forespørsel. Den kan lese kildekode, endre filer, kjøre skallkommandoer, ringeverktøy, åpne pull-forespørsler og fortsette en oppgave på tvers av mange modellsvinger. Hvis utførelsesmiljøet avslører hemmeligheter eller ubegrenset nettverkstilgang, kan agenten også berøre disse.

Det endrer gatewayproblemet. En vanlig LLM-gateway kan autentisere API-anrop, rutemodeller, målersymboler og håndheve forbruksgrenser. En kodeagent API-gateway trenger disse kontrollene, men den må også styre arbeidsbelastningen rundt modellanropet: lagertilgang, sandkasseisolering, verktøytillatelser, utveksling av legitimasjon, utgang fra nettverk, godkjenningsflyter og revisjonsspor på oppgavenivå.

Denne artikkelen definerer en praktisk referansearkitektur for et kontrollplan for bedriftskodeagenter. Den er skrevet for ingeniørledere og plattformteam som ruller ut agenter på tvers av IDEer, GitHub arbeidsflyter, CLI verktøy og administrerte sandkasser.

The Control Plane Boundary

Gatewayen bør sitte mellom den menneskelige utvikleren, agentens kjøretid, modellleverandører, repositories, MCP servere, hemmelige butikker og interne nettverk. Det bør ikke være begrenset til fullføring av nettprat eller modellsvar.

I praksis må kontrollflyet svare på syv spørsmål før og under hver agentoppgave:

• Hvem eller hva opptrer denne agenten for?
• Hvilke depoter, filialer, filer og pakkeregistre kan den få tilgang til?
• Hvilke skallkommandoer, MCP-verktøy og nettverksdestinasjoner er tillatt?
• Hvilken legitimasjon kan utstedes, til hvilket formål og hvor lenge?
• Hvilke modellnivåer, budsjetter og turngrenser gjelder?
• Hvilke handlinger krever menneskelig godkjenning?
• Hvilke sporings-, bruks- og revisjonsposter må eksporteres?

Det gjør kodeagent-gatewayen til en del av bredere enterprise LLM API-infrastruktur, men med en annen håndhevingsoverflate. Modellanropet er bare ett trinn i arbeidsmengden.

Referansearkitektur

En brukbar arkitektur har seks lag: identitet, policy, sandkasse, legitimasjonsmegler, modellgateway og revisjons- og bruksreskontro. Disse lagene kan implementeres med forskjellige produkter, men ansvaret bør forbli atskilt.

1. Identitetslag

Identitetslaget gir hver agentoppgave en varig identitet som kan tilskrives, begrenses og oppheves. Unngå delte utviklernøkler API eller generiske tjenestekontoer som får alle oppgaver til å se like ut.

Minst hver oppgave bør inneholde:

• Aktør: brukeren, tjenesten eller automatiseringen som startet oppgaven.
• Agentoverflate: IDE-utvidelse, CLI, GitHub-agent, CI-jobb eller administrert sandkasse.
• Repository-omfang: organisasjon, repository, filial og arbeidskatalog.
• Miljø: utvikling, test, iscenesettelse eller produksjon.
• Team og kostnadssenter: for godkjenning, rapportering og budsjetthåndhevelse.
• Oppgave-ID: en stabil identifikator på tvers av modellanrop, verktøykall, shell-kommandoer og pull request-aktivitet.

Det sterkeste mønsteret er identitet per agent eller per arbeidsbelastning med kortvarige tokens. Arbeidsbelastningsidentitetsforbund er nyttig her fordi agenten kan bytte ut en pålitelig påstand mot et kortvarig token i stedet for å bære en langvarig leverandørnøkkel. Bruk dedikerte prinsipper, eksakt kravmatching, minste privilegium og separate produksjons- og ikke-produksjonsidentiteter.

2. Policylag

Retningslinjelaget er beslutningspunktet for arbeidsbelastningen. Den bør evaluere mer enn modelltilgang. En kodeagent kan gjøre skade gjennom en shell-kommando, et MCP-verktøy, et pakkepubliseringstrinn eller et nettverksanrop selv når selve modellforespørselen ser harmløs ut.

Retningslinjer bør dekke:

• Repository-godkjenningslister og filialbegrensninger.
• Lese, skrive, teste, forplikte og trekke forespørselstillatelser.
• Tillatte og ikke tillatte shell-kommandoklasser.
• MCP tjeneroppdagelse, tilkobling og verktøyoppkalling.
• Utgående nettverksmodus: deaktivert, begrenset eller åpen ved unntak.
• Hemmelig tilgang etter destinasjon, formål, miljø og levetid.
• Modellnivå, maks. svinger, maks. verktøykall og budsjettgrenser.
• Krav til menneskelig godkjenning for risikofylte handlinger.

Beslutningspunktet for retningslinjer bør kalles før verktøyutførelse, ikke bare før modellkall. Agenten kan for eksempel få lov til å be en modell om en migreringsplan, men blokkert fra å kjøre en produksjonsdatabasekommando eller publisere en pakke.

3. Sandkasselag

Sandkassen er utførelsesgrensen for filsystem-, skall-, pakke- og nettverkstilgang. Det bør behandles som et arbeidsbelastningsmiljø, ikke en bekvemmelighetsbeholder.

En praktisk segmenteringsmodell er:

• Lavrisiko skrivebeskyttede oppgaver: isolert per bruker eller depot, ingen hemmeligheter, begrenset nettverk.
• Kodeendringsoppgaver: isolerte skrivbare arbeidsområder, tokens med arkivomfang, legitimasjon for tester.
• Infrastrukturoppgaver: separate herdede sandkasser, strenge godkjenninger, ingen produksjonsstandarder.
• Produksjons-tilstøtende oppgaver: sjeldne, tidsbestemte, tungt logget og isolert fra vanlige utvikleragenter.

Ikke la urelaterte agenter dele skrivbare filsystemer, cacher, legitimasjon eller pakkeregistre med mindre den delingen er tilsiktet. Delte buffere kan øke hastigheten, men de skaper også kontaminering på tvers av oppgaver og gjør rettsmedisinske analyser vanskeligere.

Nettverksutgang bør være eksplisitt. Noen oppgaver trenger pakkeregistre, dokumentasjonssider, interne artefaktbutikker eller testtjenester. Det krever ikke vilkårlig utgående tilgang. Bruk begrensede vertsgodkjenningslister der det er mulig, og logg faktiske destinasjoner.

4. Legitimasjonsmegler

Legitimasjonsmegleren holder langvarige hemmeligheter utenfor sandkassen. Agenten skal ikke motta brede skynøkler, administratortokener for kildekontroll eller hemmeligheter for produksjonsapplikasjoner bare fordi den kjører i en utviklerarbeidsflyt.

Megleren bør kun utstede kortvarig, omfangsrik legitimasjon etter godkjenning av retningslinjer. En forespørsel til megleren bør inkludere oppgaveidentiteten, depotet, destinasjonen, forespurt tillatelse og tiltenkt operasjon.

Nyttige meglermønstre inkluderer:

• Repository tokens begrenset til ett depot og kort utløpstid.
• Pakkeregistertokener begrenset til installasjonsoperasjoner, ikke publisering.
• Cloud-legitimasjon begrenset til ikke-produksjonskontoer og skrivebeskyttede handlinger.
• Databaselegitimasjon begrenset til testmiljøer.
• Signerte nettadresser eller midlertidige tilgangsbevilgninger for spesifikke artefakter.

Megleren bør avslå vage forespørsler. "Gi denne agenten AWS-tilgang" er ikke en sikker policyenhet. «Tillat denne oppgaven å lese en bestemt lagringsbane for oppsamlingsobjekter i 15 minutter» er nærmere en styrbar enhet.

5. B2B LLMway

Modellens gateway er fortsatt viktig. Kodeagenter kan generere høyt tokenvolum gjennom planleggingsløkker, gjentatte fillesninger, testfeil, verktøyutganger og gjenforsøk. Gatewayen skal håndtere autentisering, modellruting, budsjetthåndhevelse, bruksmåling og leverandørabstraksjon.

For agentarbeidsbelastninger, legg til felt som en vanlig API-forespørsel kanskje ikke har:

• Agentoppgave-ID.
• Sandbox ID.
• Depot og filial.
• Anrop av verktøy.
• Retningslinjer for maksimal sving.
• Godkjenningsstatus.
• Risikonivå.
• Forventet oppgaveklasse, for eksempel dokumentoppdatering, testgenerering, refactor eller avhengighetsoppgradering.

Disse metadataene lar plattformteamet sammenligne kostnader og pålitelighet på tvers av oppgavetyper i stedet for å behandle all modellbruk som én udifferensiert strøm. Den lar også sikkerhetsteam identifisere uvanlige bruksmønstre, for eksempel en dokumentasjonsagent som foretar gjentatte anrop knyttet til infrastrukturendringer.

6. Revisjons- og bruksreskontro

Et revisjonsspor for kodeagenter må koble modellanrop med virkelige handlinger. Tokenbruk alene er ikke nok.

Eksporter en oppgavesporing som inkluderer:

• Hvem startet oppgaven og fra hvilken overflate.
• Hvilke modellleverandører og modellnivåer ble brukt.
• Tokenbruk, ventetid, feil og kostnadsanslag.
• Repositories, filialer og filer berørt.
• Shell-kommandoer foreslått, godkjent, avslått og utført.
• MCP servere og verktøy påkalt.
• Nettverksdestinasjoner nådd eller blokkert.
• Legitimasjon forespurt, utstedt, avslått og utløpt.
• Pull-forespørsler, forpliktelser, kommentarer eller problemer opprettet.
• Endelig oppgaveutfall: fullført, forlatt, blokkert, tilbakeført eller eskalert.

Oppbevaring trenger omsorg. Spor kan inkludere proprietær kode, meldinger, verktøyutganger, feillogger og sensitive konfigurasjonsfragmenter. Bestem redaksjon, sampling, tilgangskontroll og oppbevaring før bred utrulling. Et nyttig spor som ingen trygt kan få tilgang til, hjelper ikke driften.

Eksempel på retningslinjer: Agent for dokumentasjonsoppdatering

En konkret policy gjør arkitekturen enklere å evaluere. Vurder en dokumentasjonsoppdateringsagent som brukes av et plattformingeniørteam.

Agenten kan:

• Les filer i godkjente dokumentasjonslager.
• Opprett en midlertidig filial.
• Rediger Markdown, eksempler og genererte dokumenter.
• Kjør dokumentasjonstester, koblingskontroller og enhetstester for eksempler.
• Bruk et godkjent modellnivå med et oppgavebudsjett.
• Åpne en pull-forespørsel tildelt utvikleren som ber om.
• Ring godkjent MCP verktøy for repository-søk og problemoppslag.

Agenten kan ikke:

• Få tilgang til produksjonshemmeligheter.
• Push direkte til standardgrenen.
• Publiser pakker eller beholderbilder.
• Kjør kommandoer for distribusjon av infrastruktur.
• Koble til vilkårlige utgående verter.
• Bruk privilegerte kildekontrolltokener.
• Fortsett etter maksimale svinger uten godkjenning.

Denne policyen er med vilje begrenset. Det gjør fortsatt agenten nyttig, men den begrenser eksplosjonsradiusen til en arbeidstype der gjennomgang og tilbakeføring er enkel.

Implementeringstrinn

Trinn 1: Inventory Agent Surfaces

List opp alle steder som kodeagenter kan kjøre: IDE-plugin-moduler, CLI-verktøy, GitHub- eller Git-leverandøragenter, CI-arbeidsflyter, administrerte sandkasser, interne utviklerportaler og eksperimentelle skript. Inkluder verktøy som for øyeblikket er uoffisielle. Skyggeadopsjon er vanlig når team finner en nyttig agent før plattformteamet har en kontrollmodell.

Trinn 2: Definer oppgaveklasser

Grupper brukstilfeller etter risiko og tillatelser. Nyttige startklasser inkluderer dokumentasjonsendringer, testgenerering, kodeforklaring, avhengighetsoppdateringer, refaktorering, hendelsesanalyse, infrastrukturendringer og produksjonsfeilsøking.

Hver klasse bør kartlegge til tillatte repositorier, skrivetillatelser, nettverkstilgang, verktøy, hemmeligheter, modellnivåer og godkjenningsregler.

Trinn 3: Standardiser agentidentitet

Krever at hver oppgave bærer aktør-, team-, depot-, miljø- og oppgave-ID-metadata. Hvis et verktøy ikke kan sende disse feltene direkte, pakk det inn med en oppstarter, proxy eller megler som kan legge dem ved.

Trinn 4: Sett retningslinjer før utførelse

Start med høyverdige håndhevelsespunkter: skrivetilgang til depot, shell-kommandoer, MCP verktøykall, legitimasjonsforespørsler, utgående nettverkstilgang og modellbudsjett. Logging uten håndhevelse er nyttig under oppdagelse, men det er ikke styring.

Trinn 5: Flytt hemmeligheter ut av sandkasser

Fjern statiske hemmeligheter fra agentmiljøer. Bruk en megler eller hvelvflyt for kortvarig legitimasjon. Begrens legitimasjon etter destinasjon og formål, og logg utstedelse og utløp.

Trinn 6: Eksporter agentbevisst telemetri

Send modellbruk, verktøyhendelser, kommandogodkjenninger, arkivaktivitet, legitimasjonsutstedelse og nettverkshendelser til samme analyseplan. Målet er ikke bare sikkerhetsgjennomgang. Det er også AI-bruksanalyse som ingeniør- og økonomiteam kan stole på.

Trinn 7: Utrulling gradvis

Deaktiver bred tilgang som standard. Aktiver agenter for utvalgte organisasjoner, repositorier eller oppgaveklasser. Start med skrivebeskyttede og lavrisiko skrivearbeidsflyter, og utvid deretter etter at revisjonslogger, kostnadsattribusjon og godkjenningsbaner fungerer.

Fakta, anbefalinger og spådommer

Fakta: Nåværende agentplattformer viser allerede kontroller som peker i denne retningen. OpenAI-dokumentasjonen skiller den vertsbaserte agentselen fra sandkassemiljøer og dokumentersandkassekontroller for filer, pakker, skallutførelse, MCP-servere og utgående nettverkstilgang. GitHub dokumenterer bedriftskontroller for agenttilgjengelighet, agentøkter, revisjonshendelser, MCP bruk og retningslinjer for koding av agenter. Anthropic dokumenter Claude Kodegateway og proxy-mønstre for sentralisert autentisering, brukssporing, kostnadskontroller, revisjonslogging, modellruting og bedriftsnettverksruting.

Anbefalinger: Behandle kodingsagenter som styrte arbeidsbelastninger. Bruk identitet per agent eller per arbeidsbelastning, isoler sandkasser, begrens verktøy- og nettverkstilgang, meglerlegitimasjon, håndhev budsjett- og turngrenser, og eksporter spor på oppgavenivå. Sett retningslinjer foran utførelse, ikke bare foran modellanrop.

Spådommer: Styring av kodeagenter vil bli et standard plattformingeniøransvar etter hvert som bruken går fra individuelle utviklere til utrulling for hele organisasjonen. Leverandørinnbygde kontroller vil fortsatt være nyttige, men bedrifter som bruker flere agentoverflater og modellleverandører vil trenge et normaliseringslag for retningslinjer, rapportering og kostnadsattribusjon.

Trade-offs

En sentral gateway gir sikkerhets-, plattform- og økonomiteam konsekvente kontroller, men den legger til driftsansvar. Teamet som eier gatewayen må støtte utviklerverktøy som ofte ble utviklet for å koble direkte til leverandører.

Streng sandkasse- og nettverksisolasjon reduserer eksplosjonsradius, men de kan bryte ekte arbeidsflyter. Pakkeinstallasjoner, private registre, integrasjonstester og intern dokumentasjon kan alle kreve nettverkstilgang. Svaret er vanligvis begrenset tilgang med observerbarhet, ikke et generelt nettverksforbud.

Per-agent identitet forbedrer attribusjon og tilbakekalling, men den trenger livssyklusautomatisering. Manuell administrasjon av tusenvis av tjenestekontoer eller nøkler vil mislykkes.

Meglede hemmeligheter reduserer eksponeringen, men megleren blir kritisk infrastruktur. Overvåk det som et autentiseringssystem, fordi mislykket utstedelse av legitimasjon kan stoppe agentarbeidsflyter og overdreven utstedelse kan skape sikkerhetsrisiko.

Detaljerte spor hjelper feilsøking og samsvar, men de kan fange opp sensitiv kode og utdata. Redaksjon og tilgangskontroll er ikke tilleggsutstyr.

Handlingsbar konklusjon

Den praktiske måten å styre kodeagenter på er å slutte å behandle dem som chatteøkter med et større kontekstvindu. De er autonome tekniske arbeidsbelastninger med modelltilgang, filsystemtilgang, verktøytilgang, arkivtilgang og noen ganger legitimasjonstilgang.

Bygg porten rundt denne virkeligheten. Gi hver oppgave en identitet. Evaluer policy før verktøy og skallkommandoer kjøres. Isoler sandkasser. Hold langvarige hemmeligheter borte fra miljøet. Rute modellanrop gjennom en kontrollert gateway. Eksporter spor som kobler tokenbruk til ekte tekniske handlinger.

Begynn smalt: én agentoverflate, én oppgaveklasse med lav risiko, ett sett med repositorier, begrenset nettverkstilgang, ingen produksjonshemmeligheter og revisjonslogger på oppgavenivå. Utvid bare når kontrollplanet kan vise hvem som gjorde hva, hvilke verktøy som ble brukt, hva det kostet og hva som ble endret.

Vanlige spørsmål

Er en kodeagent API-gateway det samme som en LLM-gateway?

Nei. En LLM-gateway kontrollerer modelltilgang, ruting, bruk og kostnader. En kodeagent API-gateway styrer også utførelsesmiljøet rundt modellen: repositories, shell-kommandoer, MCP-verktøy, legitimasjon, nettverkstilgang, sandkasser, godkjenninger og oppgavespor.

Skal hver kodeagent få sin egen API-nøkkel?

Ikke nødvendigvis en nøkkel med lang levetid. Det sterkere mønsteret er identitet per agent eller per arbeidsbelastning med kortvarig legitimasjon utstedt gjennom en megler- eller arbeidsbelastningsidentitetsflyt. Det viktige kravet er attribusjon og tilbakekalling på oppgave- eller arbeidsbelastningsnivå.

Hvor bør håndhevelsen av retningslinjene skje?

Retningslinjer bør håndheves før modellkall og før verktøykjøring. Repository-skriving, shell-kommandoer, MCP-anrop, legitimasjonsforespørsler, pakkepublisering og utgående nettverkstilgang trenger alle policysjekker.

Hva er den sikreste første utrullingen?

Start med skrivebeskyttet eller lavrisiko skriveoppgaver som dokumentasjonsoppdateringer eller testgenerering. Bruk begrensede repositories, ingen produksjonshemmeligheter, begrensede modellbudsjetter, kontrollert nettverkstilgang og gjennomgang av pull-forespørsel før sammenslåing.

Relatert lesing

• bruksgrenser på gateway-nivå for agentarbeidsbelastninger