Guardrails, security, और network isolation

अवधारणा 14 ने दिखाया कि evaluations और AI Red Teaming Agent unsafe जवाब, कमज़ोर tool use, और adversarial tricks users से पहले पकड़ लेते हैं। Guardrails production controls हैं जो हर request पर वही नियम लगाते हैं। Guardrail Microsoft Foundry में controls का एक नाम वाला समूह है। हर control बताता है कौन सा risk ढूँढना है, किन intervention points पर scan होगा, और risk मिलने पर क्या action लेना है।

Foundry guardrails Azure द्वारा बेचे गए models और Foundry Agent Service में बने agents दोनों पर लगाता है। Agent guardrails preview में हैं। Guardrails हानिकारक content को चिह्नित करने के लिए Azure AI Content Safety के classification models इस्तेमाल करते हैं। यह guardrail system Azure द्वारा बेचे Foundry models पर लागू होता है, सिवाय audio transcription models द्वारा संसाधित prompts और completions के। Foundry Control Plane में सिर्फ़ register किए agents पर, बिना Foundry Agent Service में develop किए, यह लागू नहीं होता।

• Foundry project, कम से कम एक model deployment, और guardrails manage करने वाली role चाहिए, जैसे Foundry Account Owner।
• एक guardrail एक ही project में कई models और कई agents से जुड़ सकता है।
• API configuration और app design filtering व्यवहार बदल सकते हैं, इसलिए guardrails को पूरे design का हिस्सा मानें, एक बार की setting नहीं।
• Hosted agents preview में network egress controls भी उसी guardrail में हो सकते हैं, जो outbound destinations सीमित करते हैं; ये rules सिर्फ़ hosted agents पर लागू होते हैं।

Tool वाला agent उन जगहों पर गलत हो सकता है जहाँ chat model कभी नहीं पहुँचता: बाहर जाते समय unsafe arguments, या tool से वापस आया जहर भरा text। Foundry इसलिए चार intervention points पर scan करता है। User input वह prompt है जो user भेजता है। Output user को मिलने वाला अंतिम completion है। Tool call (preview) वह action और data है जो agent tool को भेजने वाला है, साथ में कौन सा tool और arguments। Tool response (preview) tool का जवाब है agent run के अंदर, इससे पहले कि वह agent memory में जाए या user को दिखे।

Foundry portal में guardrail बनाते समय controls चुनें और हर control को intervention points पर लगाएँ। उदाहरण: tool responses में indirect attacks रोकने के लिए Indirect attack control जोड़ें, intervention point Tool response रखें, और action Annotate and block चुनें। Tool call और tool response checks के लिए tool में moderation support चाहिए। अभी इसमें Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, और Browser Automation शामिल हैं। Agent दूसरे tools इस्तेमाल करे तो उन points पर controls उन tools के लिए नहीं चलते। हर point पर guardrail processing लगभग 50–100 ms latency जोड़ती है, content की लंबाई और active controls की संख्या पर निर्भर।

Hate, Sexual, Self-harm, और Violence जैसे content risks पर हर control एक blocking level इस्तेमाल करता है जो तय करता है कौन सी severity रुकेगी। Off का मतलब उस risk के लिए कुछ block नहीं, हालाँकि annotations मिल सकते हैं। Low सिर्फ़ high-severity content रोकता है और सबसे कम सख्त विकल्प है। Medium medium- और high-severity content रोकता है। High low-, medium-, और high-severity content रोकता है और सबसे सख्त है। Inputs के लिए content harms बंद करने की अनुमति सभी customers को है; outputs के लिए Azure द्वारा बेचे models पर approved modified guardrails चाहिए।

