Kodlama Aracıları için Kurumsal API Ağ Geçidi Nasıl Oluşturulur

Kodlama temsilcisi sıradan bir Yüksek Lisans isteği değildir. Kaynak kodunu okuyabilir, dosyaları değiştirebilir, kabuk komutlarını çalıştırabilir, araçları çağırabilir, çekme isteklerini açabilir ve birçok model dönüşünde bir göreve devam edebilir. Yürütme ortamı sırları veya sınırsız ağ erişimini açığa çıkarırsa aracı bunlara da dokunabilir.

Bu, ağ geçidi sorununu değiştirir. Normal bir LLM ağ geçidi, API çağrının kimliğini doğrulayabilir, modelleri yönlendirebilir, belirteçleri ölçebilir ve harcama sınırlarını uygulayabilir. Kodlama aracısı API ağ geçidinin bu kontrollere ihtiyacı vardır, ancak aynı zamanda model çağrısı etrafındaki iş yükünü de yönetmesi gerekir: veri havuzu erişimi, korumalı alan izolasyonu, araç izinleri, kimlik bilgisi değişimi, ağ çıkışı, onay akışları ve görev düzeyinde denetim yolları.

Bu makale, kurumsal kodlama aracısı kontrol düzlemi için pratik bir referans mimarisini tanımlamaktadır. IDE'ler, GitHub iş akışları, CLI araçlar ve yönetilen sanal alanlar genelinde aracıları kullanıma sunan mühendislik liderleri ve platform ekipleri için yazılmıştır.

Kontrol Düzlemi Sınırı

Ağ geçidi, insan geliştirici, aracı çalışma zamanı, model sağlayıcılar, depolar, MCP sunucular, gizli depolar ve dahili ağlar arasında bulunmalıdır. Bu, sohbet tamamlama işlemlerinin proxylenmesi veya model yanıtlarıyla sınırlı olmamalıdır.

Uygulamada, kontrol düzleminin her temsilci görevi öncesinde ve sırasında yedi soruyu yanıtlaması gerekir:

• Bu temsilci kimin veya ne adına hareket ediyor?
• Hangi depolara, dallara, dosyalara ve paket kayıtlarına erişebilir?
• Hangi kabuk komutlarına, MCP araçlara ve ağ hedeflerine izin veriliyor?
• Hangi kimlik bilgileri, hangi amaçla ve ne kadar süreyle verilebilir?
• Hangi model katmanları, bütçeler ve dönüş sınırları geçerlidir?
• Hangi işlemler insan onayı gerektirir?
• Hangi izleme, kullanım ve denetim kayıtları dışa aktarılmalıdır?

Bu, kodlama aracısı ağ geçidini daha geniş kurumsal LLM API altyapısının parçası haline getirir, ancak farklı bir uygulama yüzeyine sahiptir. Model çağrısı iş yükünün yalnızca bir adımıdır.

Referans Mimarisi

Çalışabilir bir mimarinin altı katmanı vardır: kimlik, politika, korumalı alan, kimlik bilgisi aracısı, model ağ geçidi ve denetim ve kullanım defteri. Bu katmanlar farklı ürünlerle uygulanabilir ancak sorumluluklar ayrı kalmalıdır.

1. Kimlik Katmanı

Kimlik katmanı, her aracı görevine atfedilebilecek, sınırlandırılabilecek ve iptal edilebilecek dayanıklı bir kimlik verir. Her görevin aynı görünmesini sağlayan paylaşılan geliştirici API anahtarlarından veya genel hizmet hesaplarından kaçının.

Her görev en azından şunları taşımalıdır:

• İşlemci: görevi başlatan kullanıcı, hizmet veya otomasyon.
• Aracı yüzeyi: IDE uzantısı, CLI, GitHub aracı, CI işi veya yönetilen korumalı alan.
• Depo kapsamı: organizasyon, veri deposu, şube ve çalışma dizini.
• Ortam: geliştirme, test, hazırlama veya üretim.
• Ekip ve maliyet merkezi: onay, raporlama ve bütçe uygulaması için.
• Görev Kimliği: model çağrıları, araç çağrıları, kabuk komutları ve çekme isteği etkinliği arasında kararlı bir tanımlayıcı.

