AI Ajanlarına Deploy Yetkisi Vermeden Önce: Temporary Credential, Onay Kapısı ve Blast Radius

Diğer

Yapay zeka destekli geliştirme birkaç ay içinde "kod öneren yardımcı" seviyesinden çıkıp doğrudan iş yapan ajan seviyesine geldi. Bugün birçok ekip için mesele artık AI'ın kod yazıp yazamadığı değil. Asıl mesele, bu ajanların ne kadar ileri gideceği. Kod yazması mı? Test çalıştırması mı? Pull request açması mı? Yoksa doğrudan deploy etmesi mi?

Bence kırılma noktası tam burada başlıyor.

Çünkü AI ajanına deploy yetkisi vermek, geliştirici verimliliği kararı olmaktan çok daha fazlası. Bu; kimlik, yetkilendirme, geçici erişim, geri alınabilirlik, gözlemlenebilirlik ve hata yarıçapı tasarımı meselesi. Kısacası doğrudan bir yazılım mimarisi ve güvenlik mühendisliği konusu.

Son günlerde bu alanı ciddiye alan birkaç önemli sinyal geldi. Cloudflare, ajanların insan odaklı kimlik akışlarında takılmaması için geçici hesaplarla deploy yapabilmesini sağlayan bir model duyurdu. GitHub, Copilot code review tarafında repository kökünden AGENTS.md okuyarak ekip kurallarını inceleme akışına dahil etmeye başladı. Google ise ajanların birbirini, araçları ve yetenek kataloglarını güvenli biçimde keşfetmesi için Agentic Resource Discovery ve A2A etrafında daha sistematik bir çerçeve kuruyor.

Bu gelişmeleri yan yana koyunca tablo netleşiyor: 2026'nın asıl sorusu "AI ajanı deploy yapabilir mi?" değil. "AI ajanına ne kadar yetkiyi, hangi süreyle, hangi sınırlar içinde, hangi denetim mekanizmasıyla vereceğiz?" sorusu.

Asıl problem neden kimlik ve yetki problemi?

Bir geliştirici bir sistemi deploy ederken görünmez ama kritik birkaç güvenlik katmanından geçer:

  • Hangi ortama erişebildiği bellidir.
  • Hangi repository veya pipeline üzerinde işlem yaptığı bellidir.
  • MFA, SSO, VPN, device posture ve audit log gibi kontroller devrededir.
  • Hata yaparsa hesabı kapatılabilir, erişimi kesilebilir, işlem izi takip edilebilir.

AI ajanı işin içine girdiğinde bu model doğal olarak bozuluyor. Çünkü ajan:

  • Uzun süre arka planda çalışabilir.
  • İnsan kadar bağlamsal sezgiye sahip değildir.
  • Yanlış komutu yüksek hızla tekrar edebilir.
  • "Başarılı oldu mu?" diye anlamak için sisteme tekrar tekrar dokunabilir.
  • Eline verilen credential'ı amaç dışı kullanma riskini artırabilir.

Tam bu yüzden kalıcı ve geniş yetkili token'ları bir ajan oturumuna vermek, kısa vadede kolay; orta vadede ise pahalı bir karardır.

Cloudflare'in duyurduğu temporary account yaklaşımı bence burada önemli bir mimari işaret taşıyor. Model basit: ajan, kalıcı hesap açmadan wrangler deploy --temporary ile kısa ömürlü bir dağıtım yapabiliyor; bu erişim 60 dakika içinde claim edilmezse otomatik düşüyor. Teknik olarak bakınca bu özellik yalnızca "kolay deploy" değil, aynı zamanda credential ömrünü daraltma fikrinin ürünleşmiş hali.

Bu yaklaşımın ana fikri şu: ajanın sürekli yetkiye değil, dar kapsamlı ve son kullanma tarihli yetkiye ihtiyacı var.

Senior mühendislik refleksi burada ne der?

Ben bu noktada üç seviyeli düşünmeyi daha sağlıklı buluyorum:

1. Ajanın ne yapmasına izin veriyoruz? 2. Bunu hangi ortamda yapmasına izin veriyoruz? 3. Hata yaptığında zarar ne kadar büyüyebilir?

Çoğu ekip ilk soruya odaklanıyor. Halbuki ikinci ve üçüncü sorular daha kritik.

Örneğin bir AI ajanının aşağıdaki işleri yapması arasında ciddi fark var:

  • Lokal sandbox ortamında preview deploy üretmesi
  • Geçici bir staging adresine paket atması
  • Shared test environment üzerinde migration çalıştırması
  • Production'a rollout başlatması
  • WAF, Zero Trust veya DNS kuralı değiştirmesi

Hepsi teknik olarak "deploy" gibi görünür. Ama risk profilleri aynı değildir.

