Hur man bygger en Enterprise API Gateway för kodningsagenter

En kodningsagent är inte bara ytterligare en LLM-förfrågan. Den kan läsa källkod, ändra filer, köra skalkommandon, anropsverktyg, öppna pull-förfrågningar och fortsätta en uppgift över många modellvarv. Om exekveringsmiljön avslöjar hemligheter eller obegränsad nätverksåtkomst kan agenten även röra dem.

Det ändrar gatewayproblemet. En normal LLM-gateway kan autentisera API-samtal, ruttmodeller, mätartoken och upprätthålla utgiftsgränser. En kodningsagent API-gateway behöver dessa kontroller, men den måste också styra arbetsbelastningen kring modellanropet: lageråtkomst, sandlådeisolering, verktygsbehörigheter, utbyte av autentiseringsuppgifter, utgående nätverk, godkännandeflöden och revisionsspår på uppgiftsnivå.

Den här artikeln definierar en praktisk referensarkitektur för ett kontrollplan för företagskodningsagenter. Den är skriven för ingenjörsledare och plattformsteam som rullar ut agenter över IDE:er, GitHub arbetsflöden, CLI verktyg och hanterade sandlådor.

Kontrollplanets gräns

Gatewayen bör sitta mellan den mänskliga utvecklaren, agentens körtid, modellleverantörer, förråd, MCP servrar, hemliga butiker och interna nätverk. Det bör inte begränsas till att fullfölja chattslutföranden eller modellsvar.

I praktiken måste kontrollplanet svara på sju frågor före och under varje agentuppgift:

• Vem eller vad agerar den här agenten för?
• Vilka arkiv, filialer, filer och paketregister kan den komma åt?
• Vilka skalkommandon, MCP-verktyg och nätverksdestinationer är tillåtna?
• Vilka autentiseringsuppgifter kan utfärdas, i vilket syfte och hur länge?
• Vilka modellnivåer, budgetar och turgränser gäller?
• Vilka åtgärder kräver mänskligt godkännande?
• Vilka spårnings-, användnings- och granskningsposter måste exporteras?

Det gör kodningsagentens gateway till en del av den bredare enterprise LLM API-infrastrukturen, men med en annan tillämpningsyta. Modellanropet är bara ett steg i arbetsbelastningen.

Referensarkitektur

En fungerande arkitektur har sex lager: identitet, policy, sandlåda, referensmäklare, modellgateway och revisions- och användningsreskontra. Dessa lager kan implementeras med olika produkter, men ansvarsområdena bör förbli separata.

1. Identitetslager

Identitetslagret ger varje agentuppgift en hållbar identitet som kan tillskrivas, begränsas och återkallas. Undvik delade utvecklarnycklar API eller generiska tjänstkonton som får alla uppgifter att se likadana ut.

Åtminstone bör varje uppgift innehålla:

• Aktör: användaren, tjänsten eller automatiseringen som startade uppgiften.
• Agentyta: IDE-tillägg, CLI, GitHub-agent, CI-jobb eller hanterad sandlåda.
• Repository scope: organisation, arkiv, filial och arbetskatalog.
• Miljö: utveckling, test, iscensättning eller produktion.
• Team och kostnadsställe: för godkännande, rapportering och budgettillämpning.
• Task ID: en stabil identifierare för modellanrop, verktygsanrop, skalkommandon och pull-begäranaktivitet.

Det starkaste mönstret är identitet per agent eller per arbetsbelastning med kortlivade tokens. Arbetsbelastningsidentitetsfederation är användbar här eftersom agenten kan byta ut ett pålitligt påstående mot en kortlivad token istället för att bära en långlivad leverantörsnyckel. Använd dedikerade principer, exakt anspråksmatchning, minsta privilegium och separata produktions- och icke-produktionsidentiteter.

2. Policylager

Policylagret är beslutspunkten för arbetsbelastningen. Det bör utvärdera mer än modellåtkomst. En kodningsagent kan göra skada genom ett skalkommando, ett MCP-verktyg, ett paketpubliceringssteg eller ett nätverksanrop även när själva modellbegäran ser ofarlig ut.

Policyerna bör omfatta:

• Avståndslistor och filialbegränsningar.
• Behörigheter för att läsa, skriva, testa, utföra och dra begäranden.
• Tillåtna och otillåtna skalkommandoklasser.
• MCP serverupptäckt, anslutning och verktygsanrop.
• Utgående nätverksläge: inaktiverat, begränsat eller öppet av undantag.
• Hemlig åtkomst efter destination, syfte, miljö och livstid.
• Modellnivå, maxsvarv, max verktygsanrop och budgetgränser.
• Krav för mänskligt godkännande för riskfyllda handlingar.

