Foundry Hosted Agents’ta Kullanıcı ve Oturum İzolasyonu

Foundry hosted agent mimarisinde izolasyon iki ayrı kontrole dağıtılmış durumda ve bu iki kontrol birbirinden bağımsız çalışıyor: kullanıcı izolasyonu ve Foundry hosted session izolasyonu. Birincisi “bu isteğin verisi kime ait?” sorusunu cevaplar, ikincisi “kodun çalıştığı ve dosyaların kalıcı olarak durduğu sandbox hangisi?” sorusunu. İkisini ayrı ayrı düşünmek, çok kullanıcılı bir uygulamada yanıt geçmişinin ve dosya sisteminin nasıl ayrışacağını doğru tasarlamayı sağlıyor.

Her iki kontrolde de değeri ya Foundry çözüyor ya da uygulama açıkça sağlıyor. Doğrudan çağıran istemciler, güvenilen bir ara katman (middle tier), uygulamanın kendi yönettiği oturumlar ve paylaşımlı oturum havuzları aynı modelle destekleniyor.

İlgili içerik: WSLC Mimarisi: Oturum, Depolama ve Ağ Modeli

Hangi parça GA, hangisi ön sürümde?

Foundry hosted agents özelliği Microsoft Foundry tarafında genel kullanıma açık (GA) durumda. AgentServer SDK’ları ile.NET ve Python için Microsoft Agent Framework Foundry hosting paketleri ise hala ön sürüm (pre-release) aşamasında, yani API yüzeyinin değişebileceğini varsayarak ilerlemek gerekiyor.

İlgili içerik: Foundry Hosted Agents'ta Network Egress Denetimi

İki kontrolün tanımı

Kontrol	Neyi temsil eder	Seçenekler
Kullanıcı izolasyonu	Mevcut isteğin temsil ettiği kullanıcı	Çağıranın Microsoft Entra kimliği veya güvenilen bir ara katmanın gönderdiği delege edilmiş kimlik
Foundry hosted session izolasyonu	agent_session_id ile temsil edilen, VM düzeyinde izole sandbox	İlk istekte oluşturulan oturum veya uygulamanın sağladığı mevcut oturum kimliği

Sık karıştırılan bir nokta var. Foundry hosted session bir konuşma (conversation) değildir. Konuşma, mesaj ve araç çağrısı geçmişini tutar; Foundry hosted session ise sandbox hesaplama kaynağını ve kalıcı dosyaları barındırır. Yaşam döngüleri de birbirinden farklıdır.

Kullanıcı izolasyonu nasıl çözülüyor?

Doğrudan erişimde Foundry, kullanıcıyı çağıranın Microsoft Entra token’ından çözer, uygulamanın ekstra bir şey yapması gerekmez. Kendi kullanıcılarını kendisi doğrulayan uygulamalarda durum değişir; orada güvenilen bir ara katman her istekte kararlı bir delege edilmiş kimlik gönderir.

Delege edilmiş kimlik, Foundry hosted session kimliğinden bağımsızdır. Farklı kullanıcı konuşmaları ayrı sandbox’lar kullanabilir, ara katmanın seçtiği tek bir sandbox’ı da paylaşabilir.

.NET

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
ChatClientAgentSession userConversationSession =
await agent.CreateFoundryHostedAgentSessionAsync(
/* hostedSessionId: foundryHostedSessionId, */
userIdentity: userIdentity);
await agent.RunAsync(
"Analyze the uploaded files.",
userConversationSession);
string? delegatedUserIdentity =
userConversationSession.FoundryHostedAgentUserIdentity;

Python

await agent.run(
"Analyze the uploaded files.",
session=user_conversation_session,
client_kwargs={
"extra_headers": {
"x-ms-user-identity": user_identity,
}
},
)

İki dil arasındaki davranış farkı pratikte önemli. Agent Framework,.NET tarafında delege edilmiş kimliği AgentSession nesnesiyle birlikte saklar; o oturumu yeniden kullandığınızda veya geri yüklediğinizde aynı kimlik her çalıştırmada otomatik gönderilir. Python tarafında mevcut API kimliği her çağrıda ayrı ayrı iletir.

Delege edilmiş kimlik değeri Agent Framework açısından opak bir veridir, framework onu yorumlamaz. Uygulamanın doğruladığı kullanıcı ile bu değer arasındaki eşlemenin sahibi güvenilen ara katmandır. Gerekli izinler ve güvenlik modeli için Microsoft’un kullanıcı başına izolasyon rehberine bakmak gerekiyor.

Oturum kimliğini kim oluşturur?

İstek içinde agent_session_id yoksa Foundry yeni bir hosted session oluşturur ve kimliğini döner. Uygulama isterse oturumu Foundry project client üzerinden kendisi oluşturup dönen kimliği sağlayabilir.

