Your platform team wants to catch prompt-injection, tool-abuse, and jailbreak risks in a multi-agent Foundry solution before production release. They already run unit and integration tests in CI. Which shift-left security practice best extends that pipeline for agentic threats?
Select an answer to reveal the explanation.
Short Explanation
You need to shift security left by running adversarial probes of prompts, tools, and multi-agent paths before promotion. Microsoft Foundry’s AI Red Teaming Agent does that automatically in pre-release evaluation, so you catch injection, tool-abuse, and jailbreak risks before customers do.
Full Explanation
Exam AI-500 expects candidates to implement shift-left security principles, including the AI Red Teaming Agent in Foundry. Traditional unit and integration tests validate deterministic code paths; they rarely explore prompt-injection chains, multi-agent collusion, or unsafe tool invocation sequences. Embedding automated red teaming in the evaluation stage of DTAP (or a canary pre-prod environment) surfaces those risks early. Fail the pipeline when severity exceeds policy. The approach that waits until after go-live and relies solely on customer complaint tickets postpones discovery to production. The approach that disables all tool calling in production is not a security strategy—it is feature removal. The approach that runs only static SAST on Python source addresses code vulnerabilities but not model or orchestration misuse. Combine red teaming with guardrail tests, least-privilege tool scopes, and content safety filters so findings drive concrete mitigations (prompt hardening, tool allowlists, output filters) rather than one-off manual reviews.