En güçlü model, kısa ömürlü jetonlarla aracı başına veya iş yükü başına kimliktir. İş yükü kimlik federasyonu burada faydalıdır çünkü aracı, uzun ömürlü bir sağlayıcı anahtarı taşımak yerine güvenilir bir onayı kısa ömürlü bir belirteçle değiştirebilir. Özel sorumluları, tam talep eşleştirmeyi, en az ayrıcalığı ve ayrı üretim ve üretim dışı kimlikleri kullanın.

2. Politika Katmanı

Politika katmanı iş yüküne ilişkin karar noktasıdır. Model erişiminden daha fazlasını değerlendirmelidir. Bir kodlama aracısı, model isteğinin kendisi zararsız görünse bile bir kabuk komutu, bir MCP aracı, bir paket yayınlama adımı veya bir ağ çağrısı yoluyla zarar verebilir.

Politikalar şunları kapsamalıdır:

• Depo izin verilenler listeleri ve şube kısıtlamaları.
• İstek izinlerini okuma, yazma, test etme, işleme ve çekme izinleri.
• İzin verilen ve izin verilmeyen kabuk komut sınıfları.
• MCP sunucu keşfi, bağlantı ve araç çağırma.
• Giden ağ modu: devre dışı, kısıtlanmış veya istisnaya göre açık.
• Hedefe, amaca, ortama ve kullanım ömrüne göre gizli erişim.
• Model katmanı, maksimum dönüşler, maksimum araç çağrıları ve bütçe sınırları.
• Riskli işlemler için insan onayı gereksinimleri.

Politika karar noktası, yalnızca model çağrılmasından önce değil, aracın yürütülmesinden önce de çağrılmalıdır. Örneğin, aracının bir geçiş planı için model istemesine izin verilebilir, ancak bir üretim veritabanı komutunu çalıştırması veya bir paket yayınlaması engellenebilir.

3. Korumalı Alan Katmanı

Korumalı alan, dosya sistemi, kabuk, paket ve ağ erişimi için yürütme sınırıdır. Kolaylık sağlayan bir kapsayıcı olarak değil, bir iş yükü ortamı olarak ele alınmalıdır.

Pratik bir segmentasyon modeli:

• Düşük riskli salt okunur görevler: Kullanıcı veya depo başına yalıtılmış, gizli bilgi içermeyen, kısıtlı ağ.
• Kod değişikliği görevleri: izole edilmiş yazılabilir çalışma alanları, depo kapsamındaki jetonlar, yalnızca test amaçlı kimlik bilgileri.
• Altyapı görevleri: ayrı güçlendirilmiş sanal alanlar, katı onaylar, üretim varsayılanlarının olmaması.
• Üretime bitişik görevler: nadir, zamana bağlı, yoğun şekilde günlüğe kaydedilen ve normal geliştirici aracılarından izole edilmiş.

İlgisiz aracıların yazılabilir dosya sistemlerini, önbellekleri, kimlik bilgilerini veya paket kayıtlarını kasıtlı olarak paylaşmadığı sürece paylaşmasına izin vermeyin. Paylaşılan önbellekler hızı artırabilir, ancak aynı zamanda görevler arası kontaminasyona da neden olur ve adli analizleri zorlaştırır.

Ağ çıkışı açık olmalıdır. Bazı görevler paket kayıtlarına, dokümantasyon sitelerine, dahili yapı depolarına veya test hizmetlerine ihtiyaç duyar. Bu, keyfi giden erişim gerektirmez. Mümkün olduğunda kısıtlı ana makine izin verilenler listelerini kullanın ve gerçek hedefleri günlüğe kaydedin.

