Agent Security, OpenAI'nın DevDay 2026'da kurumsal ajanlar için duyurduğu merkezi politika alanı. Hangi araçlar kullanılabilir, yerel bilgisayarda veya Codex Cloud'da dosya ve ağ erişimi nasıl sınırlandırılır gibi soruları yönetici politikalarına bağlıyor. Resmî kılavuz bunun eski Policies & Configuration alanının yerini aldığını söylüyor.
En kritik ayrım şu: Global temel, desteklenen Local ve Codex Cloud ortam ayarları için ayrı geçersiz kılmalar ve Work Cloud'un ayrı bulut yetenekleri var. Bir ayarı bir yerde açmak her yürütme ortamında aynı sonucu doğurmuyor. Güvenlik incelemesinde “politika yazıldı” yerine “etkin kural bu görevde ne yaptı?” sorusunu test etmek gerekiyor.
Bu yazının duyuru ve erişim bilgileri OpenAI’nın resmî özellik belgesi ile DevDay 2026 toplu duyurusu üzerinden doğrulandı. Örnek proje ve deneme önerileri editoryal yorumdur.
Global temel neyi yönetiyor?
Her politika Global bir temel ile başlıyor. Onay gereksinimi, izinli web araması ve yönetilen araç kontrolleri gibi orkestratör kararları burada tutuluyor. Bazı ortak yürütme ayarları da Global'dan miras alınabiliyor. Yerel veya Codex Cloud ortam geçersiz kılması yalnız desteklenen yürütme alanlarını etkiliyor; her Global kuralı ortamda yeniden tanımlama özgürlüğü yok. Bir yönetici için doğru sıra önce Global kuralları gözden geçirmek, sonra gerçekten farklı olması gereken ortam ayarlarını yazmak. Aksi halde aynı niyet üç yerde çelişkili görünebilir.
Local ve Codex Cloud farkı
Local bağlı bilgisayarda yürütülen işi, Codex Cloud bulut görevini temsil ediyor. Desteklenen sandbox, ağ ve yürütme ayarları ortam bazında farklı olabilir. Örneğin yerelde yalnız proje klasörüne yazma, bulutta yalnız onaylı paket depolarına ağ erişimi gibi politikalar tasarlanabilir. Fakat gerçek alanların platforma göre değişebildiğini resmî konfigürasyon referansı belirtiyor. Bir politikayı teoride yazabiliyor olmak her istemcide uygulandığını kanıtlamaz. Test cihazı ve bulut ortamı üzerinde etkin kuralı görmek gerekir.
Ağ izinleri neden iki katmanlı?
Agent Security'de izinli ve engelli alan adları tanımlanabiliyor. Codex Cloud ortamının internet erişim ayarı ise ayrıca geçerli. Agent Security'de bir alan adına izin vermek, Cloud environment internet ayarı kapalıysa otomatik erişim açmaz. Kılavuz, yerel/özel bağlantı ve upstream proxy konularında ayrıca dikkat istiyor. Kurumsal web projesinde paket deposu, CMS önizleme alanı ve şirket içi API için ayrı test yapmak gerekir. “Domaine izin verdim, neden bağlanmıyor?” sorusunun yanıtı iki katmanın birleşiminde olabilir.
Requirements ve Defaults
Requirements kullanıcı tarafından gevşetilemeyen sınırları, Defaults ise bu sınırlar içinde başlangıç değerini tanımlar. Ekip çoğu zaman varsayılanı politika sanır; kullanıcı ayarı değiştirebildiğinde sürpriz yaşanır. Örneğin ağ kısıtı zorunluysa Requirements tarafı gerekir; yalnız önerilen çalışma ayarı için Defaults yeterli olabilir. Yönetici panelinde bu iki bölümü ayrı incelemek, özellikle hassas repo ve müşteri dosyalarında önem taşır. Politika sıralaması ve birden çok politikanın birleşimi de etkin sonucu değiştirebilir.
Work Cloud için ayrı kontroller
Resmî kılavuz Work Cloud ve Dot bulut bilgisayarlarının kendi yürütme ayarları ve gereksinimleri olduğunu söylüyor. Cloud browser use ve Cloud network access gibi yetenekler Admin Console'da ayrı çalışma alanı izinleri altında yönetiliyor. Local bilgisayar için yazılmış dosya/ağ kısıtının Work Cloud konteynerine aynen taşındığını varsaymamak gerekir. Bu ayrım, “ajan politikası var, tüm ortamlarda güvendeyiz” cümlesini engeller. Bir şirket en sık kullanılan iki yürütme yolunu ayrı test etmeli.
Örnek politika tasarımı
Bir ajans müşteri siteleri için kod ajanı kullanıyor olsun. Global düzeyde dışa mesaj ve riskli araç için onay, yerelde yalnız proje çalışma alanı, Codex Cloud'da gerekli paket yöneticisi alan adları, Work Cloud'da ayrı tarayıcı ve ağ erişimi gözden geçirilebilir. Bu benim editoryal senaryom; hazır politika tarifi değil. Her yetki şirketin gerçek uygulamalarıyla test edilmeli. Özellikle müşterinin staging alanına bağlanma ve canlı ortama yazma yetkileri farklı tutulmalı. Yalnız iyi niyetli talimat, yürütme sınırının yerini almamalı.
Öncelik ve miras alma
Kılavuz, birden çok politika arasında yüksek öncelikli politikanın kazandığını; aynı politikanın içinde işletim sistemine özel ortam kuralı, tüm sistemler için ortam kuralı, sonra Global sırasını açıklıyor. Boş ortam ayarı Global'ı temizlemiyor, miras alıyor. Bu ayrıntı erişim hatasını incelerken önemli: yönetici yeni Local kural yazmadı diye Global sınır kalkmıyor. Yerelde MDM ve yönetilen cihaz gereksinimleri de farklı önceliğe sahip olabilir. Sonuç, dosyada yazan tek satırdan değil etkin birleşimden okunmalı.
Politika değişimini nasıl doğrularım?
Önce düşük riskli test deposu ve sahte veri seçerdim. İzinli araca erişim, yasaklı araca erişim, izinli ağ, engelli ağ ve onay gerektiren adım ayrı test edilir. Aynı senaryolar Local, Codex Cloud ve kullanılıyorsa Work Cloud için tekrarlanır. İzin reddinin kullanıcıya nasıl göründüğü de önemlidir; belirsiz hata, ekibin politikayı sürekli gevşetme baskısı yaratır. Geçişte eski politikaların Global'a taşınan atamaları ve sırası özellikle incelenmeli.
Politika haritası nasıl çizilir?
Önce görev tiplerini ve yürütme yerlerini yazarım: masaüstünde yerel kod, Codex Cloud'da repo işi, Work Cloud'da araştırma veya bağlı bilgisayar erişimi. Her satırda hangi araç, hangi dosya konumu, hangi ağ hedefi ve hangi insan onayı gerektiği yer alır. Sonra Global ortak sınırlar ve ortam farkları çıkar. Bu sıra ters olursa yönetim panelindeki seçeneklere bakıp gereksiz kural üretilir. Resmî kılavuzun orkestratör/yürütücü ayrımı bu haritayı kurmaya yarıyor. Politika, ürün ayarı listesi değil gerçek iş akışının sınır sözleşmesi olmalı.
Deny ve Allow mantığını test etmek
Ağ yönetiminde yalnız izin verilen alan adlarını tanımlayıp yönetici listesini zorunlu kılarsanız etkin Allow hedefi yokken olağan komutların gidecek yeri kalmayabilir. Resmî belge bu “no effective allowed destinations” durumunu özellikle açıklıyor. Deny-only kuralının beklenen engeli oluşturup oluşturmadığı da test edilmeli. Ben izinli paket deposu, engelli rastgele domain ve şirket içi API için ayrı küçük komutlar koştururdum. Böylece policy metniyle pratik davranış uyuşuyor mu görülür. Ağ kuralının Cloud Environment internet anahtarıyla birleşimini de aynı deneyde gözlemek gerekir.
Onay ve araç kontrolünün yeri
Onay gereksinimi ve yönetilen araç kısıtları Global orkestratör alanında tanımlanıyor; Local veya Codex Cloud environment requirements her orkestratör ayarını geçersiz kılamıyor. Ekip yalnız ortam dosyasına bakarsa “neden hâlâ onay istiyor?” sorusunu çözemeyebilir. Bu yüzden politika incelemesinde kuralın hangi katmanda yaşadığı yazılmalı. Bir dosya yazma eylemi için sandbox ve insan onayı aynı şey değil: sandbox teknik olarak nereye yazılabileceğini, onay ise kullanıcının karara dahil olup olmayacağını belirler. İkisini birlikte düşünmek daha güvenilir.
Eski politikadan geçiş
Agent Security eski Policies & Configuration alanının yerini alırken uygun eski bulut politikalarının Global'a taşınan ayarları, atamaları ve sıralaması korunabiliyor. Yine de kılavuz yöneticiye bu birleşimi kontrol etmesini söylüyor. Ben göç sonrası her rol için etkin politika çıktısını ve temsilî görevde davranışı karşılaştırırdım. Yalnız “ayarlar taşındı” mesajı yeterli değil; Local ve Codex Cloud farkları yeni arayüzde yanlış yorumlanabilir. Ayrıca yerel Work erişimi ve Dot ayrı opt-in süreçleri; politika geçişi bunları kendiliğinden açmıyor. Bu ayrımı çalışanlara açıklamak yanlış beklentiyi azaltır.
Sürekli denetim
Bir kere kurulan politika yeni araç, yeni bulut ortamı veya yeni müşteri projesiyle eskir. Çeyreklik incelemede izinli domainlerin hâlâ gerekli olup olmadığını, geçici istisnaların kaldırılıp kaldırılmadığını ve hangi kullanıcı grubunun hangi policy'yi aldığını gözden geçirirdim. Yeni bir eklenti veya Work Cloud özelliği gelirse mevcut Local kuralın onu kapsadığını varsaymam. Denetimde yalnız kural listesi değil, engellenen ve izin verilen örnek iş adımları olmalı. Böylece Agent Security yazılı bir güvenlik niyetinden, doğrulanan ve değişen iş akışına uyarlanan kontrole dönüşür.
Rol bazlı deneme
Aynı politika geliştirici, editör ve yönetici rollerinde farklı etkin sonuç verebilir. Pilot testte her rolün bir izinli ve bir yasaklı görevi denemesini isterdim. Örneğin geliştirici test deposunu okuyabilir ama canlı dağıtım anahtarına erişemez; editör onaylı briefi inceleyebilir ama müşteri dışına gönderemez. Gerçek kurallar kuruma göre değişir. Ama rol matrisi olmadan yalnız politika dosyasını okumak yeterli değil. Agent Security'nin atama ve sıralama mantığı nedeniyle aynı kişinin birden fazla policy'den hangi etkin kuralları aldığı doğrulanmalı.
Engel mesajını anlaşılır yapmak
Güvenlik kuralı bir eylemi durdurduğunda kullanıcı yalnız “işlem başarısız” görürse tekrar tekrar denemeye veya yöneticiden geniş izin istemeye yönelebilir. Hangi araç veya ağ alanının kısıtlandığı ve uygun alternatifin ne olduğu anlaşılır olmalı. Çok fazla teknik ayrıntı veya gizli politika açığa çıkarmadan doğru destek yolunu göstermek gerekir. Bu, yönetim panelinin otomatik sunduğu belirli bir mesaj vaadi değil, iyi işletim önerisi. Kuralın uygulanması kadar onun iş akışında nasıl yaşandığı da önemlidir. Kullanıcı neden durduğunu anladığında güvenlik istisnası talebi daha isabetli olur.
Sonuç
Agent Security bir sihirli “güvenli ajan” anahtarı değil; izinleri ortam ve rol düzeyinde yönetme aracı. Değeri, orkestratör ile yürütücünün kontrollerini açık ayırmasında. İyi uygulama Global temelden başlar, Local/Codex Cloud farklarını yalnız gerektiğinde tanımlar, Work Cloud'u ayrı ele alır ve etkin davranışı test eder. Böylece hız kazandıran ajan iş akışı erişim sürprizi üretmeden büyüyebilir.
Sık sorulan sorular
Agent Security Work Cloud'u da tamamen yönetir mi?
Hayır. Resmî kılavuz Work Cloud bulut yetenekleri için ayrı kontroller bulunduğunu söylüyor.
Local ayar boşsa Global kural kalkar mı?
Hayır. Desteklenen ortam ayarı tanımlı değilse uygun Global ayar miras alınır.
Bir domaine izin vermek Codex Cloud internete erişim açar mı?
Tek başına açmaz; Cloud environment internet ve bağlantı ayarları ayrıca uygulanır.
İlgili yazılar
- DevDay 2026: bütün duyurular
- ChatGPT Slack ve Microsoft Teams İçinde Nasıl Çalışıyor?
- ChatGPT Team Tasks: Ekip Adına Zamanlanmış İşler
- Workspace Connections: Şirket Hesabıyla Ortak Bağlantı