Policybeslutspunkten bör anropas före verktygskörning, inte bara före modellanrop. Agenten kan till exempel tillåtas att be en modell om en migreringsplan, men blockeras från att köra ett produktionsdatabaskommando eller publicera ett paket.

3. Sandlåda lager

Sandlådan är exekveringsgränsen för filsystem, skal, paket och nätverksåtkomst. Det ska behandlas som en arbetsbelastningsmiljö, inte en bekvämlighetsbehållare.

En praktisk segmenteringsmodell är:

• Lågrisk skrivskyddade uppgifter: isolerade per användare eller arkiv, inga hemligheter, begränsat nätverk.
• Kodändringsuppgifter: isolerade skrivbara arbetsytor, tokens med förvarsomfattning, användaruppgifter endast för test.
• Infrastrukturuppgifter: separata härdade sandlådor, strikta godkännanden, inga produktionsstandarder.
• Produktionsangränsande uppgifter: sällsynta, tidsbundna, kraftigt loggade och isolerade från vanliga utvecklaragenter.

Låt inte orelaterade agenter dela skrivbara filsystem, cachar, autentiseringsuppgifter eller paketregister om inte den delingen är avsiktlig. Delade cachar kan förbättra hastigheten, men de skapar också kontaminering mellan olika uppgifter och gör kriminaltekniska analyser svårare.

Nätverksutgående ska vara explicit. Vissa uppgifter behöver paketregister, dokumentationswebbplatser, interna artefaktbutiker eller testtjänster. Det kräver inte godtycklig utgående åtkomst. Använd begränsade värdtillståndslistor där det är möjligt och logga faktiska destinationer.

4. Credential Broker

Autentiseringsmäklaren håller långlivade hemligheter utanför sandlådan. Agenten ska inte ta emot breda molnnycklar, administratörstoken för källkontroll eller produktionsapplikationshemligheter bara för att den körs i ett utvecklararbetsflöde.

Mäklaren bör utfärda kortlivade, omfångade autentiseringsuppgifter först efter policygodkännande. En begäran till mäklaren bör innehålla uppgiftens identitet, arkiv, destination, begärd behörighet och avsedd operation.

Användbara mäklarmönster inkluderar:

• Repository tokens begränsade till ett arkiv och kort utgångsdatum.
• Paketregistertokens begränsade till installationsåtgärder, inte publicering.
• Molnuppgifter begränsade till icke-produktionskonton och skrivskyddade åtgärder.
• Databasuppgifter begränsade till testmiljöer.
• Signerade webbadresser eller tillfälliga åtkomstbeviljande för specifika artefakter.

Mäklaren bör avslå vaga förfrågningar. "Ge den här agenten AWS-åtkomst" är inte en säker policyenhet. "Tillåt den här uppgiften att läsa en specifik lagringsväg för mellanlagringsobjekt i 15 minuter" är närmare en styrbar enhet.

5. B2B LLMway

Modellens gateway spelar fortfarande roll. Kodningsagenter kan generera hög tokenvolym genom planeringsslingor, upprepade filläsningar, testfel, verktygsutgångar och återförsök. Gatewayen bör hantera autentisering, modelldirigering, budgettillämpning, användningsmätning och leverantörsabstraktion.

För agentarbetsbelastningar, lägg till fält som en normal API-begäran kanske inte har:

• Id för agentuppgift.
• Sandlåde-ID.
• Förråd och filial.
• Antal samtal för verktyg.
• Max turn policy.
• Godkännandestatus.
• Risknivå.
• Förväntad uppgiftsklass, som uppdatering av dokument, testgenerering, refactor eller beroendeuppgradering.

Denna metadata gör att plattformsteamet kan jämföra kostnader och tillförlitlighet mellan uppgiftstyper snarare än att behandla all modellanvändning som en odifferentierad ström. Det låter också säkerhetsteam identifiera ovanliga användningsmönster, som att en dokumentationsagent ringer upprepade samtal i samband med infrastrukturförändringar.

6. Revisions- och användningsreskontra

En revisionsspår för kodningsagent måste koppla modellanrop med verkliga åtgärder. Enbart tokenanvändning räcker inte.

Exportera en uppgiftsspårning som inkluderar:

• Vem startade uppgiften och från vilken yta.
• Vilka modellleverantörer och modellnivåer som användes.
• Tokenanvändning, latens, fel och kostnadsuppskattningar.
• Förråd, filialer och filer berördes.
• Shell-kommandon föreslagna, godkända, nekade och körda.
• MCP servrar och verktyg anropade.
• Nätverksdestinationer nådde eller blockerade.
• Autentiseringsuppgifter har begärts, utfärdats, nekats och gått ut.
• Pull-förfrågningar, åtaganden, kommentarer eller problem skapade.
• Slutlig uppgiftsresultat: slutförd, övergiven, blockerad, återställd eller eskalerad.