• Harm categories Hate, Sexual, Self-harm, और Violence models और agents दोनों पर (agents preview में)।
• User prompt attacks और Indirect attacks models और agents दोनों पर; user input, output, और agents के लिए ज़रूरत हो तो tool call या tool response पर भी।
• Groundedness (preview) और Spotlighting (preview) models पर, agents पर नहीं; shared guardrail पर वे models के लिए चलते हैं, agents के लिए नहीं।
• Personally identifiable information (preview) और Task Adherence (preview) दोनों पर। Protected material for code और for text दोनों पर।
• Risk मिलने पर models Annotate या Annotate and block इस्तेमाल कर सकते हैं। Agents (preview) सिर्फ़ Annotate and block, Annotate alone नहीं।

Capability reference trust and safety में जुड़े filters बताता है: harm category filters, jailbreak और prompt injection के लिए Prompt Shields, groundedness detection, sensitive data (PII) detection, protected material detection, और task adherence जब agent अपने task से भटके।

Models और agents एक guardrail definition साझा कर सकते हैं, लेकिन हर control दोनों पर नहीं चलता। Tool calls या agent-only risks से जुड़े controls model runs पर छूट जाते हैं। ज़्यादा महत्वपूर्ण: agent को अलग guardrail assignment मिले तो agent traffic के लिए वह assignment underlying model deployment के guardrail की जगह पूरी तरह ले लेता है। Foundry agent पर risks agent guardrail से detect करता है, model guardrail से नहीं।

Default rules व्यवहार अनुमान लगाने में मदद करते हैं। Model deployments Microsoft.DefaultV2 guardrail से शुरू होते हैं जब तक आप न बदलें। Agents के लिए custom guardrail assign करें तो वही use होता है। कुछ assign न करें तो agent model deployment का guardrail inherit करता है। Agent Microsoft.DefaultV2 तभी use करता है जब deployment उसे use करे या आप साफ़ assign करें।

• Agent व्यवहार expected guardrail से न मिले तो Foundry portal या SDK में guardrail agent पर assign है यह जाँचें, सिर्फ़ model पर नहीं।
• Agent safety tune करते समय Groundedness या Spotlighting जैसे agent-unsupported preview risks वाले controls हटाएँ या बदलें।
• Tools से harmful content गुजरे तो Tool call और Tool response controls हैं और Foundry Agent Service preview features project के लिए enabled हैं, यह verify करें।
• Legitimate content block हो तो उस risk के लिए blocking level कम करके देखें, पहले यह न मानें कि classifier गलत है।

कल्पना करें Foundry prompt agent एक online shop के लिए। वह Azure AI Search से order status पढ़ता है और refund function चला सकता है। अवधारणा 14 की red teaming ने user input पर jailbreak और search snippets में indirect injection दिखाए। आप Foundry portal में ShopSupportSafety नाम का guardrail बनाते हैं और उसे agent पर attach करते हैं, सिर्फ़ GPT deployment पर नहीं।

• User input पर User prompt attacks, Annotate and block, ताकि jailbreak prompts model तक न पहुँचें।
• Tool call (preview) पर Violence या Hate Medium, अगर refunds या customer notes में harmful text function में जा सकता है।
• Tool response (preview) पर Indirect attack, Annotate and block, क्योंकि search results में hidden instructions हो सकते हैं।
• Output पर Sexual, Self-harm, Violence, Hate Medium, और Protected material for text अगर जवाब copyrighted policy text verbatim न कहें।
• Azure AI Search और Azure Functions supported tool list में हैं, यह पुष्टि करें ताकि tool-stage controls चलें।

मान लें model deployment input और output पर Violence High use करता है, लेकिन agent guardrail Violence Low set करता है और tool stages पर Violence checks नहीं जोड़ता। User messages और final answers Low severity पर scan होते हैं। Tool calls और tool responses पर Violence scan नहीं होगा जब तक आप उन intervention points पर controls न जोड़ें। यह override pattern जानबूझकर है: agent sessions के लिए agent guardrail ही सच्चाई का स्रोत है।

Guardrails content filter करते हैं; network isolation तय करता है Foundry तक कौन पहुँच सकता है और agent traffic कहाँ जा सकता है। Microsoft Foundry समस्या को तीन हिस्सों में बाँटता है: Foundry resource तक inbound access, Foundry resource से दूसरी Azure services तक outbound access, और Foundry Agent client से dependencies तक outbound access—जैसे private data sources या virtual network injection से approved internet endpoints।