4. Kimlik Bilgisi Aracısı

Kimlik bilgisi aracısı, uzun ömürlü sırları korumalı alanın dışında tutar. Aracı, yalnızca bir geliştirici iş akışında çalıştığı için geniş bulut anahtarlarını, kaynak kontrolü yönetici belirteçlerini veya üretim uygulaması sırlarını almamalıdır.

Aracı, yalnızca politika onayından sonra kısa ömürlü, kapsamlı kimlik bilgileri sağlamalıdır. Aracıya yapılan bir istek, görev kimliğini, depoyu, hedefi, istenen izni ve amaçlanan işlemi içermelidir.

Yararlı aracı modelleri şunları içerir:

• Depo jetonları tek bir depoyla sınırlıdır ve geçerlilik süreleri kısadır.
• Kayıt defteri jetonlarını paketleyin, yayınlamayla değil, yükleme işlemleriyle sınırlıdır.
• Bulut kimlik bilgileri, üretim dışı hesaplar ve salt okunur işlemlerle sınırlıdır.
• Veritabanı kimlik bilgileri test ortamlarıyla sınırlıdır.
• Belirli yapılar için imzalı URL'ler veya geçici erişim izinleri.

Aracının belirsiz istekleri reddetmesi gerekir. “Bu aracıya AWS erişimi ver” güvenli bir politika birimi değildir. "Bu görevin belirli bir hazırlama nesnesi deposu yolunu 15 dakika boyunca okumasına izin ver", yönetilebilir bir birime daha yakındır.

5. Model Ağ Geçidi

Model ağ geçidi hâlâ önemlidir. Kodlama aracıları, planlama döngüleri, tekrarlanan dosya okumaları, test hataları, araç çıktıları ve yeniden denemeler aracılığıyla yüksek token hacmi oluşturabilir. Ağ geçidi, kimlik doğrulama, model yönlendirme, bütçe uygulama, kullanım ölçümü ve sağlayıcı soyutlamasını gerçekleştirmelidir.

Ajan iş yükleri için, normal bir API isteğinde bulunamayan alanları ekleyin:

• Ajan görev kimliği.
• Korumalı Alan Kimliği.
• Depo ve şube.
• Araç çağrı sayısı.
• Maksimum dönüş politikası.
• Onay durumu.
• Risk katmanı.
• Belge güncellemesi, test oluşturma, yeniden düzenleme veya bağımlılık yükseltme gibi beklenen görev sınıfı.

Bu meta veriler, tüm model kullanımını farklılaştırılmamış tek bir akış olarak ele almak yerine, platform ekibinin görev türleri arasında maliyet ve güvenilirliği karşılaştırmasına olanak tanır. Ayrıca güvenlik ekiplerinin, bir dokümantasyon aracısının altyapı değişiklikleriyle ilişkili tekrarlanan aramalar yapması gibi olağandışı kullanım kalıplarını tespit etmesine de olanak tanır.

6. Denetim ve Kullanım Defteri

Kodlama aracısı denetim takibinin model çağrılarını gerçek eylemlerle bağlaması gerekir. Jeton kullanımı tek başına yeterli değildir.

Şunları içeren bir görev izlemeyi dışa aktarın:

• Görevi kim, hangi yüzeyden başlattı.
• Hangi model sağlayıcıları ve model katmanları kullanıldı?
• Jeton kullanımı, gecikme, hatalar ve maliyet tahminleri.
• Depolara, dallara ve dosyalara dokunuldu.
• Kabuk komutları önerildi, onaylandı, reddedildi ve yürütüldü.
• MCP sunucu ve araç çağrıldı.
• Ağ hedeflerine ulaşıldı veya engellendi.
• Kimlik bilgileri istendi, verildi, reddedildi ve süresi doldu.
• Pull istekleri, taahhütler, yorumlar veya oluşturulan sorunlar.
• Nihai görev sonucu: tamamlandı, terk edildi, engellendi, geri alındı veya iletildi.

