Foundry Hosted Agents'ta Network Egress Denetimi

⏱️ 8 dk okuma📅 25 Eylül 2026

Bir agent’a hangi araçları verdiğinizi biliyorsunuz da, o süreç çalışırken nereye istek gönderebiliyor? Microsoft Foundry Agent Service’in hosted agent’lar için getirdiği network egress (ağ çıkışı) kontrolleri, bu soruyu uygulama kodunun dışında, gözden geçirilebilir bir politika olarak yanıtlamayı hedefliyor. Bu yazıda kaynaktaki fatura agent’ı senaryosunu izliyorum: hedef listesi nasıl tanımlanıyor, agent sürümüne nasıl iliştiriliyor, sınır çalışma zamanında nasıl test ediliyor.

Önizleme uyarısı: Kaynak makale, network egress kontrollerinin genel kullanıma açılmadığını (GA olmadığını), önizleme için SLA bulunmadığını ve üretim kullanımı için tasarlanmadığını açıkça belirtiyor. Anlatılan akış geliştirme ve değerlendirme ortamları içindir.

Araç listesi bir ağ sınırı değildir

Senaryo basit. Fatura agent’ı tedarikçi bilgisini sorguluyor, ödeme kaydını kontrol ediyor; işini yapmak için iki API’ye ihtiyacı var. Ama işlenen bir belgenin içinden tanımadığınız bir yükleme bağlantısı çıkabilir, yeni eklenen bir yardımcı kütüphane beklemediğiniz bir URL’i takip edebilir.

Tek bir HTTP sarmalayıcısının içine yazılmış kural, yalnızca çağrı o sarmalayıcıdan geçtiğinde işe yarar. Kaynaktaki yaklaşım hedef kararını hosted agent tanımının üzerine taşıyor. Karşılaştırma şöyle özetleniyor:

Yalnızca uygulama içi kontroller: Her istemciyi ve yardımcı sınıfı hedef denetimi açısından tek tek gözden geçirmeniz gerekir; başarılı bir araç yanıtı elinizdeki başlıca sinyaldir.
Açık egress politikası: Adlandırılmış, sıralı bir hedef kuralları kümesini gözden geçirirsiniz; hem izin verilen hem de kasıtlı olarak reddedilen bir çağrıyı test edersiniz.

Kaynak şunu da not düşüyor: Bu görselleştirme uygulama trafiğine dair kavramsal bir bakış, Foundry’nin gerekli platform bağlantıları ayrıca izinli ve “varsayılan deny” ifadesi her çalışma zamanı bağlantısının engellendiği anlamına gelmiyor.

1. Agent’ın ihtiyaç duyduğu hedefleri tanımlayın

Örnekte bir finans API’si ile bir tedarikçi API’si onaylanıyor, test amaçlı yükleme hedefi bilinçli olarak onaylanmıyor. Geniş bir joker karakter yerine tam ana bilgisayar adlarıyla başlarsanız politikayı inceleyen kişi sınırı yorum yapmadan anlar.

Başlamadan önce gerekenler: bir test Foundry projesi, dağıtılabilir bir hosted agent imajı, hesap düzeyinde RAI politikası oluşturma izni ve kontrolünüzdeki HTTPS uç noktaları. Aşağıdaki .example uzantılı adlar canlı servis değil, yer tutucu; sahibi olduğunuz host’larla değiştirin.

Politika gövdesini invoice-egress.json olarak kaydedin. Belgelenmiş ARM kaynak şeklini kullanır, hem ağ modunu hem varsayılan eylemi bilinçli olarak ayarlar:

{
"properties": {
"basePolicyName": "Microsoft.DefaultV2",
"mode": "Blocking",
"egressPolicy": {
"mode": "Audit",
"defaultAction": "Deny",
"rules": [
{
"name": "allow-finance",
"ruleType": "Fqdn",
"match": { "host": "finance.contoso.example" },
"action": { "actionType": "Allow" }
},
{
"name": "allow-vendors",
"ruleType": "Fqdn",
"match": { "host": "vendors.contoso.example" },
"action": { "actionType": "Allow" }
}
]
}
}
}

