Foundry Agent Service təhlükəsizliyi

Foundry Agent Service-də persistent memory-nin dəyəri odur ki, agent sessiyalar, cihazlar və workflow-lar arasında istifadəçi kontekstini saxlaya bilir. Amma təhlükəsizlik baxımından bu, transient prompt hücumlarını persistent riskə çevirir. Microsoft-un zero-trust memory safety sənədi açıq ifadə edir ki, persistent memory cross-context influence yaradır və blast radius-u böyüdür. Foundry memory konsept sənədi də prompt injection və memory corruption risklərini ayrıca qeyd edir. Yəni burada əsas məsələ təkcə “agent daha ağıllı oldu” deyil; artıq agentin yaddaşına nə məqaləldığını, nə qədər saxlanıldığını, hansı scope-da ayrıldığını və hansı hallarda geri çağırıldığını idarə etmək lazımdır.

Persistent memory-nin üç növü var: user profile memory, chat summary memory və procedural memory. Onların hər biri fərqli hücum səthinə malikdir. User profile poisoning sizi səhv personalization-a, chat summary poisoning yanlış continuity-yə, procedural memory poisoning isə təhlükəli automation pattern-lərinə aparır. Microsoft Foundry memory usage sənədi store-level retention, item-level CRUD və remember/forget command-larını təqdim etməklə artıq governance instrumentlərini verir; bu da o deməkdir ki, security team persistent memory-ni “öz-özünə idarə olunan AI feature” kimi deyil, data lifecycle obyekti kimi idarə etməlidir.

Arxitektura və Dəyişikliyin Mahiyyəti.
Sağlam arxitektura dörd qat üzərində qurulmalıdır. Birinci qat scope isolation-dir: eyni store içində user ID, session ID və resource ID-lərin qarışdırılması cross-user bleed riskini yaradır. Microsoft-un LangChain/LangGraph memory guidance-i scope-ların sabit user identity və ephemerial session identity ilə ayrılmasını tövsiyə edir. İkinci qat write gating-dir: hər gələn məlumat yaddaşa avtomatik məqaləlmamalıdır. Zero-Trust memory safety guidance məhz “intent and provenance” əsaslı write gate dizaynını tövsiyə edir. Üçüncü qat retrieval risk decision-dir: retrieved memory həmişə trusted context sayılmamalıdır. Dördüncü qat isə observability-dir: memory writes, tool çağırışları, latency, failures və content annotation-lar end-to-end trace olunmalıdır.

Prompt Shields bu modelin guardrail qatıdır. Microsoft Foundry sənədi göstərir ki, Prompt Shields iki əsas hücum sinfini aşkarlayır: user prompt attacks və document attacks. Document attacks xüsusilə persistent memory üçün kritikdir, çünki sənəd, e-poçt və ya veb kontent içindəki gizli təlimatlar agent sessiyasını hijack etməyə cəhd edir. Spotlighting isə üçüncü tərəf sənədləri base-64 formalı “less trusted” input kimi işarələməklə indirect attack riskini azaldır, amma token xərci və input size limiti yan effektləri yarada bilər. Persistent memory məqaləları üçün bu guardrail-lər write-before-store pipeline-da yerləşdirilməlidir.

Network və identity qatında Foundry private networking guidance çox aydındır: agent service standart private setup ilə public egress-i bağlaya, agent compute-i delegated subnet-ə yerləşdirə və private resurslara private endpoint-lərlə çıxış verə bilir. Amma Azure AI Search, Azure Storage və Azure Cosmos DB üçün private endpoint-lər avtomatik yaranmır; onları ayrıca qurmaq lazımdır. Agent identity concepts sənədi də Microsoft Foundry-nin agent identity-ləri avtomatik provision etdiyini, RBAC least-privilege tətbiqinin isə yenə sizin məsuliyyətinizdə qaldığını bildirir. Əgər security architecture bunu nəzərə almırsa, agent “private” görünsə də, faktiki dependency layer-də public leakage yarana bilər.

Adım-adım Tətbiq və Konfiqurasiya.
Aşağıdakı Python nümunəsi persistent memory store yaratmağın təhlükəsiz başlanğıc skeleton-udur. Məqsəd odur ki, store explicit yaradılsın, uyğun chat və embedding deployment-ləri təyin edilsin, scope idarə edilsin və sonradan selective cleanup mümkün olsun. Microsoft-un rəsmi nümunəsində memory stores üçün create/get/search/update/delete semantikası, eləcə də RBAC ilə identity əsaslı giriş tövsiyə olunur.

import os
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import MemoryStoreDefaultDefinition, MemoryStoreDefaultOptions
from azure.identity import DefaultAzureCredential
from azure.core.exceptions import ResourceNotFoundError

endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
client = AIProjectClient(endpoint=endpoint, credential=DefaultAzureCredential())
store_name = "prod-user-memory"

try:
    store = client.beta.memory_stores.get(store_name)
except ResourceNotFoundError:
    definition = MemoryStoreDefaultDefinition(
        chat_model="gpt-5.2",
        embedding_model="text-embedding-3-small",
        options=MemoryStoreDefaultOptions(
            user_profile_enabled=True,
            chat_summary_enabled=True,
        ),
    )
    store = client.beta.memory_stores.create(
        name=store_name,
        description="Scoped persistent memory for production agents",
        definition=definition,
    )

from microsoft.opentelemetry import use_microsoft_opentelemetry

use_microsoft_opentelemetry(
    enable_azure_monitor=True,
    sampling_ratio=1.0,
    instrumentation_options={
        "langchain": {
            "enabled": True,
            "agent_name": "prod-claims-agent",
            "agent_id": "claims-agent-prod"
        }
    }
)

# Required environment variables:
# APPLICATIONINSIGHTS_CONNECTION_STRING
# AZURE_OPENAI_ENDPOINT
# AZURE_OPENAI_CHAT_DEPLOYMENT
# AZURE_OPENAI_VERSION

Audit və forensics üçün Application Insights/Log Analytics KQL istifadə olunmalıdır. Microsoft-un telemetry data model sənədi request, dependency, exception və generative AI content məlumatlarının fərqli cədvəllərdə saxlandığını, operation_Id ilə korelyasiya edilə bildiyini göstərir. Bu, agent run daxilində hansı tool çağırışının, hansı exception və hansı suspicious content event ilə əlaqəli olduğunu zəncir şəklində araşdırmağa imkan verir.

AppRequests
| where TimeGenerated > ago(1h)
| where Name has "agent" or OperationName has "agent"
| project TimeGenerated, OperationId, Name, DurationMs, Success, ResultCode
| join kind=leftouter (
    AppDependencies
    | project OperationId, DependencyType, DependencyName=Name, Target, Success, ResultCode, DurationMs
) on OperationId
| join kind=leftouter (
    AppExceptions
    | project OperationId, ExceptionType, ProblemId
) on OperationId
| order by TimeGenerated desc

Mümkün Problemlər və Troubleshooting Ssenariləri.
Ən təhlükəli ssenari persistent memory poisoning-dir. Əlamətləri bunlardır: agent eyni yanlış qaydanı sessiyalar boyunca təkrarlayır, istifadəçi dəyişmədiyi halda persona davranışı dəyişir, əvvəlki sessiyalarda olmayan prosedurları “norma” kimi tətbiq edir. Bu halda memory scope partitioning, recent memory writes, prompt shield annotation nəticələri və memory retrieval nəticələrinin hamısı birlikdə araşdırılmalıdır. Zero-Trust guidance write-ləri provenance və intent əsaslı gate-ləməyi, retrieval-i risk qərarı kimi görməyi tövsiyə edir.

İkinci ssenari trace visibility yoxluğudur. Əgər portalda trace görünmürsə, ya Application Insights bağlanmayıb, ya yeni trafik yoxdur, ya ingestion gecikir, ya da RBAC çatmır. Microsoft bunu birbaşa troubleshooting cədvəlində vurğulayır. Log query üçün Log Analytics Reader, protected tables olduqda əlavə Privileged Monitoring Data Reader lazımdır. Bu problem çox vaxt “agent işləmir” kimi yozulur, halbuki əslində müşahidəedilmə stack-i tam deyil.

Üçüncü ssenari private networking drift-dir. Foundry resource private olsa da, Storage/Search/Cosmos dependency-ləri üçün private endpoint-lər ayrıca qurulmayıbsa və DNS zone-lar düzgün bağlanmayıbsa, agent bəzi tool çağırışlarında timeout və ya access failure alacaq. Burada yoxlama zənciri: subnet delegation, public network access flag-ləri, nslookup, private endpoint health və tool-level dependency traces-dir. Ən Yaxşı Təcrübələr.
Memory-ni default-on convenience kimi deyil, governed data plane kimi idarə edin. Hər tenant və hər use-case üçün ayrı scope və lazım gəlsə ayrı store istifadə edin. Default TTL təyin edin, explicit “forget” path saxlayın, prompt shields-i annotate rejimində pilot edib sonra block rejiminə keçin, production-da sensitive content capture-u söndürün, private networking-i dependency layer daxil olmaqla tam bağlayın, agent identity-lərə minimal RBAC verin və Application Insights üzərində KQL əsaslı anomaliya dashboard-u qurun