Bir senior ekip burada yetkiyi işin adına göre değil, etkisine göre modellemeli. "Deploy yetkisi var" gibi geniş bir ifade yerine şu şekilde düşünmek daha doğru:

  • Sadece ephemeral preview ortamına yazabilir.
  • Sadece belirli branch veya commit SHA'dan işlem başlatabilir.
  • Sadece onaylanmış artifact'i dağıtabilir.
  • Sadece belirli süre yaşayan credential kullanabilir.
  • Sadece belirli değişiklik tiplerinde otomatik ilerleyebilir.
  • Policy, secret, network ve data-plane değişiklikleri için insan onayı ister.

Bu ayrımı koymadan verilen her ajan yetkisi, aslında tek satırlık bir abstraction altında gizlenmiş büyük bir operasyonel risktir.

Temporary credential neden kritik?

AI ajanları için en tehlikeli anti-pattern'lerden biri kalıcı API token paylaşımı. Sebebi basit:

  • Token çoğu zaman geniş yetkilidir.
  • Kullanım bağlamı sınırlı değildir.
  • Süresi uzun olduğu için unutulur.
  • Log, prompt, terminal çıktısı veya ara dosyalarda sızma riski taşır.
  • "Geçici çözüm" olarak verilir ama kalıcı mimariye dönüşür.

Temporary credential yaklaşımı ise daha doğru bir güvenlik varsayımıyla başlar: ihlal olabilir, yanlış kullanım olabilir, o yüzden erişim kısa ömürlü ve düşük etki alanlı olsun.

Benim pratikte önerdiğim minimum çerçeve şu:

  • Credential TTL kısa olsun.
  • Scope sadece gereken resource'larla sınırlı olsun.
  • Kullanım tek amaçlı olsun.
  • İnsan tarafından claim veya approval gerektiren son bir kapı olsun.
  • Tüm agent action'ları ayrı audit event olarak loglansın.
  • Expire olan yetki otomatik temizlensin.

Cloudflare'in temporary account modeli bu düşüncenin iyi bir örneği. Ama aynı fikir GitHub tarafındaki AGENTS.md desteğiyle de örtüşüyor. Çünkü sorun yalnızca "ajana erişim vermek" değil, "ajana kurallı davranış zemini sağlamak". AGENTS.md bu açıdan teknik governance dokümanının repository seviyesinde makine tarafından okunabilir versiyonu gibi çalışıyor.

Bu dosyayı yalnızca kod stili için düşünmemek lazım. İyi kurgulanmış bir AGENTS.md veya eşdeğer politika katmanı şu kuralları taşıyabilir:

  • Hangi klasörler risklidir
  • Hangi değişiklikler için test zorunludur
  • Güvenlik hassasiyetine sahip alanlar nelerdir
  • Hangi komutlar çalıştırılamaz
  • Secret, config veya migration değişikliklerinde nasıl davranılmalıdır
  • Agent'in hangi noktada insan onayı istemesi gerekir

Yani AI ajanı için kuralların prompt içinde dağınık tutulduğu dönemden, repository ve platform seviyesinde tanımlandığı döneme geçiyoruz.

Blast radius küçültülmeden agentic deploy güvenli olmaz

Benim en kritik gördüğüm konu bu.

AI ajanlarıyla ilgili tartışmalar çoğu zaman model kalitesi etrafında dönüyor. Oysa gerçek üretim ortamında asıl belirleyici olan şey model zekası değil, hata yarıçapı. Çünkü çok zeki bir ajan da yanlış hedefe doğru işlem yapabilir. Zayıf ama kısıtlı bir ajan ise daha az zarar verir.

Bu yüzden güvenli agentic deploy için şu prensipleri temel almak gerekiyor:

1. Preview ile production aynı güven düzeyinde olmamalı

Preview deploy, ajanların hızlı dene-gör döngüsü için çok değerli. Ama production pipeline ile aynı credential modelini paylaşmamalı. Ephemeral environment burada çok işe yarıyor. Ajan kodu üretir, ayağa kaldırır, smoke test yapar, sonucu raporlar. Bu akış production'a dokunmadan değer üretir.

2. Onay kapısı artifact aşamasında kurulmalı

İnsan onayını en sona koymak bazen geç kalmak demek. Daha doğru yaklaşım, ajan kod yazdıktan sonra değil; build, test, security scan ve policy check tamamlandıktan sonra onayı artifact üzerinde vermek. Böylece insan "ne deploy edilecek?" sorusuna somut bir çıktı üzerinden cevap verir.

3. Policy ve secret alanı kod alanından ayrılmalı

Bir ajanın uygulama koduna katkı vermesi ile IAM policy, firewall kuralı, DNS kaydı veya secret rotation işlemi yapması aynı şey değil. Bu alanlar ayrı yetki düzlemlerinde durmalı. Özellikle network ve identity katmanında "agent can assist, human approves" modeli daha güvenli.

