Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-104.1 Design and implement security for multi-agent solutions

Gate agent releases on adversarial evidence

Completed by the knowledge check

Learning objective

Integrate shift-left security testing and the AI Red Teaming Agent in Microsoft Foundry.

Core idea

For an architect releasing a multi-agent solution, shift-left security means finding defects while code, dependencies, permissions, and agent behavior can still change before deployment. Use separate checks for separate failure classes. Source analysis can find vulnerable code or exposed credentials; adversarial agent testing can reveal unsafe outputs or prohibited tool use. Passing one does not establish that the other is safe.

Microsoft documents source-security controls in GitHub Advanced Security for Azure DevOps and behavioral probing through the AI Red Teaming Agent in Microsoft Foundry. Microsoft labels the AI Red Teaming Agent as preview. Connect both to an explicit release decision. See 0.14 for reproducible delivery and 3.3.3 for quality regression measurement; this lesson adds security-specific checks and adversarial evidence.

How it works

Move source-security checks into change review

For Azure Repos Git repositories in Azure DevOps Services, GitHub Advanced Security provides code, dependency, and secret scanning. The standalone products are GitHub Code Security and GitHub Secret Protection for Azure DevOps. Code Security covers code and dependency scanning; Secret Protection covers secret scanning and push protection. Enable the product capabilities for the repositories in scope rather than assuming a scan task alone supplies them.

Secret push protection evaluates pushes after enablement. Repository secret scanning also searches existing history. Their purposes differ: blocking another exposed credential and finding a credential already committed are separate controls. When a real credential is discovered, fixing source text does not invalidate the credential; rotate it through the mechanism in 4.1.7.

Code scanning uses CodeQL. For advanced pipeline setup, AdvancedSecurity-Codeql-Init@1 initializes analysis and AdvancedSecurity-Codeql-Analyze@1 performs it, with the language-appropriate build steps between them. Dependency scanning examines dependency vulnerabilities through the pipeline or documented repository default setup. Choose coverage for the PR branch, not only a scheduled scan of the default branch.

A result needs enforcement to affect release. Azure DevOps documents the status checks AdvancedSecurity/AllHighAndCritical and AdvancedSecurity/NewHighAndCritical. The first blocks on all critical and high vulnerabilities; the second blocks on newly introduced ones. Configure the selected check as a required branch policy and include a Build validation policy with the security scanning pipeline.

The configuration documentation requires build validation for these checks to work correctly. Where the pipeline includes multiple Advanced Security tasks, enable Wait for Processing on the analysis and publish tasks as documented. Otherwise, a completed build and completed vulnerability processing can be different moments. Decide whether existing debt blocks every change or only additional high-impact findings; do not leave that decision to an optional status indicator.

Define the behavioral threat before scanning

Integrate red teaming throughout the lifecycle: compare candidate models during design, test model upgrades and fine-tuned variants during development, and evaluate the assembled application before deployment. Turn confirmed findings into mitigation and regression cases while changes are still inexpensive. After deployment, schedule continuous runs on synthetic adversarial data; see 3.3.3 for continuous quality evaluation. These stages complement source-security checks rather than waiting for a final release gate.

The AI Red Teaming Agent combines Microsoft’s PyRIT attack capabilities with Foundry risk and safety evaluations. It generates adversarial probes, evaluates attack-response pairs, and produces a scorecard. Attack Success Rate (ASR) is successful attacks divided by total attacks, expressed as a percentage. It describes success under the tested attacks, not the frequency of failures in ordinary production traffic.

The documentation supports text-based scenarios. Agent-specific risk categories include prohibited actions, sensitive data leakage, and task adherence, and are available through cloud red teaming. Prohibited-action testing uses a user-reviewed policy and taxonomy to determine which behavior is a violation. A vague tool description or an unreviewed taxonomy weakens the test’s definition of success.

The support matrix includes Foundry hosted prompt agents, hosted container agents, and Azure tool calls. It excludes workflow agents, non-Foundry agents, non-Azure tools, function tools, browser automation, connected-agent tools, and Computer Use tools. Test unsupported integrations through your own controlled security cases; do not treat their absence from a red-team run as evidence that they passed.