Buradaki ayrımı karıştırmayın. properties.mode içerik güvenliği ayarıdır, ağ ayarı ise properties.egressPolicy.mode altındadır. Egress kurallarında ilk eşleşen kural eylemi belirler, eşleşme yoksa varsayılan eylem uygulanır.

JSON dosyasının bulunduğu dizinde, Azure CLI kurulu şekilde aşağıdaki komutları çalıştırın. Üç kaynak değerini kendi ortamınıza göre değiştirin ve hesap üzerinde RAI politikası yazabilen bir kimlikle oturum açın. az rest, oturumunuzdan Azure Resource Manager token’ını alır ve JSON dosyasını istek gövdesi olarak gönderir:

SUBSCRIPTION_ID="<your-subscription-id>"
RESOURCE_GROUP="<your-resource-group>"
ACCOUNT_NAME="<your-foundry-account>"
az login
az account set --subscription "$SUBSCRIPTION_ID"
ACCOUNT_ID="/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RESOURCE_GROUP}"
ACCOUNT_ID="${ACCOUNT_ID}/providers/Microsoft.CognitiveServices/accounts/${ACCOUNT_NAME}"
export RAI_POLICY_ID="${ACCOUNT_ID}/raiPolicies/invoice-egress-audit"
POLICY_URL="https://management.azure.com${RAI_POLICY_ID}?api-version=2026-05-15-preview"
az rest --method put --url "$POLICY_URL" \
--headers "Content-Type=application/json" \
--body "@invoice-egress.json"

Agent sürümü oluşturmadan önce kaydedilen politikayı geri okuyun; ID’nin RAI_POLICY_ID ile eşleştiğini, ağ modunun Audit, varsayılanın Deny olduğunu ve iki host adının da yerinde durduğunu doğrulayın:

az rest --method get --url "$POLICY_URL" \
--query "{id:id,egressPolicy:properties.egressPolicy}" \
--output json

Bu GET yalnızca saklanan yapılandırmayı doğrular, çalışma zamanındaki zorlamayı değil. Gerçek kontrol 3. adımdaki allow/deny probe’larıdır.

Not: Bu alıştırma için yeni bir kaynak kullanın. İçerik güvenliği ve ağ ayarlarını birlikte barındıran mevcut bir politikayı bu kısaltılmış örnekle değiştirmeyin, diğer kontrollerini olduğu gibi bırakın.

2. Politikayı hosted agent’a iliştirin

Python SDK tarafında bağlama işlemi RaiConfig ile ifade ediliyor. RAI_POLICY_ID değişkenine yalnızca invoice-egress-audit adını değil, tam ARM ID’sini vermeniz gerekiyor. Aşağıdaki sürüm oluşturma örneği, Responses protokolünü zaten uygulayan bir container’ı hedefliyor.

Dağıtım ortamınızda azure-ai-projects>=2.2.0 ve azure-identity paketlerini kullanın, projeniz için yetkili bir kimlikle kimlik doğrulaması yapın. Test imajını oluşturmadan önce 3. adımdaki tanılama fonksiyonunu ekleyin, requests bağımlılığını dahil edin ve fonksiyonu agent’ın araç/istek dağıtıcısına kaydedin. FOUNDRY_PROJECT_ENDPOINT proje URL’si, AGENT_IMAGE erişilebilir container imajı, RAI_POLICY_ID ise 1. adımdaki politika olmalı.

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
AgentEndpointProtocol, ContainerConfiguration,
HostedAgentDefinition, ProtocolVersionRecord, RaiConfig,
)
with AIProjectClient(
endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
credential=DefaultAzureCredential(),
allow_preview=True,
) as project:
version = project.agents.create_version(
agent_name="invoice-agent",
definition=HostedAgentDefinition(
cpu="1",
memory="2Gi",
container_configuration=ContainerConfiguration(
image=os.environ["AGENT_IMAGE"],
),
protocol_versions=[
ProtocolVersionRecord(
protocol=AgentEndpointProtocol.RESPONSES,
version="2.0.0",
)
],
rai_config=RaiConfig(
rai_policy_name=os.environ["RAI_POLICY_ID"],
),
),
)
print(f"Created {version.name}, version {version.version}")

