Study guide for the Microsoft Certified: Multi-Agent AI Solutions Expert exam
Microsoft · October 2026 exam blueprint · 166 curriculum items
0.1 Choose models by their required capabilities
About this guide
Each bite isolates one concept or one architecture decision. Read them in order to prepare for the exam, or come back to a single bite later as a reference — the shape is the same either way, so you always know where in a lesson an answer will be.
Lessons are made to fit into the gaps between real engineering work, including the time while your coding agent is running. There is no reading-time promise attached to that, only a deliberate scope: one decision per bite.
A Lab completes when you open its official exercise — and, if it ends with a knowledge check, once you have answered that too. Anything else that carries a knowledge check — a bite, a checkpoint, a mock exam — completes when you answer every question of it; a bite without one completes when you say so. Completion only accumulates — nothing here takes it back.
Prerequisites
- 0.1 Choose models by their required capabilitiesSelect chat, reasoning, small, multimodal, and embedding models by the interface and quality your workload requires.
- 0.2 Budget tokens before tuning model behaviorRelate request token budgets and supported inference controls to response completeness, latency, throughput, and cost.
- 0.3 Separate instructions from evidence and contractsDesign role-bearing prompts, bounded context, schema-constrained outputs, and explicit handling of untrusted content.
- 0.4 Trace tool calls through a bounded loopFollow model decisions, authorized tool execution, observations, termination, and failures without confusing proposals with completed actions.
- 0.5 Choose the least complex execution modelDistinguish fixed automation, single-agent tool loops, and coordinated specialist workflows by who controls execution.
- 0.6 Separate agent authority from user delegationIdentify the principal, permission model, and trust checks that authorize each agent action.
- 0.7 Give each kind of state an ownerSeparate workflow progress, agent sessions, conversation history, and long-term memory by purpose and lifetime.
- 0.8 Turn similar passages into usable evidenceExplain how embeddings and retrieval supply candidate evidence without confusing similarity with factual support.
- 0.9 Choose the contract for each interactionDistinguish remote-agent collaboration through A2A from tool interoperability through MCP and apply Foundry's support constraints.
- 0.10 Bound concurrent calls and validate resultsApply Python concurrency, deadlines, schema validation, and exception handling without mistaking transport success for a valid result.
- 0.11 Match Azure resources to workload needsDistinguish Azure compute, network, storage, and data services by the responsibility and access pattern each one supports.
- 0.12 Separate credentials from Azure access grantsSelect an Azure credential source and scoped role assignment without confusing authentication with permission to access data.
- 0.13 Locate the right Foundry object firstNavigate Foundry projects, model deployments, agent definitions, versions, and conversations before choosing a Responses API integration.
- 0.14 Make agent delivery reproducible and reviewableConnect Git review, layered tests, environment configuration, container artifacts, and declarative infrastructure into a reproducible delivery path.
- 0.15 Correlate logs, metrics, and OpenTelemetry tracesInterpret logs, metrics, traces, and spans through Azure Monitor and OpenTelemetry without confusing aggregate symptoms with request-level evidence.
Architect multi-agent solutions
Design logical architecture for multi-agent solutions
- 1.1.1 Split business goals into bounded workSeparate workflows, agents, subagents, and tools by their outcomes, ownership, and execution boundaries.
- 1.1.2 Keep business rules outside model discretionChoose deterministic workflow control and bounded autonomous reasoning for different kinds of decisions.
- 1.1.3 Delegate subtasks without losing outcome ownershipDesign orchestrator and subagent boundaries with explicit inputs, return contracts, and retained responsibility.
- 1.1.4 Constrain agent behavior beyond its personaDefine agent identity, duties, operating scope, behavioral obligations, and permitted autonomy separately.
- 1.1.5 Bound planning loops with explicit outcomesDesign planning and reflection loops with measurable completion, escalation, and enforced termination boundaries.
- 1.1.6 Place approval before consequential actionsChoose human checkpoints from impact, uncertainty, and reversibility, then implement a scoped approval boundary.
- 1.1.7 Authorize tools for the acting principalSpecify exposed tools, delegated access, and downstream token audiences without confusing model scope with enforced permissions.
- 1.1.8 Choose protocols by the work exchangedSelect A2A, MCP, direct APIs, and durable events by responsibility, interaction shape, and delivery requirements.
- 1.1.9 Make agent decisions inspectable and contestableDesign transparency, feedback, override, and accountability controls that connect the human experience to enforced execution decisions.
- 1.1.10 Share context through explicit memory ownershipSeparate session context, workflow state, and long-term memory while assigning cross-agent read, write, retention, and correction responsibilities.
- 1.1.11 Assign models from measured workload requirementsMatch model and deployment capabilities to quality, latency, context, tool use, and cost constraints for each agent role.
- LABApply task decomposition and agent collaboration strategies in Microsoft FoundryComplete a meta-agent planner whose JSON task DAG application code validates, schedules across specialist agents, and bounds to at most one replan signal.
- LABExplore and compare modelsCompare two models in the Foundry catalog, leaderboard and playground, then evaluate one against a synthetically generated dataset.
- LABGovern a Foundry multi-agent code reviewRun a three-agent governance workflow with minimized handoffs, a deterministic human-review gate, and accountability evidence in Application Insights.
Specify technology components to include in a multi-agent solution
- 1.2.1 Choose where agent control belongsSelect prompt agents, hosted agents, or code-based workflows by separating runtime hosting from orchestration ownership.
- 1.2.2 Assign each integration a clear boundarySpecify separate components for agent discovery, durable messaging, tool selection, gateway governance, and knowledge retrieval.
- 1.2.3 Rebind permissions when agent identity changesIdentify the active Foundry agent identity, reassign downstream permissions at the correct lifecycle boundary, and limit lateral access.
- 1.2.4 Turn compliance requirements into enforced boundariesMap Zero Trust, tenant isolation, processing location, and data minimization to concrete identity, retrieval, storage, and network controls.
- 1.2.5 Separate session state from shared memorySelect durable components for conversations, agent checkpoints, shared team records, and scoped semantic memory.
- 1.2.6 Match agent hosting to operating demandsCompare managed agent hosting and Azure compute by scaling behavior, recovery, operational ownership, isolation, and total cost.
- 1.2.7 Preserve execution evidence without private reasoningDesign correlated traces, minimized decision records, and versioned replay fixtures that explain agent execution without collecting private model reasoning.
- 1.2.8 Detect coordination faults before remediating themCombine workflow delivery signals, quality evaluations, Azure Monitor alerts, and bounded recovery actions to detect failures, drift, and regressions.
- 1.2.9 Rebuild the agent development environment reliablySpecify a versioned development environment with dev containers, editor extensions, command-line tools, dependency controls, and discoverable AI instructions.
- LABDesign stateful agentic loops with Microsoft Foundry Agent ServiceMigrate an Agents v1 loop to Agents v2, bound its reflection, keep state in a conversation, and branch with previous_response_id.
- LABBuild AI agents with portal and VS CodeBuild a grounded agent with file search and code interpreter in the Foundry portal, then use it from the Foundry Toolkit and a Python client.
- LABExercise - Add a dev container to an existing projectAdd a Python dev container configuration to a project, reopen the project inside it, and run the app from the container.
Develop multi-agent solutions in Azure
Design and implement advanced prompt engineering strategies in multi-agent solutions
- 2.1.1 Give each role an explicit result contractDesign specialist prompts with representative examples, operational constraints, and output schemas that downstream agents can validate.
- 2.1.2 Render context without rewriting trusted instructionsBuild runtime prompts from typed inputs, explicit delimiters, and request-scoped evidence while preserving the template's ownership.
- 2.1.3 Reject overrides without abandoning the authorized taskWrite defensive agent instructions and connect prompt-attack detection to explicit enforcement without trusting retrieved or delegated content.
- 2.1.4 Promote prompt versions from comparative evidenceCompare versioned prompts on controlled datasets, enforce regression gates, and separate candidate creation from production activation.
- 2.1.5 Carry context without merging agent responsibilitiesSelect role-specific context, synchronize handoffs, and expose validated workflow state without confusing history with authority.
- 2.1.6 Match each quality gap to its fixDistinguish prompt, grounding, model, and training changes and select a supported SFT, DPO, or RFT method from its learning signal.
- 2.1.7 Gate training data and retraining decisionsGovern dataset acceptance, held-out evaluation, checkpoint selection, and retraining triggers for a fine-tuned agent role.
- LABDesign advanced prompting strategies for production AI agentsCompare two versioned agent prompts behind four deterministic guardrails and decide on prompt promotion and fine-tuning readiness from evidence.
- LABFine-tune a language modelRun a supervised fine-tuning job in Foundry and compare the fine-tuned model's tone and consistency with a prompted base model.
Design and implement agent memory, context management, and knowledge integration
- 2.2.1 Choose one owner for conversation continuityManage persisted conversations, response chains, and local sessions without duplicating history or assuming every stored item reaches the model.
- 2.2.2 Transfer bounded evidence with explicit ownershipDefine and validate handoff payloads that preserve sources, unresolved commitments, and entity identities while limiting transferred context.
- 2.2.3 Budget evidence before injecting retrieved contextSelect authorized, relevant evidence and preserve its provenance while enforcing a token budget on the context actually injected.
- 2.2.4 Compact history without erasing business meaningSelect scoped compaction mechanisms and verify that reduced context preserves commitments, critical facts, and stable entity references.
- 2.2.5 Match memory persistence to its purposeSelect working, episodic, semantic, and shared-memory strategies by lifetime, source fidelity, access pattern, and update ownership.
- 2.2.6 Enforce scoped memory access and lifecycleEnforce trusted memory scopes, tenant-aware isolation, retention and deletion controls, and explicit consistency checks.
- 2.2.7 Consolidate memory with explicit lifecycle controlsImplement memory consolidation, expiration, inspection, and deletion while preserving evidence of lifecycle operations.
- 2.2.8 Choose chunks by the evidence neededSelect fixed, structural, semantic, and parent-child chunking by retrieval precision, context completeness, and indexing behavior.
- 2.2.9 Evaluate embeddings as a retrieval contractCompare embedding models and dimensions while preserving compatible vectors, useful metadata, and measurable retrieval quality.
- 2.2.10 Tune retrieval before reranking candidate evidenceChoose keyword, vector, hybrid, and semantic ranking stages while distinguishing candidate recall from final evidence precision.
- 2.2.11 Assign retrieval ownership across authorized sourcesDesign specialist retrieval responsibilities, enforce source permissions, and route cross-source questions without losing provenance or failure evidence.
- 2.2.12 Connect Search, Foundry IQ, and MCP knowledgeChoose direct Search, Foundry IQ knowledge bases, semantic ranking, and MCP source integrations with explicit identity and evidence contracts.
- LABBuild persistent shared memory for Foundry agentsBuild a patient-scoped vector memory in Azure Cosmos DB with retention, audit and consistency controls, and ground a Foundry Hosted Agent in it.
- LABImplement advanced RAG with Azure AI SearchBuild routed vector, hybrid and semantic retrieval over two chunking strategies in Azure AI Search, and compare them by MRR and latency.
- LABIntegrate an AI agent with Foundry IQGround a Foundry agent in a Foundry IQ knowledge base, then call it from a Python client that approves each knowledge lookup.
Build and integrate tool ecosystems
- 2.3.1 Constrain arguments before executing a toolDefine typed tool inputs, validate proposed calls, and choose the execution owner for custom and built-in tools.
- 2.3.2 Route capabilities through a tested tool versionCompare fixed tool assignments with runtime discovery while preserving authorization and tested contract versions.
- 2.3.3 Choose stdio or Streamable HTTP for MCP serversDesign discoverable MCP tool interfaces and choose process-local stdio or remote Streamable HTTP delivery.
- 2.3.4 Negotiate capabilities before approving tool callsDiscover MCP tools, establish authenticated protocol capabilities, and approve specific calls before execution.
- 2.3.5 Publish function handlers as discoverable MCP toolsExpose Azure Functions through typed MCP tool triggers and configure the extension endpoint and access controls.
- 2.3.6 Turn Logic Apps workflows into MCP toolsChoose qualifying Logic Apps workflows, define their tool inputs, and separate MCP access from connector execution.
- 2.3.7 Govern MCP access through API ManagementChoose an API Management exposure path and apply separate client access, backend credentials, traffic, and monitoring controls.
- 2.3.8 Bound tool recovery before choosing fallbackCoordinate retry limits, backoff, deadlines, circuit breakers, and fallback without multiplying attempts or repeating unsafe effects.
- 2.3.9 Check compatibility before authorizing tool executionValidate arguments, deployed tool versions, and replay semantics while keeping authorization and side-effect approval independent.
- 2.3.10 Validate tool evidence before downstream useCheck result structure, provenance, and functional fitness before consumption, with a separate security screen for untrusted content.
- LABUse a custom function in an AI agentGive a Foundry agent strict JSON-schema function tools, and run the calls it proposes in your own client code.
- LABBuild an enterprise MCP tool ecosystemBuild a FastMCP server and a client that discovers, selects, invokes and validates versioned tools, then deploy the server behind Entra authentication.
- LABExercise - Create an MCP server with Azure FunctionsExpose two Python Azure Functions as MCP tools with the MCP tool trigger, and call them locally from GitHub Copilot in agent mode.
- LAB01 - Build MCP Server in Azure Logic AppsCreate an MCP server from a Logic Apps Standard app through Azure API Center, with a Microsoft Teams connector action as its tool.
- LABModel Context Protocol (MCP) from REST API labExpose REST APIs as MCP servers through Azure API Management, and test their rate-limit and token-validation policies from several agent clients.
Implement multi-agent orchestration
- 2.4.1 Release each stage after its prerequisitesImplement ordered agent pipelines and explicit dependency gates that prevent downstream work from consuming incomplete results.
- 2.4.2 Aggregate parallel results under explicit policyImplement concurrent branches with validated aggregation, quorum rules, and explicit outcomes for partial failure.
- 2.4.3 Route specialist work through a controlled hubImplement supervisor-to-specialist routing while enforcing separate control, context, and tool-access rules.
- 2.4.4 Terminate handoffs and group chats deliberatelyImplement allowed peer handoffs and managed group discussions with measurable completion and enforced stopping conditions.
- 2.4.5 Delegate bounded tasks and replan deliberatelyImplement specialist delegation with explicit task contracts, enforced spawning budgets, and controlled replanning.
- 2.4.6 Resume approved work from durable stateImplement persisted approval gates, bounded waits, authorized overrides, and checkpoint-based resumption without approving changed work.
- 2.4.7 Measure reuse of stable prompt prefixesStructure repeatable Azure OpenAI prompt prefixes and measure cache reads, writes, latency, and net provider savings.
- 2.4.8 Reuse answers within verified freshness scopesChoose exact or semantic response caching with explicit expiration, version-based invalidation, and tenant-scoped lookup.
- 2.4.9 Admit agent work within shared limitsControl spawned work, batch admission, concurrent calls, execution quotas, and cancellation across shared model deployments.
- 2.4.10 Authenticate remote agents before delegating workIntegrate independently deployed agents through versioned A2A or MCP connections with scoped identities, tool exposure, and approval controls.
- 2.4.11 Connect agents through typed executor graphsBuild Agent Framework workflows that separate agent reasoning, executor processing, message routing, and terminal output.
- 2.4.12 Resume LangGraph work through explicit stateDefine state updates, conditional routes, durable checkpoints, and interrupts that resume without repeating unsafe side effects.
- 2.4.13 Choose where composition becomes workflow orchestrationCompose LangChain agents and runnable chains while assigning stateful orchestration to LangGraph or Agent Framework deliberately.
- 2.4.14 Place Transformers pipelines where latency fitsIntegrate Transformers pipelines into agent workflows and choose execution hardware, batching, and hosting from measured latency requirements.
- 2.4.15 Enforce shared policy at middleware layersPlace reusable logging, authorization, validation, and exception handling at the agent, model, or function invocation layer that owns the operation.
- LABImplement advanced multi-agent orchestration patterns in Microsoft FoundryComplete a hub-and-spoke orchestrator that fans out to versioned Foundry specialists, applies a quorum, and synthesizes only accepted evidence.
- LABDevelop a multi-agent solution with Microsoft Agent FrameworkChain three Foundry-backed agents into a sequential Agent Framework orchestration that summarizes, classifies and acts on customer feedback.
- LABDesign enterprise-scale agent communication with A2A in AzureServe an A2A agent card and JSON-RPC endpoint, and route tenant-scoped requests through a Cosmos DB registry with ETag-protected shared state.
- LABImplement durable human approval workflowsBuild a resumable approval state machine on Cosmos DB and Service Bus that escalates by calibrated risk, resumes exactly once, and audits every decision.
- LABLAB 4 — Order Fulfillment Orchestration: Multi-Agent Workflow + HITL + CheckpointBuild a typed Agent Framework workflow that fans out, pauses for human approval, and resumes from a file checkpoint in a fresh process.
- LABOptimize multi-agent performance and cost with measured evidenceAdd model routing, context budgets, versioned caching, and quality-floor escalation, and compare them with a premium baseline using measured tokens and latency.
- LABModule 02 - Specialized Sub-Agent ToolsGive a LangGraph supervisor two sub-agents exposed as typed tools, one a one-shot selector and one a ReAct agent with its own MCP tools.
- LABMulti-stage Reasoning with LangChain using Azure Databricks and Azure OpenAIBuild a retrieval chain over a FAISS index in an Azure Databricks notebook, then pipe its answer into a second LangChain chain.
- LABExplore Large Language Models with Azure DatabricksRun Hugging Face Transformers pipelines for summarization, sentiment, translation and zero-shot classification in an Azure Databricks notebook.
Evaluate, optimize, and monitor multi-agent solutions
Design and implement evaluation and validation strategies for multi-agent solutions
- 3.1.1 Turn human reviews into actionable evidenceDesign scoped reviewer access, response samples, evaluation templates, and escalation decisions that make human feedback usable.
- 3.1.2 Configure cloud evaluation runs and their judgesConfigure reusable datasets, target definitions, evaluator mappings, and thresholds while distinguishing cloud runs from SDK-local judges.
- 3.1.3 Gate response changes with independent checksCompare prompt candidates against regression baselines using instruction-adherence, schema-validity, and response-consistency evidence.
- 3.1.4 Validate tool trajectories beyond final answersEvaluate tool choice, arguments, execution outcomes, result use, and fallback paths against explicit interaction evidence.
- 3.1.5 Test memory across identities and sessionsEvaluate stored facts, retrieved memories, entity associations, and corrected behavior across separate conversations.
- 3.1.6 Separate retrieval scores from answer qualityChoose retrieval and answer evaluators, interpret ranking metrics, and isolate failures between evidence selection and generation.
- 3.1.7 Locate failures along the execution pathCorrelate agent, tool, and handoff evidence to distinguish local defects from end-to-end workflow failures.
- LABDesign and optimize promptsCompare a production prompt with a token-optimized variant on Git experiment branches by scoring a Foundry agent's batch responses by hand.
- LABBuild a multi-agent evaluation quality gateRun model judges over synthetic multi-agent journeys with the Azure AI Evaluation SDK, calibrate them against human labels, and turn the scores into a deterministic release gate.
- LABAutomated evaluation with cloud evaluatorsRun Microsoft Foundry cloud evaluators over an uploaded dataset and trigger the same evaluation from GitHub Actions on pull requests.
Optimize prompt and model performance for multi-agent solutions
- 3.2.1 Shorten the critical path of agent workflowsIdentify independent work, preserve dependency gates, and measure whether bounded parallel execution reduces end-to-end latency.
- 3.2.2 Control model traffic before retrying throttlesDistinguish token and request admission limits, interpret 429 evidence, and configure bounded retries within shared deployment capacity.
- 3.2.3 Trace forgotten facts to context removalProve when a sliding window removes required facts and distinguish that loss from session, retrieval, and model-use failures.
- 3.2.4 Compare compacted summaries with authoritative factsDetect accumulated meaning changes across repeated summarization and distinguish summary defects from downstream answer failures.
- 3.2.5 Choose recall by the evidence requiredDiagnose vector-only retrieval misses and select hybrid search or exact structured recall according to the question's evidence contract.
- 3.2.6 Keep entity identities stable across agents and memoryPreserve stable entity references across conversation turns, specialist handoffs, and retrieved memories without merging unrelated records.
- 3.2.7 Calibrate judges before trusting their scoresDefine explicit evaluation rubrics, calibrate judge decisions against human labels, and check for scoring biases before gating agent changes.
- 3.2.8 Generate synthetic regression and adversarial casesBuild reusable synthetic regression, edge-case, and adversarial datasets with explicit expected outcomes and documented generator constraints.
- 3.2.9 Turn feedback into measurable quality updatesConvert user feedback and semantic failures into versioned evaluation changes, controlled optimization experiments, and verified release decisions.
Design and implement observability and monitoring for multi-agent solutions
- 3.3.1 Measure agent health against workflow outcomesDistinguish per-agent execution health, workflow failure rates, and coordination outcomes with scoped telemetry and explicit denominators.
- 3.3.2 Connect decisions to their execution tracesCorrelate agent, workflow, and service telemetry with trace context and minimized structured decision records.
- 3.3.3 Detect quality changes in production trafficCombine sampled response evaluation and scheduled benchmarks to distinguish behavioral drift from quality regression.
- 3.3.4 Turn recurring failures into bounded recoveryConfigure Azure Monitor failure alerts, escalation actions, and guarded remediation from stable recurring signatures.
- 3.3.5 Measure reliability against explicit service objectivesChoose availability, latency, throughput, and reliability measurements that support defensible SLA and SLO reporting.
- 3.3.6 Enforce budgets before admitting more workEnforce context, model-call, tool-call, and execution limits while monitoring consumption separately from loop design.
- 3.3.7 Allocate agent spending to its consumersSeparate capacity quotas, token metering, billed cost, and tenant chargebacks with explicit attribution and reconciliation.
- 3.3.8 Export agent traces to Foundry and Application InsightsConfigure Foundry-connected tracing, token telemetry, content capture, and correlation while distinguishing cloud and local trace views.
- 3.3.9 Prove incident causes before applying repairsReconstruct causal traces, replay isolated evidence safely, and validate remediation against the observed failure.
- LABMonitor and trace your generative AI agentSend traces for three prompt versions to Application Insights and compare their token usage and latency in Azure Monitor and a span tree.
- LABTrace multi-agent workflows with OpenTelemetryPropagate W3C trace context across a synthetic three-agent flow, export spans and logs to Application Insights, and fire an Azure Monitor alert from emitted anomaly decisions.
- LABDebug a multi-agent production incident with trace evidenceReconstruct a synthetic multi-agent incident from Application Insights, replay a sanitized snapshot without side effects, and test competing hypotheses before writing a postmortem.
- LABGovern a multi-agent topology lifecyclePromote versioned Foundry prompt agents as one release, meter tenant usage against quotas in Cosmos DB, and retire one agent version through explicit gates.
Secure, govern, and deploy multi-agent solutions
Design and implement security for multi-agent solutions
- 4.1.1 Assign each principal only required permissionsSeparate agent and managed identities and assign narrowly scoped management-plane and data-plane permissions.
- 4.1.2 Close each agent network access pathCombine private endpoints, delegated-subnet integration, public-access restrictions, and resource policies into a verifiable network design.
- 4.1.3 Authorize every edge between agent servicesRestrict lateral agent calls with audience-scoped tokens, target-specific permissions, and tenant-aware authorization.
- 4.1.4 Choose whose authority each call carriesDistinguish application-only access, user identity passthrough, and OAuth on-behalf-of exchange while enforcing audience and consent.
- 4.1.5 Configure OAuth and API keys for toolsConfigure OAuth tool connections and govern API keys without confusing shared credentials with delegated user access.
- 4.1.6 Retrieve Key Vault secrets and certificates safelyChoose Key Vault retrieval APIs and data-plane roles for secrets and certificates while separating runtime access from administration.
- 4.1.7 Rotate credentials without stranding encrypted dataDesign secret-version adoption and encryption-key rotation while accounting for Foundry customer-managed key coverage and revocation effects.
- 4.1.8 Gate agent releases on adversarial evidenceCombine source-security checks and Foundry red teaming with scoped release gates and explicit limits on what each test proves.
- LABApply zero trust to a Microsoft Foundry multi-agent workflowEnforce an agent-call allowlist, tenant context, and data minimization on three Foundry agents, and verify keyless, container-scoped access to Cosmos DB.
- LABExercise - Manage secrets with Azure Key VaultRetrieve, list, version, and cache secrets from Azure Key Vault in a Python app with Microsoft Entra authentication.
Design and implement guardrails for multi-agent solutions
- 4.2.1 Place guardrail controls where risks enterConfigure Foundry risk categories, severity thresholds, actions, and intervention points while checking agent overrides and tool moderation support.
- 4.2.2 Match Prompt Shields to attack entry pointsApply direct and indirect Prompt Shields through Foundry controls or the Content Safety API while preserving document identity and explicit enforcement.
- 4.2.3 Authorize tool calls before approving side effectsEnforce principal-specific tool permissions and application policy, then require approval for the exact sensitive or irreversible operation.
- 4.2.4 Screen tool evidence before admitting contextScreen untrusted tool results for injection, sensitive data, and policy violations, then enforce a deny or transform decision before downstream consumption.
- 4.2.5 Gate outputs before releasing business resultsCombine content-safety, grounding, schema, and business-policy checks into an explicit output acceptance decision.
- 4.2.6 Turn domain rules into enforced verdictsImplement domain-specific guardrail decisions with explicit escalation thresholds, approval resolution, and exception outcomes.
- 4.2.7 Choose failure behavior before controls failChoose fail-closed, bounded fail-open, or degraded behavior from risk, reversibility, latency, and downstream consequences.
- 4.2.8 Prove guardrails with repeatable adversarial testsCombine synthetic attacks, labeled policy cases, fault injection, and versioned regression runs to validate guardrail enforcement.
- LABApply guardrails to prevent the output of harmful contentTest a model deployment's default guardrail in the Foundry playground, then create and apply a custom guardrail with stricter content filters.
- LABExercise - Prompt shieldsTest Prompt Shields against a direct user prompt attack, an indirect attack hidden in a document, and both together.
Deploy multi-agent solutions to Azure
- 4.3.1 Match release methods to operational riskChoose DTAP, blue/green, and canary methods by the validation, exposure, and recovery controls your agent workflow needs.
- 4.3.2 Isolate each environment and release setSeparate environment resources, configuration, and credentials while recording compatible immutable agent and dependency versions.
- 4.3.3 Gate promotion at controlled traffic ingressImplement staged release promotion with Container Apps traffic weights, measured quality evidence, and resource-owned approval checks.
- 4.3.4 Restore the recorded compatible release setRecover from an agent release failure using immutable evidence for the agent, model, prompt, tool, and orchestration combination.
- 4.3.5 Govern promotion through dependency retirementManage agent-version promotion, compatibility evidence, deprecation decisions, and retirement without losing valid recovery targets.
- 4.3.6 Layer unit, integration, and regression agent testsDesign unit, integration, and regression coverage that separates deterministic defects from agent behavior changes.
- 4.3.7 Require evaluation evidence before releasing agentsTurn completed agent evaluations into release decisions linked to the candidate, dataset, criteria, and scored cases.
- 4.3.8 Separate pipeline identity from release approvalConfigure federated deployment identity, resource-owned approvals, and validation that binds each release to its evidence.
- 4.3.9 Recreate environments from validated infrastructure definitionsChoose Bicep, Terraform, and Azure Developer CLI roles while validating planned changes and deployed agent dependencies.
- LABImplement CI/CD for Foundry hosted agentsDeploy three Foundry hosted agents through GitHub Actions, canary a version-bound Container Apps dashboard, promote across environments, and roll back to a verified release set.