Bir AI agent; kod yazabilir, dosya okuyabilir, API çağırabilir, veritabanında sorgu çalıştırabilir veya zamanlanmış bir işi tamamen otomatik yürütebilir. Bu yetenekler faydalıdır; fakat production ortamında agentin “ne yapabildiği” kadar “nereye kadar yapabildiği” de tasarlanmalıdır. Güvenli AI Agent Hosting, yalnızca bir süreci 7/24 açık tutmak değil; çalışma ortamını, secret erişimini, dış ağ trafiğini ve geri dönüşü zor aksiyonları sınırlandırmaktır.

Önce tehdit modelini yazın

Agent güvenliği, modelin her zaman doğru karar vereceği varsayımıyla kurulamaz. Hatalı prompt, yanlış araç seçimi, beklenmeyen API yanıtı, kötü amaçlı içerik veya uygulama bug’ı agenti amaç dışı bir aksiyona sürükleyebilir. Bu nedenle ilk soru “hangi modeli kullanıyoruz?” değil, “bu iş yükü yanlış davranırsa hangi varlıklara ulaşabilir?” olmalıdır.

• Hangi dosya ve dizinleri okuyabilir veya değiştirebilir?
• Hangi API ve internet hedeflerine bağlanabilir?
• Hangi credential’ları görebilir; bunlarla hangi işlemleri yapabilir?
• Bir hata sonsuz döngü, aşırı maliyet veya toplu veri değişikliği yaratabilir mi?
• Operatör agenti nasıl durdurur ve son güvenli duruma nasıl döner?

Agent için ayrı bir çalışma sınırı oluşturun

Agenti doğrudan host işletim sistemi üzerinde geniş yetkilerle çalıştırmak, uygulama hatasını altyapı olayına dönüştürebilir. Ayrı kullanıcı, container veya daha güçlü bir sanallaştırma sınırı; dosya sistemi, süreç, ağ ve kaynak erişimini daraltmak için kullanılır. Seçilen yöntem iş yükünün riskine göre değişebilir; temel kural agentin ihtiyaç duymadığı host kaynaklarına erişmemesidir.

Host socket, yönetim paneli token’ı, SSH anahtarı veya tüm proje dizinini kapsayan yazma izni “kolay kurulum” sağlar; aynı zamanda agentin hata etkisini büyütür. Salt okunur kök dosya sistemi, ayrı çalışma dizini, geçici dosyalar için kota ve belirli volume’lar daha kontrollü bir başlangıçtır. Birden fazla agent aynı sunucuda çalışıyorsa süreç ve credential ayrımı tenant ayrımı kadar ciddiye alınmalıdır.

Dış ağ erişimini varsayılan kapalı düşünün

Agentin internete çıkabilmesi çoğu senaryoda gereklidir; ancak “her yere çıkabilir” politikası gerekli değildir. Egress allowlist ile yalnızca kullanılan API, paket deposu, webhook veya veritabanı hedeflerine izin verilebilir. DNS sorguları, proxy logları ve bağlantı denemeleri izlenerek beklenmeyen hedefler görünür hale getirilir.

• API hedeflerini alan adı ve port düzeyinde tanımlayın.
• Metadata servisleri, yönetim ağları ve özel subnet’leri agent ağından kapatın.
• Webhook hedeflerinde TLS doğrulaması ve mümkünse imza kontrolü kullanın.
• Yeni bir hedefe erişim gerektiğinde otomatik genişletmek yerine değişiklik kaydı ve onay isteyin.

Ağ kısıtı tek başına içerik güvenliği sağlamaz. İzinli bir e-posta API’sine yanlış müşterinin verisini göndermek hâlâ mümkündür. Egress kontrolü, agentin erişebileceği yüzeyi daraltır; işlem niyeti ve veri doğruluğu için ayrı uygulama kontrolleri gerekir.

Secret’ları agentin belleğine bırakmayın

API key, veritabanı parolası ve servis hesabı token’ı prompt içine, Git deposuna veya düz loga yazılmamalıdır. Secret mümkünse çalışma anında enjekte edilmeli, en dar yetkiye sahip olmalı ve iş yükü bazında ayrılmalıdır. Tek bir “master” anahtarı tüm agentlere dağıtmak, küçük bir sızıntıyı ortak altyapı olayına dönüştürür.

• Okuma ve yazma yetkileri için farklı credential kullanın.
• Development, test ve production secret’larını kesin olarak ayırın.
• Kısa ömürlü token veya proxy üzerinden işlem modelini değerlendirin.
• Loglarda header, query string ve hata gövdesi maskelemesi uygulayın.
• Rotasyonun yalnızca anahtarı değiştirmek değil, eski anahtarı iptal etmek olduğunu doğrulayın.