Retention kräver vård. Spår kan inkludera egen kod, uppmaningar, verktygsutdata, felloggar och känsliga konfigurationsfragment. Bestäm redaktion, sampling, åtkomstkontroll och lagring innan bred utrullning. Ett användbart spår som ingen säkert kan komma åt hjälper inte verksamheten.

Exempelpolicy: Dokumentationsuppdateringsagent

En konkret policy gör arkitekturen lättare att utvärdera. Överväg en agent för dokumentationsuppdatering som används av ett plattformsteknikteam.

Agenten kan:

• Läs filer i godkända dokumentationsarkiv.
• Skapa en tillfällig filial.
• Redigera Markdown, exempel och genererade dokument.
• Kör dokumentationstester, länkkontroller och enhetstester för exempel.
• Använd en godkänd modellnivå med en uppgiftsbudget.
• Öppna en pull-begäran som tilldelats den begärande utvecklaren.
• Ring godkända MCP verktyg för arkivsökning och problemsökning.

Agenten får inte:

• Få åtkomst till produktionshemligheter.
• Push direkt till standardgrenen.
• Publicera paket eller behållarbilder.
• Kör kommandon för distribution av infrastruktur.
• Anslut till godtyckliga utgående värdar.
• Använd privilegierade källkontrolltokens.
• Fortsätt efter maxvarv utan godkännande.

Den här policyn är avsiktligt snäv. Det gör fortfarande agenten användbar, men den begränsar sprängradien till en arbetstyp där granskning och återställning är enkla.

Implementeringssteg

Steg 1: Inventory Agent Surfaces

Lista varje plats som kodningsagenter kan köra: IDE-plugin-program, CLI-verktyg, GitHub- eller Git-leverantörsagenter, CI-arbetsflöden, hanterade sandlådor, interna utvecklarportaler och experimentella skript. Inkludera verktyg som för närvarande är inofficiella. Skuggantagande är vanligt när team hittar en användbar agent innan plattformsteamet har en kontrollmodell.

Steg 2: Definiera uppgiftsklasser

Gruppera användningsfall efter risk och behörigheter. Användbara startklasser inkluderar dokumentationsändringar, testgenerering, kodförklaring, beroendeuppdateringar, refaktorering, incidentanalys, infrastrukturförändringar och produktionsfelsökning.

Varje klass bör mappa till tillåtna arkiv, skrivbehörigheter, nätverksåtkomst, verktyg, hemligheter, modellnivåer och godkännanderegler.

Steg 3: Standardisera agentidentitet

Kräv att varje uppgift bär metadata för aktör, team, arkiv, miljö och uppgifts-ID. Om ett verktyg inte kan passera dessa fält direkt, slå in det med en startprogram, proxy eller mäklare som kan bifoga dem.

Steg 4: Placera policy före exekvering

Börja med värdefulla tillsynspunkter: skrivåtkomst till förvar, skalkommandon, MCP verktygsanrop, autentiseringsbegäranden, utgående nätverksåtkomst och modellbudget. Loggning utan verkställighet är användbart vid upptäckt, men det är inte styrning.

Steg 5: Flytta hemligheter ur sandlådor

Ta bort statiska hemligheter från agentmiljöer. Använd en mäklare eller ett valvflöde för kortlivade referenser. Begränsa autentiseringsuppgifter efter destination och syfte, och logga utfärdande och utgång.

Steg 6: Exportera agentmedveten telemetri

Skicka modellanvändning, verktygshändelser, kommandogodkännanden, lagringsaktivitet, utfärdande av autentiseringsuppgifter och nätverkshändelser till samma analysplan. Målet är inte bara säkerhetsgranskning. Det är också AI-användningsanalyser som teknik- och ekonomiteam kan lita på.

Steg 7: Lansera gradvis

Inaktivera bred åtkomst som standard. Aktivera agenter för utvalda organisationer, arkiv eller uppgiftsklasser. Börja med skrivskyddade och skrivarbetsflöden med låg risk och expandera sedan efter att granskningsloggar, kostnadstillskrivning och godkännandevägar fungerar.

Fakta, rekommendationer och förutsägelser

Fakta: Nuvarande agentplattformar exponerar redan kontroller som pekar i denna riktning. OpenAI-dokumentationen skiljer den värdbaserade agentkabeln från sandlådemiljöer och dokumentsandlådekontroller för filer, paket, skalexekvering, MCP-servrar och utgående nätverksåtkomst. GitHub dokumenterar företagskontroller för agenttillgänglighet, agentsessioner, granskningshändelser, MCP användning och kodningsagentpolicyer. Anthropic dokument Claude Kodgateway och proxymönster för centraliserad autentisering, användningsspårning, kostnadskontroller, granskningsloggning, modellrouting och företagsnätverksrouting.