Saklamanın özen gösterilmesi gerekiyor. İzler; özel kod, istemler, araç çıktıları, hata günlükleri ve hassas yapılandırma parçalarını içerebilir. Geniş kullanıma sunmadan önce redaksiyona, örneklemeye, erişim kontrolüne ve saklamaya karar verin. Hiç kimsenin güvenli bir şekilde erişemeyeceği yararlı bir iz, operasyonlara yardımcı olmaz.

Örnek Politika: Dokümantasyon Güncelleme Aracısı

Somut bir politika, mimarinin değerlendirilmesini kolaylaştırır. Bir platform mühendisliği ekibi tarafından kullanılan bir dokümantasyon güncelleme aracısını düşünün.

Acente şunları yapabilir:

• Onaylı dokümantasyon depolarındaki dosyaları okuyun.
• Geçici bir şube oluşturun.
• Markdown'ı, örnekleri ve oluşturulan dokümanları düzenleyin.
• Örnekler için dokümantasyon testleri, bağlantı kontrolleri ve birim testleri çalıştırın.
• Görev bütçesiyle onaylanmış bir model katmanı kullanın.
• İstekte bulunan geliştiriciye atanan çekme isteğini açın.
• Depo araması ve sorun arama için onaylanmış MCP araçları arayın.

Acente şunları yapamaz:

• Üretim sırlarına erişin.
• Doğrudan varsayılan şubeye aktarın.
• Paketleri veya kapsayıcı resimlerini yayınlayın.
• Altyapı dağıtım komutlarını çalıştırın.
• İsteğe bağlı giden ana makinelere bağlanın.
• Ayrıcalıklı kaynak kontrolü jetonlarını kullanın.
• Maksimum dönüşten sonra onay almadan devam edin.

Bu politika kasıtlı olarak daraltılmıştır. Bu, aracıyı yine de kullanışlı kılar ancak patlama yarıçapını, inceleme ve geri almanın kolay olduğu bir iş türüyle sınırlar.

Uygulama Adımları

1. Adım: Envanter Aracısı Yüzeyleri

Kodlama aracılarının çalıştırabileceği her yeri listeleyin: IDE eklentileri, CLI araçları, GitHub veya Git sağlayıcı aracıları, CI iş akışları, yönetilen sanal alanlar, dahili geliştirici portalları ve deneysel komut dosyaları. Şu anda resmi olmayan araçları ekleyin. Platform ekibi bir kontrol modeline sahip olmadan önce ekiplerin yararlı bir aracı bulması durumunda gölgenin benimsenmesi yaygındır.

2. Adım: Görev Sınıflarını Tanımlayın

Kullanım örneklerini riske ve izinlere göre gruplandırın. Yararlı başlangıç sınıfları arasında dokümantasyon değişiklikleri, test oluşturma, kod açıklaması, bağımlılık güncellemeleri, yeniden düzenleme, olay analizi, altyapı değişiklikleri ve üretimde hata ayıklama yer alır.

Her sınıf, izin verilen veri havuzları, yazma izinleri, ağ erişimi, araçlar, gizli diziler, model katmanları ve onay kurallarıyla eşlenmelidir.

3. Adım: Temsilci Kimliğini Standartlaştırın

Her görevin aktör, ekip, veri deposu, ortam ve görev kimliği meta verilerini taşımasını zorunlu kılın. Bir araç bu alanları doğrudan aktaramazsa aracı, bunları ekleyebilecek bir başlatıcı, proxy veya aracıyla sarın.

4. Adım: Politikayı Yürütmeden Önce Yerleştirin

Yüksek değerli uygulama noktalarıyla başlayın: veri havuzu yazma erişimi, kabuk komutları, MCP araç çağrıları, kimlik bilgisi istekleri, giden ağ erişimi ve model bütçesi. Zorunluluk olmadan günlüğe kaydetme, keşif sırasında faydalıdır ancak yönetim değildir.

