Gizli Bilgiler ve Ağ
Bulut ajanları Gizlilik Modunda kullanılabilir. Kodunuzla asla eğitim yapmayız ve kodunuzu yalnızca agent çalışırken saklarız. Gizlilik Modu hakkında daha fazla bilgi edinin.
Çalıştırma yaşam döngüsü, erişim modeli, yalıtım, şifreleme ve veri işleme dâhil olmak üzere Bulut ajanlarının mimarisi ve güvenliği hakkında ayrıntılı bilgi için Güvenliğe genel bakış sayfasına bakın. Bu sayfa, açıklanan denetimlere yönelik yapılandırma başvurusudur.
Gizlilik Modu (Eski) desteklenmez. Eski Gizlilik Modu, bulutta veri depolanmasını engeller. Bulut ajanlarının ise çalışırken kod ve ortam verilerini bulutta depolaması gerekir. Bulut ajanlarını kullanmadan önce Kontrol Paneli → Bulut Ajanları üzerinden Gizlilik Moduna geçin.
Gizli bilgilerin korunması
Cloud Agents'a sağlanan gizli bilgiler, depolanırken ve aktarım sırasında şifrelenir. Cloud Agent kullanıcısı dışında hiç kimse bu bilgilere erişemez.
Gizli bilgiler Ortam Değişkeni, Çalışma Zamanı Gizli Bilgisi veya Derleme Gizli Bilgisi olarak ayarlanabilir.
Ortam Değişkenleri
Environment Variable türündeki gizli bilgiler cloud agent tarafından görülebilir. Bunlar, işaretler veya herkese açık URL'ler gibi agentın görmesinin yararlı olduğu hassas olmayan yapılandırmalar için idealdir. Diğer gizli bilgi türlerinde olduğu gibi durağan halde ve aktarım sırasında şifrelenir.
Çalışma zamanı gizli bilgileri
Runtime Secrets daha önce Redacted Secrets olarak adlandırılıyordu.
Runtime Secret türünde ayarlanan gizli bilgiler, ortam değişkeni olarak yüklenmeye devam eder; ancak içerikleri agent'ın araç çağrısı sonuçlarında, chat dökümünde, commit'lerde ve commit mesajlarında gizlenerek [REDACTED] yer tutucu dizesiyle değiştirilir. Bunlar, agent'a gösterilmemesi ve asla depoya commit edilmemesi gereken hassas kimlik bilgileri için idealdir.
Çalışma zamanı gizli bilgileri dahili olarak ortam değişkeni işlevi görmeye devam ettiğinden, agent'a gösterilmeseler de Terminal üzerinden agent'ın ortamıyla etkileşime giren kullanıcılar tarafından görülebilirler.
Derleme gizli bilgileri
Build Secret türünde ayarlanan gizli bilgiler yalnızca Docker derleme işleminde (yapılandırdıysanız) kullanılabilir ve çalışan agent'ın ortamına aktarılmaz. Bunlar, agent'a aktarılmaması gereken özel paket kayıtları veya derleme zamanı kimlik bilgileri için idealdir.
Dockerfile'ınızda bir Build Secret'ı güvenli bir şekilde kullanmak için, örneğin bir Docker gizli bilgi bağlama noktası kullanarak RUN adımında buna başvurun:
RUN --mount=type=secret,id=MY_TOKEN,env=MY_TOKEN,required=true \ ./scripts/install-private-deps.shOIDC kimlik belirteçleri
Bulut rolleri ve dahili API'ler için, Gizli Bilgiler'deki uzun ömürlü anahtarlar yerine kısa ömürlü OIDC belirteçlerini tercih edin. cloud agent VM, yerel bir socket üzerinden Cursor tarafından imzalanmış bir JWT oluşturup bunu AWS, GCP, Azure, Vault veya herhangi bir OIDC doğrulayıcısına sunabilir.
İmzalı commit'ler
Bulut ajanları her commit'i HSM destekli bir Ed25519 anahtarıyla imzalar. GitHub ve GitLab'da bu commit'lerde, ekibinizin commit'in Cursor'dan geldiğini doğrulamasını sağlayan bir "Verified" rozeti görüntülenir.
Bu özellik tüm bulut ajanları için otomatik olarak çalışır. Kurulum gerekmez.
Deponuz, imzalı commit'ler gerektiren dal koruma kurallarını zorunlu tutuyorsa Cloud Agent PR'leri ek yapılandırma gerektirmeden bu kuralları karşılar.
Korumalı Git Kapsamları
Ekip yöneticileri, yalnızca ekiplerinizin bu Git kuruluşundaki repolarda Cloud Agent başlatabilmesi için bir Git kuruluşunu Cursor kuruluşunuza kilitleyebilir. Bkz. Korumalı Git Kapsamları.
Bilmeniz gerekenler
- Düzenlemek istediğiniz repolar için GitHub uygulamamıza okuma-yazma izni verin. Bu izinle repoyu klonlar ve değişiklik yaparız.
- Kodunuz, yalıtılmış VM'lerde AWS altyapımızda çalışır ve agent erişilebilir olduğu sürece VM disklerinde saklanır.
- Agent varsayılan olarak internete erişebilir. Agent'ın erişebileceği alan adlarını kısıtlamak için kullanıcılar, ekipler ve kaydedilmiş ortamlar için ağ çıkış kontrollerini yapılandırabilirsiniz.
- Agent tüm terminal komutlarını otomatik olarak çalıştırarak testler üzerinde yineleme yapabilir. Bu, her komut için kullanıcı onayı gerektiren ön plandaki agent'tan farklıdır. Otomatik çalıştırma veri sızdırma riski doğurur: saldırganlar istem enjeksiyonu saldırılarıyla agent'ı kandırarak kodu kötü amaçlı web sitelerine yüklemesini sağlayabilir. Cloud agent'lar için istem enjeksiyonu risklerine ilişkin OpenAI açıklamasına bakın.
- Gizlilik Modu devre dışıysa ürünü iyileştirmek için istemleri ve geliştirme ortamlarını toplarız.
- Bir cloud agent başlatırken Gizlilik Modu'nu devre dışı bırakır, ardından agent çalışırken etkinleştirirseniz agent tamamlanana kadar Gizlilik Modu devre dışı kalır.
Veri saklama
Bulut ajanları her çalıştırmada iki tür veri saklar:
- Konuşma geçmişi. Agent'ın dökümünü oluşturan istemler, model yanıtları, araç çağrıları ve demo çıktıları. Bu verileri, web'de veya masaüstü istemcisinde bir agent açtığınızda görürsünüz.
- Ortam anlık görüntüleri. Sanal makine diskinin belirli bir andaki şifrelenmiş kopyaları. Anlık görüntüler, VM ortamlarını özelleştirmenize ve agent'ların depoyu yeniden klonlamadan veya kurulumu yeniden çalıştırmadan başlamasına ya da devam etmesine olanak tanır.
Geçmiş çalıştırmaları yeniden inceleyebilmeniz ve devam ettirebilmeniz için konuşma geçmişi varsayılan olarak süresiz saklanır. Ortam anlık görüntüleri, en fazla 90 gün hareketsizlik boyunca saklanır. Bir agent anlık görüntüden her başladığında veya devam ettiğinde, son kullanma süresi 90 gün daha uzatılır. Bir anlık görüntü 90 gün boyunca kullanılmadığında, plan veya ilkeden bağımsız olarak otomatik olarak silinir.
Bir bulut ajanının konuşma geçmişini açıkça silmek için Delete Agent API'yi kullanabilirsiniz. Bu uç nokta, konuşma dökümünü ve çıktıları kaldırır. Ortam anlık görüntülerini silmez; bunlar isteğe bağlı olarak silinemez ve bunun yerine yukarıdaki saklama süresine tabidir.
Bulut ajanı saklama ilkeleri
Özel saklama süreleri, belirli Kurumsal ekipler için Erken Erişim kapsamındadır. Erişim talep etmek için satış ekibiyle iletişime geçin.
Kurumsal ekip yöneticileri, ekibin Cloud Agent verilerinin ne kadar süreyle saklanacağını Cloud Agents panelindeki Ekip Ayarları üzerinden sınırlayabilir. Kullanılabilen süreler Süresiz ve 90 gündür.
İlkeyi 90 gün olarak ayarladığınızda:
- Bir arka plan işi, saklama ilkesi süresinden eski konuşmaları siler.
- Ortam anlık görüntüleri, yukarıda açıklanan hareketli 90 günlük etkinliksizlik süresine uymaya devam eder.
- İlke, kayıtlı ortamlardan ve API'den gelenler dâhil olmak üzere ekibin sahip olduğu tüm agent çalıştırmalarına uygulanır.
Tekrar Süresiz seçeneğine geçmek, yeni konuşmaların silinmesini durdurur ancak daha önce silinmiş verileri geri yüklemez.
Ağ erişimi
Cloud Agents'larınızın erişebileceği ağ kaynaklarını yönetin. Bu ayarlar; bireysel kullanıcılar, kaydedilmiş ortamlar ve ekip yöneticileri için Cloud Agents kontrol panelinde kullanılabilir.
Özel ağ erişimi
Cloud Agents, özel kaynaklara erişmek için kendi donanımınızda çalışmak zorunda değildir. VPC veya intranet üzerindeki hizmetler için Cloud Agent ortamında Tailscale kullanıcı alanı ağ iletişimini, Cloudflare Tunnel'ı ya da benzer bir özel ağ istemcisini kullanın. Kurulum notları için Running Tailscale ve Running Cloudflare Tunnel bölümlerine bakın.
Tailscale veya Cloudflare Tunnel kullanıldığında, özel hizmetlerinizin genel internetten gelen trafiği kabul etmesi gerekmez. Agent kimliği doğrulanmış bir ağ yolu üzerinden bağlanırken hizmet özel ağınızda kalır.
Cloudflare Tunnel, agent'ın özel hizmete kimliği doğrulanmış bir HTTPS ana makine adı üzerinden erişebildiği durumlarda iyi bir seçenektir. Ağınızdaki bir bağlayıcı Cloudflare'a bağlantı başlatır ve Cloud Agent bu ana makine adını diğer harici URL'ler gibi çağırır. Ana makine adını Cloudflare Access hizmet token'larıyla koruyabilir, token değerlerini Cursor Secrets olarak saklayabilir ve ana makine adını Cloud Agent izin listenize ekleyebilirsiniz.
Özel veritabanları gibi TCP hedefleri için agent ortamında yerel bir TCP dinleyicisi sunan bir tünel istemcisi kullanın. Agent daha sonra localhost'a bağlanır; tünel ise trafiği özel kaynağa yönlendirir.
Özel GitHub Enterprise Server, GitLab Enterprise, kaynak denetimi API'leri, Artifactory veya Nexus gibi paket kayıtları ve ilgili webhook trafiği için Kurumsal ekipler, AWS PrivateLink veya Cloudflare Tunnel ile özel bağlantıyı kullanabilir.
Erişim modları
Üç mod, Cloud Agents'ın giden ağ erişimini kontrol eder:
| Mod | Davranış |
|---|---|
| Tüm ağ erişimine izin ver | Cloud Agents herhangi bir harici hosta erişebilir. Alan adı kısıtlaması yoktur. |
| Default + izin listesi | Cloud Agents, varsayılan alan adlarına ve izin listenize eklediğiniz tüm alan adlarına erişebilir. |
| Yalnızca izin listesi | Cloud Agents yalnızca izin listenize açıkça eklediğiniz alan adlarına erişebilir. |
Yalnızca izin listesi modunda bile Cloud Agents'ın çalışabilmesi için sınırlı sayıda alan adına erişim sağlanır. Bunlar arasında Cursor'ın kendi hizmetleri ve kaynak kontrol yönetimi (SCM) sağlayıcıları bulunur.
Çıktı yüklemeleri
Cloud Agents, çıktıları (PR'lerde gösterilen ekran görüntüleri, videolar ve günlük referansları) cloud-agent-artifacts.s3.us-east-1.amazonaws.com adresine yükler.
Default + izin listesi veya Yalnızca izin listesi kullanıyorsanız, çıktı yüklemelerinin başarılı olması için izin listenize tam host adını ekleyin. Girdiyi *.s3.us-east-1.amazonaws.com olarak genişletmeyin: joker karakter, bölgedeki tüm bucket'lara giden çıkış erişimini açar ve istem enjeksiyonuna uğramış bir agent için veri sızdırma yolu oluşturur. Host'u engellemek yüklemeleri devre dışı bırakır; agent oturumları ve diğer araç çağrıları çalışmaya devam eder.
Kullanıcı düzeyindeki ayarlar
Bireysel kullanıcılar, Cloud Agents kontrol panelindeki Güvenlik başlığı altında ağ erişim modlarını yapılandırabilir. Kullanıcı düzeyindeki ayarınız, oluşturduğunuz tüm Cloud Agents için geçerlidir.
İzin listesi içeren bir mod (Default + izin listesi veya Yalnızca izin listesi) seçtiğinizde, ayarın altında özel alan adlarınızı ekleyebileceğiniz bir izin listesi yapılandırma bölümü görünür.
Ortam düzeyinde ayarlar
Kaydedilmiş ortamların kendi ağ erişim modu ve izin listesi olabilir. Bir repo veya repo grubunun, ekibinizin geri kalanına kıyasla daha sıkı dışa ağ erişimine ihtiyaç duyduğu durumlarda ortam düzeyindeki ayarları kullanın.
Örneğin, daha az hassas bir ortamı Default + izin listesi modunda bırakırken üretime yakın bir ortamı Yalnızca izin listesi modunda tutabilirsiniz. Daha sıkı ortamı kullanan agent'lar bu kısıtlamaları devralır.
Ortam düzeyindeki ayarlar iki devralma seçeneği içerir:
| Mod | Davranış |
|---|---|
| Ayarları devral | Geçerli kullanıcı veya ekip ağ erişim ayarını kullanır. |
| Ayarları devral + ortam izin listesi | Geçerli kullanıcı veya ekip ayarını kullanır ve ortam izin listesindeki alan adlarını ekler. |
Bir ortamı doğrudan Tüm ağ erişimine izin ver, Default + izin listesi veya Yalnızca izin listesi olarak da ayarlayabilirsiniz.
Ekip düzeyindeki ayarlar
Ekip yöneticileri, aynı kontrol panelinden ekibin tamamı için varsayılan bir ağ erişim modu belirleyebilir. Ekip düzeyindeki izin listesi, yöneticilerin sandbox varsayılan ağ izin listesi için yapılandırdığı izin listesidir. Yönetilecek ayrı bir izin listesi yoktur; tek bir izin listesi hem Cloud Agent ağ erişimini hem de sandbox varsayılanlarını kontrol eder.
Ekip düzeyinde bir ayar varsa:
- Bir ortam kendi modunu tanımlıyorsa, bu ortamı kullanan agent'lara ortam ayarı uygulanır.
- Bir ortam ayarları devralıyorsa ve bir kullanıcı kendi ayarını yapılandırdıysa, kullanıcı ayarı önceliklidir.
- Ne ortam ne de kullanıcı bir ayar yapılandırdıysa, ekip varsayılanı uygulanır.
Ayarı kilitleme (Kurumsal)
Kilitleme yalnızca Kurumsal ekiplerde kullanılabilir.
Kurumsal ekip yöneticileri, Ağ Erişimi İlkesini Kilitle seçeneğini kullanarak ağ erişimi ayarını kilitleyebilir. Kilitlendiğinde:
- Ekip düzeyindeki ayar, kişisel tercihlerinden bağımsız olarak tüm üyeler için geçerli olur.
- Kullanıcılar kilitli ayarı kendi kontrol panellerinden değiştiremez.
Bu, yöneticilere kuruluş genelinde Cloud Agent ağ erişimi üzerinde tam denetim sağlar.
Sandbox ağ ilkesiyle ilişkisi
Default + izin listesi modundaki "Default" alan adları, masaüstü Agent'ın sandbox'ında kullanılan varsayılan ağ izin listesiyle aynıdır. Ekip düzeyindeki izin listesi de ortaktır: bir yönetici kontrol panelinde bir izin listesi yapılandırdığında, bu liste hem Cloud Agent ağ erişimi hem de sandbox ağ ilkesi için geçerli olur.
Dışa giden IP aralıkları
Cloud Agents, harici hizmetlere, API'lere veya repolara erişirken belirli IP adresi aralıklarından ağ bağlantısı kurar.
API uç noktası
IP aralıkları, JSON API uç noktası üzerinden kullanılabilir:
curl https://cursor.com/docs/ips.jsonYanıt biçimi
{ "version": 1, "modified": "2025-09-24T16:00:00.000Z", "cloudAgents": { "us3p": ["100.26.13.169/32", "34.195.201.10/32", "..."], "us4p": ["54.184.235.255/32", "35.167.37.158/32", "..."], "us5p": ["3.12.82.200/32", "52.14.104.140/32", "..."] }, "gitEgressProxy": ["184.73.225.134/32", "3.209.66.12/32", "52.44.113.131/32"]}- version: API yanıtı için şema sürüm numarası
- modified: IP aralıklarının son güncellenme zamanını belirten ISO 8601 zaman damgası
- cloudAgents: Kümeye göre anahtarlanmış IP aralıklarını içeren nesne
- gitEgressProxy: git egress proxy tarafından kullanılan IP adresleri
IP aralıkları CIDR gösterimiyle yayımlanır. Gerekirse çevrimiçi bir dönüştürme aracı kullanarak CIDR gösterimini IP adresi aralıklarına dönüştürebilirsiniz.
IP aralıklarını kullanma
Yayımlanan bu IP aralıkları Cloud Agents tarafından şunlar için kullanılabilir:
- Uzak repoları klonlamak ve bunlara push yapmak (git egress proxy kullanılmadığı sürece)
- Paketleri ve bağımlılıkları indirmek
- Harici hizmetlere API çağrıları yapmak
- Agent yürütülürken web kaynaklarına erişmek
Kuruluşunuz ağ erişimini denetlemek için güvenlik duvarı kuralları veya IP izin listeleri kullanıyorsa, Cloud Agents'ın hizmetlerinize düzgün şekilde erişebilmesini sağlamak için bu IP aralıklarını izin listesine eklemeniz gerekebilir.
Önemli noktalar:
- Ölçeklendirme ve operasyonel ihtiyaçlar nedeniyle IP adreslerimizde zaman zaman değişiklik yaparız.
- IP adreslerini izin listesine eklemeyi birincil güvenlik mekanizmanız olarak önermiyoruz.
- Bu IP aralıklarını kullanmanız gerekiyorsa JSON API uç noktasını düzenli olarak izlemenizi önemle tavsiye ederiz.
Git çıkış proxy'si ve IP izin listesi
Cursor, IP izin listeleri için Git çıkış proxy'si kullanma özelliğine benzer ancak farklı bir özelliği destekler. Bu proxy, tüm Git trafiğini daha sınırlı bir IP kümesi üzerinden yönlendirir ve GitHub, GitLab, Azure DevOps ve Bitbucket dahil tüm Git host'larında çalışır.
Git host'ları için, Cursor GitHub uygulamasıyla doğrudan entegre olduğundan yukarıdaki bağlantıda açıklanan IP izin listesi yapılandırmasını öneririz.
Proxy IP'lerini doğrudan bir izin listesine eklemeniz gerekiyorsa şu adresleri kullanın:
184.73.225.1343.209.66.1252.44.113.131Cursor Review IP'leri
Ekibiniz Cursor Review ile birlikte Cloud Agents kullanıyorsa, yukarıdaki git egress proxy IP'lerine ek olarak aşağıdaki IP'leri izin listesine ekleyin:
34.192.39.18250.16.106.25544.217.29.1243.223.245.20154.164.185.1034.194.133.2335.170.116.221Bu IP adresleri kararlıdır. Liste değişirse, IP izin listelerini kullanan ekipler herhangi bir adres eklenmeden veya kaldırılmadan önce önceden bilgilendirilir.
Özel GitHub Enterprise Server veya GitLab Enterprise dağıtımlarına sahip Kurumsal müşteriler, Cloud Agents ve Bugbot'un özel kaynak kontrol sistemlerine erişebilmesi için özel bağlantı seçeneklerini kullanabilir.