Ardından normal hosted agent dağıtım/başlatma akışını tamamlayın, test trafiğini tam olarak bu sürüme yönlendirin. Sürümü geri okuyup politika referansını kontrol edin. Yine de authoring API’sinin döndürdüğü bir nesne, dışarı çıkan trafiğe dair bir sınırın kanıtı değildir; çalışma zamanını test etmek gerekir.

Uygulama hala kendi API’lerine kimlik doğrulaması yapar. Bir hedefe izin vermek, o hedefte yetki verildiği anlamına gelmez. Finans ve tedarikçi API’lerinin kimlik bilgileri ile yetkilendirme kontrollerini ağ politikasından ayrı tutun.

Portal üzerinden ilerlemeyi tercih ederseniz, herkese açık rehber bir guardrail oluşturmayı, Network egress kurallarını eklemeyi ve bunu hosted agent’a atamayı anlatıyor. Her durumda gözden geçirilebilir artefakt politikanın kendisidir, bir prompt talimatı değil.

3. Agent’ın cevabını değil, sınırı test edin

Test agent’ına iki zararsız probe URL’i verin. Biri politikadaki finans host’uyla eşleşmeli, diğeri izin verilmeyen ve platforma ait olmayan, kontrolünüzdeki bir host olmalı. İki uç nokta da probe için 200 döndürmeli ve gelen istekleri kaydetmeli. Yalnızca sentetik veri kullanın.

Bu probe’u dağıtımdan önce test imajına tanılama aracı veya istek işleyici olarak ekleyin; yönetilen hosted agent container’ları bu akış için etkileşimli bir kabuk sunmuyor. requests paketini dahil edin, INVOICE_ALLOWED_PROBE_URL ve INVOICE_BLOCKED_PROBE_URL değişkenlerini test çalışma zamanında tanımlayın. run_egress_probe fonksiyonunu framework’ünüzün dağıtıcısına kaydedin, dağıtılmış agent’ın Responses uç noktası üzerinden çağırın.

import os
import requests
def run_egress_probe() -> dict[str, int]:
targets = {
"allowed": os.environ["INVOICE_ALLOWED_PROBE_URL"],
"blocked": os.environ["INVOICE_BLOCKED_PROBE_URL"],
}
ca_bundle = os.environ["REQUESTS_CA_BUNDLE"]
results = {}
for label, url in targets.items():
response = requests.get(
url,
verify=ca_bundle,
timeout=10,
allow_redirects=False,
)
results[label] = response.status_code
return results

Tanılamanın gerçekten çalıştığını doğrulayın. Aynı kodu kendi iş istasyonunuzda çalıştırmak, hosted agent egress sınırını test etmez. Yönlendirmeleri (redirect) kapalı tutmak da test edilen hedefi belirsizlikten kurtarır.

Audit ve Enforced denemeleri

Audit modunda gözlenen çağrıları “reddedilecekti” (would-deny) kanıtlarıyla karşılaştırın. Çağrının network egress karar span’larını veya projenin Application Insights kayıtlarını inceleyin. Bir olayın bulunmamasını, çağrının izinli olduğunun kanıtı saymayın.

Zorlama denemesi için aynı gövdeden invoice-egress-enforced adlı yeni bir politika oluşturun, yalnızca ağ modunu Enforced olarak değiştirin. Bu yeni politikayı yeni bir test sürümüne iliştirip probe’ları tekrarlayın. Audit sürümünü ayrı tutun ve bir düzenlemenin çalışan her oturumu anında değiştireceğini varsaymayın.