Rekommendationer: Behandla kodningsagenter som styrda arbetsbelastningar. Använd identitet per agent eller per arbetsbelastning, isolera sandlådor, begränsa verktygs- och nätverksåtkomst, mäklaruppgifter, upprätthåll budget- och turgränser och exportera spår på aktivitetsnivå. Sätt policy framför exekvering, inte bara framför modellanrop.

Förutsägelser: Styrning av kodningsagenter kommer att bli ett standardansvar för plattformsteknik när införandet går från enskilda utvecklare till en organisationsövergripande lansering. Leverantörsbaserade kontroller kommer att förbli användbara, men företag som använder flera agentytor och modellleverantörer kommer att behöva ett normaliseringslager för policy, rapportering och kostnadstillskrivning.

Avvägningar

En central gateway ger säkerhets-, plattforms- och ekonomiteam konsekventa kontroller, men den lägger till operativt ansvar. Teamet som äger gatewayen måste stödja utvecklarverktyg som ofta utformades för att ansluta direkt till leverantörer.

Strikt sandlåda och nätverksisolering minskar sprängradien, men de kan bryta verkliga arbetsflöden. Paketinstallationer, privata register, integrationstester och intern dokumentation kan alla kräva nätverksåtkomst. Svaret är vanligtvis begränsad åtkomst med observerbarhet, inte ett generellt nätverksförbud.

Per-agent-identitet förbättrar tillskrivning och återkallelse, men den behöver livscykelautomatisering. Manuell hantering av tusentals tjänstkonton eller nycklar kommer att misslyckas.

Förmedlade hemligheter minskar exponeringen, men mäklaren blir kritisk infrastruktur. Övervaka det som ett autentiseringssystem, eftersom misslyckad utfärdande av autentiseringsuppgifter kan stoppa agentarbetsflöden och överdriven utfärdande kan skapa säkerhetsrisk.

Detaljerade spår hjälper felsökning och efterlevnad, men de kan fånga känslig kod och utdata. Redigering och åtkomstkontroll är inte tillval.

Aktiveringsbar slutsats

Det praktiska sättet att styra kodningsagenter är att sluta behandla dem som chattsessioner med ett större sammanhangsfönster. De är autonoma tekniska arbetsbelastningar med modellåtkomst, filsystemåtkomst, verktygsåtkomst, arkivåtkomst och ibland autentiseringsåtkomst.

Bygg porten runt den verkligheten. Ge varje uppgift en identitet. Utvärdera policy innan verktyg och skalkommandon körs. Isolera sandlådor. Håll långlivade hemligheter borta från miljön. Route modellanrop genom en kontrollerad gateway. Exportera spår som kopplar tokenanvändning till verkliga tekniska åtgärder.

Börja smalt: en agentyta, en uppgiftsklass med låg risk, en uppsättning arkiv, begränsad nätverksåtkomst, inga produktionshemligheter och granskningsloggar på aktivitetsnivå. Expandera endast när kontrollplanet kan visa vem som gjorde vad, vilka verktyg som användes, vad det kostade och vad som ändrades.

FAQ

Är en kodningsagent API-gateway detsamma som en LLM-gateway?

Nej. En LLM-gateway styr modellåtkomst, routing, användning och kostnad. En kodningsagent API-gateway styr också exekveringsmiljön runt modellen: arkiv, skalkommandon, MCP-verktyg, autentiseringsuppgifter, nätverksåtkomst, sandlådor, godkännanden och uppgiftsspårningar.

Ska varje kodningsagent få sin egen API-nyckel?

Inte nödvändigtvis en nyckel med lång livslängd. Det starkare mönstret är identitet per agent eller per arbetsbelastning med kortlivade autentiseringsuppgifter utfärdade genom en mäklare eller arbetsbelastningsidentitetsflöde. Det viktiga kravet är tillskrivning och återkallelse på aktivitets- eller arbetsbelastningsnivå.

Var ska policytillämpningen ske?

Policy bör tillämpas före modellanrop och innan verktygskörning. Lagringsskrivningar, skalkommandon, MCP-anrop, autentiseringsbegäranden, paketpublicering och utgående nätverksåtkomst behöver alla policykontroller.

Vad är den säkraste första lanseringen?

Börja med skrivuppgifter eller skrivuppgifter med låg risk som dokumentationsuppdateringar eller testgenerering. Använd begränsade lagringsplatser, inga produktionshemligheter, begränsade modellbudgetar, kontrollerad nätverksåtkomst och granskning av pull-begäran före sammanslagning.

Relaterad läsning

• utgiftsgränser på gatewaynivå för agentarbetsbelastningar