Cloud red teaming is documented in East US 2, France Central, Sweden Central, Switzerland West, and US North Central. Check that the test environment matches the supported target and regional constraints before making the scan a deployment prerequisite. A pipeline gate that cannot execute is missing evidence, not a clean result.

Run and retain the Foundry evaluation evidence

The cloud guide uses AIProjectClient.get_openai_client() and client.evals.create(), with data_source_config containing type: "azure_ai_source" and scenario: "red_team". Its agentic criteria include builtin.prohibited_actions, builtin.task_adherence, and builtin.sensitive_data_leakage. These evaluator identifiers make the selected risks explicit rather than relying on a generic safety label.

For prohibited actions, the guide uses project_client.beta.evaluation_taxonomies.create() with RiskCategory.PROHIBITED_ACTIONS and an AzureAIAgentTarget identifying the agent name and version. Review and confirm the generated taxonomy before using it as the attack source. The documented REST examples use api-version=2025-11-15-preview, and taxonomy creation uses a beta SDK interface. Plan version-specific validation for these preview and beta interfaces.

client.evals.runs.create() starts a run with data_source.type: "azure_ai_red_team". The source specifies type: "red_team_taxonomy", attack_strategies, num_turns, and a taxonomy source ID. The guide includes strategy identifiers such as Flip, Base64, and IndirectJailbreak. Record the exact target version, taxonomy, strategies, and run ID so a subsequent result is comparable.

Retrieve completion with client.evals.runs.retrieve() and output items with client.evals.runs.output_items.list(). Inspect the findings before deciding whether to block or mitigate. The documentation notes that generative evaluation is nondeterministic and can yield false positives. A release gate should distinguish a completed run with reviewed findings from a failed or incomplete run.

Preserve realistic conditions without production effects

Microsoft recommends a purple environment: nonproduction resources configured to resemble production. For agentic runs, the documented environment is minimally sandboxed, not completely locked down. Synthetic tool data and transient runs reduce exposure, but they are not a guarantee that every behavior is faithfully mocked or that arbitrary integrations are safely isolated.

Use test identities, synthetic sensitive records, and controlled tool targets. Verify permission denials and approval enforcement separately from generated-text scoring. The red-team concept page limits prohibited-action testing to single-turn, English-only, tool-level scenarios without live production data; do not extend that specific test’s claims to every multi-turn run or language.

Key distinctions and trade-offs

Code vulnerability versus generated-code vulnerability: CodeQL analyzes repository code. The red-teaming code-vulnerability category tests code produced by the AI system. They examine different artifacts.

Automated detection versus release policy: Foundry returns evaluation evidence; your release process decides acceptable outcomes, review ownership, and exceptions. An ASR threshold is an organizational gate, not a documented universal safe value.

Adversarial population versus production population: A red-team score measures selected attacks. Pair it with normal-task regression evidence rather than using it as a production failure-rate estimate.

Architecture / decision scenario

A team changes a tool adapter and the instructions of a Foundry prompt agent. The application also contains a workflow calling a custom function, which the documented agentic red-team matrix does not cover.

Require source scanning on the PR branch, secret push protection, and AdvancedSecurity/NewHighAndCritical with build validation. In a supported cloud region, run the candidate prompt-agent version against a reviewed prohibited-actions taxonomy plus leakage and task-adherence criteria. Include indirect injection attacks against supported tool-returned context, and retain run identifiers and reviewed output items.

Test the workflow and function path separately with synthetic records and explicit denied-action cases. Block promotion if the required scan cannot finish, if a confirmed prohibited action occurs, or if the required source check fails. After mitigation, repeat the affected security cases and normal-task regression checks before promotion. A clean CodeQL result does not waive a confirmed unsafe tool action, and a low ASR does not waive an exposed credential.

Common exam traps

  • Treating source scanning and behavioral red teaming as interchangeable.
  • Posting security results without a required branch policy.
  • Assuming cloud agentic testing covers every tool and workflow.
  • Treating a generated taxonomy as approved policy without review.
  • Reading ASR as a production incident probability or a guarantee of safety.
  • Assuming minimally sandboxed testing permits live production data and targets.

What to remember

Gate source changes with the appropriate scanning capabilities and enforced status checks. Red team a versioned, supported Foundry target against reviewed risks in a controlled environment. Keep unsupported paths, incomplete runs, and uncertain findings visible in the release decision.

Knowledge check

References