Microsoft put PyRIT-backed AI red teaming into Foundry preview, making scan evidence a separate release artifact
Microsoft announced its AI Red Teaming Agent public preview on April 4, 2025, bringing PyRIT-based adversarial testing to Foundry evaluation, reporting and logging surfaces.
Historical reporting: Microsoft announced a public preview of its AI Red Teaming Agent for Azure AI Foundry on April 4, 2025. The launch said the service integrated Microsoft AI Red Team’s open-source PyRIT toolkit with risk and safety evaluations, automated scans, scoring and reporting. A current Microsoft Learn page is retained as a route reference but was behind an authorization wall during review and supplies no factual claim here. Automation can surface potential failures, but it does not independently authorize deployment or replace expert review.
Key takeaways
- The April event was a public preview, not a general-availability claim for every model, tool or workload.
- Microsoft positioned scanning, scoring and reports as separate artifacts that can inform a release decision; none alone proves a system is safe.
- PyRIT-backed probing can make tests repeatable, but target scope, review of findings and mitigation ownership remain human governance work.
The April announcement established a public-preview testing surface[source 1]
Microsoft announced the public preview of its AI Red Teaming Agent on April 4, 2025 for generative-AI systems in Azure AI Foundry. The post said it integrated the Microsoft AI Red Team’s open-source PyRIT toolkit with Foundry’s existing risk and safety evaluations. That wording establishes a release-stage and product relationship: customers could evaluate a preview service that combined adversarial probing with evaluation infrastructure. It does not establish that every Foundry endpoint, external system, model family, region or tool call was supported on that date. Preview also does not mean a scan outcome is production approval. The historical event is the introduction of a structured test workflow, with stated components and limits, rather than an assurance that a single control plane can settle every safety or security question.
Microsoft separated adversarial scans, scoring and reporting into distinct evidence steps[source 1]
The launch described three linked functions: automated scans that simulate adversarial probing, evaluation of attack-response pairs that can generate an attack-success-rate metric, and scorecards or reports that track findings over time. That separation is operationally useful. A generated probe is not its own judgment; a score depends on evaluation criteria; and a report is only as useful as its traceability to a specific target, configuration and remediation decision. An organization can preserve all three as review evidence, compare changes across releases and ask whether an observed failure was fixed or merely no longer covered by a scenario. But none of those artifacts automatically measures business impact, authorization boundaries, data handling or the validity of a model’s answer in a real deployment.
PyRIT supplied an adversarial-testing lineage without making every technique a deployment rule[source 1]
Microsoft said the preview used PyRIT, its open-source Python Risk Identification Tool, alongside Foundry risk and safety evaluators. The connection is significant because it made a named red-teaming toolkit part of a managed testing path. It should not be read as a claim that one toolkit detects every form of misuse or that a standard scan can model every organization’s threat surface. A team still needs to define target scope, keep synthetic testing separate from customer data, investigate findings and own the decision to release or block a change. A tool can produce a repeatable test run without producing that governance decision.
A scan result was release evidence, not certification or a security guarantee[source 1]
The launch framed automated red teaming as a way to make potential risks visible during development and to track safety improvements. That is narrower and more credible than treating an attack-success-rate number as certification. Scores vary with prompts, risk taxonomies, target configuration, evaluator behavior, sample size and the kinds of attacks a team elects to include. A low score can show that a particular tested configuration resisted a particular set of probes; it cannot show that the system is invulnerable or that its tools have appropriate authority in production. The April preview is therefore best understood as a reporting and testing milestone. Teams still need human sign-off, access controls, incident plans, change records and review of their test corpus before they can make claims about deployment readiness.
Sources
Continue reading
Related reading
News analysisUK’s third-party AI assurance roadmap mapped professionalization, information access and a planned innovation fund3 min read
News analysisThe UK retitled its AI Safety Institute and put security risks at the centre of its remit4 min read
News analysisOECD launched the Hiroshima AI reporting framework, making comparable company disclosures the event—not proof of compliance3 min read