Foundry project client ile oturum oluşturma (.NET)

using Azure.AI.Projects;
using Azure.AI.Projects.Agents;
ProjectAgentSession foundryHostedSession =
await projectClient.AgentAdministrationClient.CreateSessionAsync(
agentName,
new VersionRefIndicator(agentVersion));
string foundryHostedSessionId =
foundryHostedSession.AgentSessionId;

Foundry project client ile oturum oluşturma (Python)

from azure.ai.projects.models import VersionRefIndicator
foundry_hosted_session = await project_client.agents.create_session(
agent_name,
version_indicator=VersionRefIndicator(
agent_version=agent_version,
),
)
foundry_hosted_session_id = (
foundry_hosted_session.agent_session_id
)

Kimlik ister servis tarafından oluşturulmuş olsun ister uygulama tarafından verilmiş, Agent Framework onu kendi AgentSession nesnesinde tutar. Buradaki ayrım kritik: Agent Framework nesnesi uzaktaki Foundry hosted session’ı oluşturmaz, yalnızca kimliği taşır. Aynı nesneyle yapılan sonraki çağrılar da bu yüzden ekli kimliği gönderir, aynı kalıcı $HOME dizinine, yüklenmiş dosyalara ve çalışma durumuna ulaşır.

Foundry tarafından atanan veya uygulama tarafından verilen oturum (.NET)

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
ChatClientAgentSession session =
await agent.CreateFoundryHostedAgentSessionAsync(
/* hostedSessionId: foundryHostedSessionId
Omit this argument for Foundry to assign the ID
on the first invocation. */);
await agent.RunAsync("Analyze the uploaded files.", session);
string? resolvedFoundryHostedSessionId =
session.FoundryHostedAgentSessionId;

Foundry tarafından atanan veya uygulama tarafından verilen oturum (Python)

from agent_framework import AgentSession
from agent_framework.foundry import (
FOUNDRY_HOSTED_AGENT_SESSION_ID_KEY,
)
session = AgentSession()
# Optional: attach an ID created through the Foundry project client.
session.state[
FOUNDRY_HOSTED_AGENT_SESSION_ID_KEY
] = foundry_hosted_session_id
await agent.run("Analyze the uploaded files.", session=session)
foundry_hosted_session_id = session.state[
FOUNDRY_HOSTED_AGENT_SESSION_ID_KEY
]

Hangi yaklaşım hangi senaryoya uyuyor?

Uygulama tarafından sağlanan kimlikler ilk çağrıdan önce dosya yüklemeye, açık yaşam döngüsü yönetimine, kararlı iş yükü yerleşimine (workload placement) ve sınırlı sayıda oturumdan oluşan havuzlara uygun. Servis tarafından oluşturulan kimlikler ise talep anında oturum tahsisi (on-demand allocation) gerektiren senaryolara hizmet ediyor.

Havuzlu bir tasarım şöyle işliyor: ara katman kullanıcıları sınırlı sayıda Foundry hosted session kimliğine eşler, her istekte de delege edilmiş kimliği gönderir. Bu kurulumda Foundry yanıt zincirlerini kullanıcı bazında özel tutar, ama sandbox dosya sistemi paylaşılmaya devam eder. Uygulamanın sahip olduğu dosyalar, veritabanı satırları ve önbellekler için bölümleme anahtarı olarak hem agent_session_id hem kullanıcı kimliği birlikte kullanılabilir.

Kullanıcı izolasyonu veriye kimin erişebileceğini belirliyor, oturum izolasyonu ise kodun ve dosyaların nerede yaşadığını. Paylaşımlı sandbox kullanan bir tasarımda dosya düzeyindeki ayrışmayı uygulama katmanı kurgular.

Kaynaklar ve İleri Okuma

• devblogs.microsoft.com

• Foundry hosted agent isolation with Microsoft Agent Framework (Roger Barreto, Tao Chen)
• Foundry hosted agent oturumlarını kullanıcı başına izole etme
• Foundry hosted agent oturumlarını yönetme
• Tek bir Foundry hosted session içinde birden fazla kullanıcıyı çoğullama
• Microsoft Agent Framework ile Foundry Hosted Agents dokümantasyonu
• Agent Framework.NET Foundry hosted agent örnekleri
• Agent Framework Python Foundry hosted agent örnekleri
• From Local to Production: Foundry Hosted Agents ile dağıtım
• Microsoft Agent Framework at BUILD 2026 duyurusu
• Foundry Hosted Agents ile MAF’ı prod’a taşımak
• Hosted Agents: ajanlar için güvenli ve ölçekli bulut