Probe	Audit denemesi	Enforced denemesi
Onaylı finans uç noktası	200; istek uç noktaya ulaşır.	200; istek uç noktaya ulaşır.
Onaysız test uç noktası	200; “reddedilecekti” kanıtı.	Proxy 403; uç noktaya istek ulaşmaz.

Bunlar sağlıklı ve kontrollü uç noktalar için beklenen sonuçlar, yakalanmış test çıktısı değil. Hedefin kendisi de 403 döndürebilir; DNS veya TLS hatası ise başarılı bir reddetme sayılmaz. Testi “geçti” saymadan önce politika kararını hedefin alım günlüğüyle karşılaştırın.

TLS doğrulamasını açık bırakın. Probe, çalışma zamanının sağladığı CA bundle’ını kullanır. Testi geçirmek için bu bundle’ı imajınıza kopyalamayın, doğrulamayı da kapatmayın; sertifika yönetimi rehberliğine bakın.

Basit bir izin listesi yetmediğinde

Tedarikçi servisi her istekte gizli olmayan bir iş yükü etiketi bekliyorsa, bir Transform kuralı bu başlığı ekleyebilir veya değiştirebilir. Onaylı bir servis başka bir uç noktanın arkasına taşındıysa, bir Rewrite kuralı hedefi değiştirebilir. Bunlar izin ver/engelle kararlarından ibaret değil, bilinçli istek değişiklikleri.

Burada kural sırası kritik. Transform’dan önce kazanan bir Allow kuralı, sonraki başlık düzenlemesinin hiç çalışmaması demek. Gereken davranışı eşleşen kuralın içine koyun ve hedefin gerçekte ne aldığını test edin. Resmî egress örneği, başlık ve rewrite alıştırmalarını ayrı ayrı içeriyor.

Audit her eylem için bir prova değildir. Audit modunda Deny engellemeyi durdurur ama Transform ve Rewrite yine çalışır. Bu yüzden bu akışta hassas olmayan statik değerler kullanın. Dağıtılan agent’ın kimliği hedef kaynakta gerekli RBAC rolüne sahipse managed identity değer referansları destekleniyor; gizli anahtar (secret) değer referansları önizleme sırasında desteklenmiyor.

Her kontrolün görevini ayrı tutun

Fatura agent’ı için üç soruyu ayrı ayrı sorun. Bu doğru hedef mi? Çağıran taraf orada yetkili mi? Gönderilen veri bu hedefe uygun mu? Bir hedef kuralı yalnızca ilkini yanıtlar. Onaylı bir tedarikçi yine de yanlış faturayı alabilir, izin verilen bir API yine de yetkisiz çağıranı reddedebilir.

Mevcut uygulama doğrulamanızı, kimlik kontrollerinizi ve ağ tasarımınızı koruyun. Bu akışı belgelenmiş hosted agent HTTP/HTTPS yoluyla sınırlı tutun, sonucu rastgele protokollere veya diğer agent türlerine genellemeyin.

Kaynak makale, Toolbox yazısının “agent bir aracı çağırırken kimin adına hareket ediyor?” sorusunu, bu yazının ise “hosted agent nereye bağlanabiliyor?” sorusunu ele aldığını vurguluyor. Bunlar farklı tasarım soruları ve biri diğerini doğrulama ihtiyacını ortadan kaldırmıyor.

Tek agent, iki hedefle başlayın

Küçük başlayın: bir işe yarar uygulama çağrısı, bilinçli bir negatif test, satır satır açıklayabileceğiniz bir politika. Önce Audit kanıtlarını inceleyin, sonra aynı deneyi Enforced modunda tekrarlayın, bağlantının iki ucunu da kontrol edin. Fatura agent’ı için istenen sonuç net: Finans sorguları çalışmaya devam eder, test yükleme uç noktası hiçbir şey almaz. Yayın öncesi kontrol olarak bu, agent’ın “talimata uydum” demesinden çok daha güçlü.

Kaynaklar ve İleri Okuma

devblogs.microsoft.com

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102