4. Agent eylemleri gözlemlenebilir olmalı

Agent'in hangi komutu çalıştırdığı, hangi credential ile eriştiği, hangi resource'u değiştirdiği ve hangi sonuçla karşılaştığı tekil olaylar halinde tutulmalı. Aksi halde bir incident sonrasında "bunu kim yaptı?" sorusunun cevabı "ajan yaptı" seviyesinde kalır. Bu cevap kurumsal sistemlerde yeterli değil.

5. Geri alma maliyeti en baştan hesaplanmalı

Ajanın yaptığı deploy'un rollback stratejisi tanımlı değilse, aslında deploy süreci yarım tasarlanmıştır. Feature flag, blue-green, canary, immutable artifact ve hızlı rollback mekanizmaları agentic sistemlerde lüks değil; temel emniyet katmanıdır.

Google'ın ARD ve A2A hamleleri neden önemli?

Google'ın son günlerde duyurduğu Agentic Resource Discovery ve A2A yaklaşımı bence bu alanın bir sonraki aşamasını gösteriyor.

Bugün birçok ekip tek bir AI asistanına odaklanıyor. Ama yakın gelecekte daha sık göreceğimiz yapı şu olacak:

  • Bir ajan build tarafında çalışacak.
  • Başka bir ajan güvenlik taraması yapacak.
  • Başka bir ajan deployment planını hazırlayacak.
  • Başka bir ajan observability sinyallerini yorumlayacak.

Sorun şu: Bu ajanlar birbirini ve doğru aracı nasıl güvenle bulacak?

ARD bu soruya katalog, registry ve doğrulanabilir güven metadatası üzerinden cevap veriyor. A2A ise ajanların API gibi değil, daha dinamik ve görev devreden yapılar olarak haberleşmesi gerektiğini söylüyor.

Kurumsal mimari açısından bunun anlamı net: gelecek yalnızca "tek güçlü kod ajanı" değil; yönetişim altında çalışan çoklu ajan ekosistemi. Dolayısıyla bugün deploy yetkisini tasarlarken bile sadece tek ajanı değil, yarın birbirine görev devredecek ajan zincirini düşünmek gerekiyor.

Peki ekipler bugün ne yapmalı?

Bu alanda en sık gördüğüm hata iki uç yaklaşım:

  • Ya ajanlara neredeyse hiç yetki verilmemesi
  • Ya da hız kazanma baskısıyla gereğinden fazla yetki verilmesi

İkisi de sürdürülebilir değil.

Ben daha dengeli bir ilerleme öneriyorum:

Başlangıç seviyesi

  • Ajan sadece local ve ephemeral preview deploy yapsın.
  • Kalıcı credential verilmesin.
  • Secret erişimi kapalı olsun.
  • Tüm agent action'ları loglansın.

Orta seviye

  • Ajan staging dağıtımı başlatabilsin.
  • Yetki branch, servis ve ortam bazında sınırlandırılsın.
  • Zorunlu test, SAST ve policy check olmadan ilerleyemesin.
  • İnsan onayı olmadan data veya network katmanına dokunamasın.

İleri seviye

  • Ajan rollout planı ve rollback planı hazırlasın.
  • Canary veya düşük riskli servislerde kontrollü otomasyon çalışsın.
  • Değişiklikler risk skoruna göre farklı approval akışlarına girsin.
  • Platform ekibi agent governance standardını merkezi olarak yönetsin.

Buradaki amaç ajanın önünü tamamen kapatmak değil. Ama onu "süper admin stajyer" gibi de sisteme salmamak.

Sonuç

AI destekli geliştirmede bir süredir kalite ve teknik olgunluk tarafını konuşuyoruz. Bence şimdi buna bir katman daha eklemek gerekiyor: yetki mimarisi.

Önümüzdeki dönemde güçlü ekiplerle zayıf ekipler arasındaki farkı yalnızca kimin daha iyi model kullandığı belirlemeyecek. Asıl farkı, kimin AI ajanlarını daha güvenli, daha denetlenebilir ve daha küçük blast radius ile üretim sürecine bağladığı belirleyecek.

AI ajanı deploy yapabiliyor olması etkileyici. Ama esas mühendislik seviyesi, bunu hangi sınırlar içinde yaptırdığınızda ortaya çıkıyor.

Benim için doğru soru artık şu:

"Bu ajan deploy edebilir mi?"

değil.

"Bu ajan hata yaptığında sistem ne kadar güvende kalır?"

sorusu.

Bu soruya iyi cevap veren ekipler, agentic development çağında gerçekten ölçeklenebilir çalışacak.

Kaynaklar

Görüntüleme: 78

Serhat Diker sitesinden daha fazla şey keşfedin

Subscribe to get the latest posts sent to your email.

You may also like...