Geri dönüşü zor aksiyonlara onay kapısı koyun

Okuma, taslak oluşturma ve öneri üretme işlemleri ile gönderme, silme, ödeme, deploy veya production verisi değiştirme işlemleri aynı risk sınıfında değildir. Agentin bir e-postayı hazırlaması otomatik olabilir; göndermesi insan onayı gerektirebilir. Benzer şekilde migration planı üretebilir, fakat production migration komutu ayrı bir yetkiyle çalıştırılmalıdır.

Onay mekanizması yalnızca bir “evet/hayır” düğmesi olmamalıdır. Operatöre hedef sistem, değişecek kayıt sayısı, tahmini maliyet, geri dönüş planı ve kullanılan credential kapsamı gösterilmelidir. Böylece onay, kör bir formalite yerine risk değerlendirmesine dönüşür.

Kaynak, maliyet ve zaman limitleri belirleyin

Hatalı retry döngüsü; CPU, bellek, API kotası veya LLM harcamasını kısa sürede tüketebilir. Her görev için timeout, maksimum deneme sayısı, eşzamanlılık, kuyruk uzunluğu ve günlük maliyet limiti tanımlayın. İşlem idempotent değilse otomatik retry veri çoğaltabilir; retry kararı iş mantığıyla birlikte ele alınmalıdır.

CPU ve bellek limitleri hostu korur; görev düzeyindeki limitler ise bütçeyi ve dış servisleri korur. Kuyruk gecikmesi, başarısız görev oranı, token/API tüketimi, disk büyümesi ve açık bağlantılar için alarm üretin. Limit aşıldığında sistemi tamamen çökertmek yerine yeni işi durduran kontrollü bir “circuit breaker” yaklaşımı kullanın.

Audit log ve kill switch olmadan production’a çıkmayın

Bir olay sonrasında “agent ne yaptı?” sorusu cevaplanabilmelidir. Görev kimliği, tetikleyici, kullanılan araç, hedef servis, karar noktası, sonuç ve hata durumu ilişkilendirilebilir biçimde loglanmalıdır. Hassas veri ve secret loglanmamalı; ancak aksiyon zinciri yeniden kurulabilmelidir.

Kill switch yeni görev alımını durdurmalı, gerekiyorsa çalışan işleri iptal etmeli ve credential’ları iptal etme sürecini tetiklemelidir. Bu mekanizmayı olay anında ilk kez denemeyin. Staging ortamında kuyruk taşması, API timeout, yanlış credential ve izin verilmeyen ağ hedefi senaryolarıyla prova yapın.

Yayın öncesi kötü senaryo testi yapın

Normal akışın çalışması production hazırlığını kanıtlamaz. Agentin yanıt vermeyen bir API ile karşılaşmasını, beklenmedik büyüklükte dosya üretmesini, süresi dolmuş credential kullanmasını ve izin verilmeyen hedefe bağlanmayı denemesini kontrollü olarak test edin. Her senaryoda görevin güvenli biçimde durduğunu, retry sayısının sınırlı kaldığını, secret’ın loga düşmediğini ve alarmın doğru sorumluya ulaştığını doğrulayın. Test sonucu tarih, sürüm ve kullanılan politika setiyle kaydedilmelidir.

Production güvenlik kontrol listesi

• Agent ayrı kullanıcı ve izole çalışma ortamında çalışıyor.
• Host socket, yönetim ağı ve gereksiz volume erişimi kapalı.
• Egress hedefleri allowlist ile sınırlı; DNS/proxy logları izleniyor.
• Her agent ve ortam için ayrı, en az yetkili credential kullanılıyor.
• Secret’lar prompt, repo ve loglarda görünmüyor; rotasyon testi var.
• Silme, gönderme, deploy ve production değişiklikleri için onay kapısı tanımlı.
• Timeout, retry, concurrency, kuyruk ve maliyet limitleri ölçülüyor.
• Audit log, alarm, kill switch ve olay müdahale sahibi belirli.

AI Agent Hosting altyapısını birlikte değerlendirin

7/24 çalışan agent, bot, Python/Node.js otomasyonu veya zamanlanmış görevler için kaynak ihtiyacı kadar yetki ve izolasyon modeli de önemlidir. Narweb AI Agent Hosting sayfasından kullanım senaryolarını inceleyebilir; deployment, izleme ve bakım akışı için DevOps hizmetini değerlendirebilirsiniz. Mevcut agent iş yükünüzün secret, ağ, storage ve çalışma süresi gereksinimlerini paylaşmak için teknik görüşme talep edin.