5. Adım: Sırları Korumalı Alanlardan Çıkarın

Ajan ortamlarından statik gizli dizileri kaldırın. Kısa ömürlü kimlik bilgileri için bir aracı veya kasa akışı kullanın. Kimlik bilgilerini hedefe ve amaca, günlük düzenlemeye ve geçerlilik süresine göre kısıtlayın.

6. Adım: Aracı Bilgili Telemetriyi Dışa Aktarın

Model kullanımını, araç etkinliklerini, komut onaylarını, veri havuzu etkinliğini, kimlik bilgilerinin verilmesini ve ağ etkinliklerini aynı analiz düzlemine gönderin. Amaç sadece güvenlik incelemesi değildir. Aynı zamanda mühendislik ve finans ekiplerinin güvenebileceği şey yapay zeka kullanım analizleridir.

7. Adım: Aşamalı Olarak Kullanıma Sunma

Geniş erişimi varsayılan olarak devre dışı bırakın. Seçilen kuruluşlar, depolar veya görev sınıfları için aracıları etkinleştirin. Salt okunur ve düşük riskli yazma iş akışlarıyla başlayın, ardından denetim günlükleri, maliyet ilişkilendirme ve onay yolları çalışmaya başladıktan sonra genişletin.

Gerçekler, Öneriler ve Tahminler

Gerçekler: Mevcut aracı platformları bu yöne işaret eden kontrolleri zaten açığa çıkarıyor. OpenAI belgeleri, barındırılan aracı donanımını korumalı alan ortamlarından ayırır ve dosyalar, paketler, kabuk yürütme, MCP sunucuları ve giden ağ erişimi için sanal alan kontrollerini belgeler. GitHub aracı kullanılabilirliği, aracı oturumları, denetim etkinlikleri, MCP kullanımı ve aracı politikalarının kodlanması için kurumsal kontrolleri belgelemektedir. Anthropic belgeler Claude Merkezi kimlik doğrulama, kullanım izleme, maliyet kontrolleri, denetim günlüğü tutma, model yönlendirme ve kurumsal ağ yönlendirme için kod ağ geçidi ve proxy modelleri.

Öneriler: Kodlama aracılarına, yönetilen iş yükleri gibi davranın. Aracı başına veya iş yükü başına kimlik kullanın, korumalı alanları izole edin, araç ve ağ erişimini, aracı kimlik bilgilerini kısıtlayın, bütçe ve dönüş sınırlarını uygulayın ve görev düzeyinde izlemeleri dışa aktarın. Politikayı yalnızca model çağrılarının önüne değil, yürütmenin de önüne koyun.

Tahminler: Benimseme bireysel geliştiricilerden kuruluş çapında kullanıma sunuldukça, kodlama aracısı yönetimi standart bir platform mühendisliği sorumluluğu haline gelecektir. Sağlayıcıya özgü kontroller yararlı olmaya devam edecek ancak birden fazla aracı yüzeyi ve model sağlayıcı kullanan kuruluşların politika, raporlama ve maliyet ilişkilendirme için bir normalleştirme katmanına ihtiyacı olacak.

Ödünleşmeler

Merkezi bir ağ geçidi, güvenlik, platform ve finans ekiplerine tutarlı kontroller sağlar ancak operasyonel sorumluluk da ekler. Ağ geçidinin sahibi olan ekibin, genellikle sağlayıcılara doğrudan bağlanmak üzere tasarlanmış geliştirici araçlarını desteklemesi gerekir.

Katı korumalı alan ve ağ izolasyonu, patlama etki alanını azaltır ancak gerçek iş akışlarını bozabilir. Paket yüklemeleri, özel kayıtlar, entegrasyon testleri ve dahili belgelerin tümü ağ erişimi gerektirebilir. Bunun yanıtı genellikle genel ağ yasağı değil, gözlemlenebilirlikle sınırlı erişimdir.