नए resource पर inbound isolation: Azure portal खोलें, Foundry खोजें, Create a resource चुनें, Basics पूरा करें, Networking tab पर public access Disabled करें, + Add private endpoint चुनें, region virtual network से मिलाएँ। मौजूदा resource पर Resource Management, Networking, Private endpoint connections, + Private endpoint। Connection approve करें ताकि status Approved दिखे; pending connections traffic नहीं भेजते।

• Foundry project, storage, Key Vault, container registry, monitoring जैसी platform services isolation के लिए Private Link use करती हैं।
• Agents के लिए Foundry Agent client customer-managed subnet में inject करता है, अलग compute चलाने को नहीं कहता।
• Standard setup में Azure Storage, Azure AI Search, Azure Cosmos DB लाने की उम्मीद है ताकि agent data आपके tenant में रहे; Basic setup deployment में managed resources बना सकता है।
• Outbound virtual network injection चालू करते समय Microsoft.App/environments delegated subnet चुनें, size /27 या बड़ा। Search, Storage, Cosmos DB के private endpoints अपने आप नहीं बनते—हर resource पर अलग जोड़ें।
• Existing deployment पर outbound virtual network injection बाद में नहीं जोड़ सकते; outbound networking या delegated subnet बदलने के लिए Foundry redeploy करें।

Foundry stored data को default पर Microsoft-managed keys से encrypt करता है, FIPS 140-2 compliant 256-bit AES के साथ। Azure Key Vault या Azure Managed HSM में customer-managed keys (CMKs) rotation, revocation, auditing पर आपका नियंत्रण बढ़ाते हैं। CMK enforcement की सीमाएँ हैं: कुछ capabilities के लिए पहले अपना storage लाना पड़ता है, और runtime compute में data थोड़ी देर memory में unwrap हो सकता है जब rest storage CMK-protected हो।

• Prompt agents पर CMK के लिए अपना Azure Cosmos DB, Storage, Azure AI Search लाएँ और CMK हर service पर अलग configure करें।
• Hosted agent sandbox compute ephemeral है, लेकिन हर session का persistent $HOME filesystem platform-managed storage पर है जो आज CMK-encrypted नहीं।
• Active CMK revoke करने पर उस key से encrypted data तक पहुँच बंद; fine-tuning downloads और नए deployments access restore होने तक fail हो सकते हैं।
• Azure AI Search पर CMK सिर्फ़ select regions में; design से पहले regional availability देखें।
• Model-level guardrails agent की रक्षा कर देंगे, जबकि agent को अलग guardrail assign है—यह मान लेना।
• Tool response controls चालू करना जब agent moderation unsupported tools call करता है।
• Public access बंद करना लेकिन private DNS छोड़ना, ताकि VNet के अंदर clients अभी public IP resolve करें।
• Basic agent storage चुनना जब policy agent state पर CMK माँगती है—customer-managed storage चाहिए, hosted agents पर CMK अधिकतम आंशिक।

Guardrails को अवधारणा 14 में बनाए evaluation और red-team baselines के साथ जोड़ें, फिर agent promote करने से पहले virtual network के अंदर की machine से network paths validate करें। अवधारणा 16 scale पर governance cover करती है: control plane fleet monitoring, publishing, resilience, और cost controls जो single-project guardrails और private endpoints के ऊपर बैठते हैं।

• Default guardrails, risk tables, blocking levels, और agent override rules। Guardrails and controls overview in Microsoft Foundry
• Control setup के चरण, supported tools, और latency notes। Intervention points
• Private endpoints, virtual network injection, और tool traffic patterns। Configure network isolation for Microsoft Foundry
• Capability के हिसाब से CMK coverage और compute stack limits। Customer-managed key encryption in Microsoft Foundry