Temsilci başına kimlik, ilişkilendirme ve iptali iyileştirir ancak yaşam döngüsü otomasyonuna ihtiyaç duyar. Binlerce hizmet hesabını veya anahtarı manuel olarak yönetmek başarısız olur.

Aracılı sırlar açığa çıkmayı azaltır ancak aracı kritik bir altyapı haline gelir. Bunu bir kimlik doğrulama sistemi gibi izleyin çünkü başarısız kimlik bilgisi verilmesi aracı iş akışlarını durdurabilir ve aşırı kimlik bilgisi verilmesi güvenlik riski oluşturabilir.

Ayrıntılı izlemeler hata ayıklamaya ve uyumluluğa yardımcı olur ancak hassas kod ve çıktıları yakalayabilir. Redaksiyon ve erişim kontrolü isteğe bağlı ekstralar değildir.

Uygulanabilir Sonuç

Kodlama aracılarını yönetmenin pratik yolu, onları daha büyük bir bağlam penceresine sahip sohbet oturumları olarak ele almayı bırakmaktır. Bunlar, model erişimi, dosya sistemi erişimi, araç erişimi, veri havuzu erişimi ve bazen kimlik bilgileri erişimine sahip özerk mühendislik iş yükleridir.

Ağ geçidini bu gerçekliğin etrafında inşa edin. Her göreve bir kimlik verin. Araçlar ve kabuk komutları çalıştırılmadan önce politikayı değerlendirin. Korumalı alanları izole edin. Uzun ömürlü sırları çevreden uzak tutun. Model çağrılarını kontrollü bir ağ geçidi üzerinden yönlendirin. Belirteç kullanımını gerçek mühendislik eylemlerine bağlayan izleri dışa aktarın.

Daraltmaya başlayın: bir aracı yüzeyi, bir düşük riskli görev sınıfı, bir veri havuzu seti, kısıtlı ağ erişimi, üretim sırrı yok ve görev düzeyinde denetim günlükleri. Yalnızca kontrol düzlemi kimin neyi yaptığını, hangi araçların kullanıldığını, maliyetini ve nelerin değiştiğini gösterebildiğinde genişletin.

SSS

Kodlama aracısı API ağ geçidi, LLM ağ geçidiyle aynı mıdır?

Hayır. Bir LLM ağ geçidi model erişimini, yönlendirmeyi, kullanımı ve maliyeti kontrol eder. Kodlama aracısı API ağ geçidi aynı zamanda model etrafındaki yürütme ortamını da yönetir: depolar, kabuk komutları, MCP araçları, kimlik bilgileri, ağ erişimi, korumalı alanlar, onaylar ve görev izleri.

Her kodlama aracısının kendi API anahtarına sahip olması gerekir mi?

Mutlaka uzun ömürlü bir anahtar olması gerekmez. Daha güçlü model, bir aracı veya iş yükü kimlik akışı aracılığıyla verilen kısa ömürlü kimlik bilgilerine sahip aracı başına veya iş yükü başına kimliktir. Önemli gereksinim, görev veya iş yükü düzeyinde ilişkilendirme ve iptaldir.

Politika yaptırımı nerede gerçekleşmeli?

Politika, model çağrılmadan ve araç çalıştırılmadan önce uygulanmalıdır. Depo yazma işlemleri, kabuk komutları, MCP çağrıları, kimlik bilgisi istekleri, paket yayınlama ve giden ağ erişiminin tümü politika kontrolleri gerektirir.

En güvenli ilk kullanıma sunma yöntemi nedir?

Belge güncellemeleri veya test oluşturma gibi salt okunur veya düşük riskli yazma görevleriyle başlayın. Kısıtlı depolar kullanın, üretim sırrı kullanmayın, sınırlı model bütçeleri, kontrollü ağ erişimi ve birleştirme öncesinde çekme isteği incelemesi kullanın.

İlgili okumalar

• ajan iş yükleri için ağ geçidi düzeyinde harcama sınırları