Microsoft PyRIT Red Team Setup: An Implementation Lab

Microsoft PyRIT gives a red-team engineer configurable targets and attack strategies, with scorers and memory for repeatable generative AI testing. The framework can send single-turn or multi-turn attacks to supported provider targets and other configured interfaces, including custom HTTP endpoints. The first lab should stay small with one authorized target and one risk objective. It should also include one recorded conversation and one exported result, followed by one remediation replay. I would reject a setup that produces a clever prompt without preserving enough state to run it again.

TL;DR

• Install PyRIT through a documented route and pin the environment used for the test.
• Configure one authorized target and one attack strategy, then add a scorer and memory before adding breadth.
• Export the complete conversation and test context, then attach the expected behavior and repair owner.
• Treat PyRIT as a test framework; production enforcement requires a separate control on the live request path.

PyRIT is a configurable test framework

The official Microsoft PyRIT repository describes the Python Risk Identification Tool for generative AI red teaming. It supports orchestrated attacks and evaluation rather than acting as a production gateway.

Start by writing the lab objective in one sentence. For example: verify that an authenticated support-agent route refuses a prompt that requests another customer's case summary. The sentence identifies the expected behavior along with a target and identity context. It also keeps the test tied to a buyer-relevant control instead of producing an abstract jailbreak demonstration.

The AI red-teaming tools comparison covers the category decision across PyRIT and neighboring tools. This implementation lab assumes PyRIT is already selected and focuses on producing one defensible, replayable result.

Choose an installation route and pin it

Microsoft's PyRIT installation guide documents Docker and pip routes, with uv as another route. Pick the route that matches the team's operating environment. Record the PyRIT version and Python environment. Also record the dependency lock or container reference used for the run.

The setup record matters because attack behavior can change across versions, as can scorers and targets. A result that cannot be recreated after a dependency update is weak regression evidence. Keep secrets outside notebooks and committed configuration. Use the target provider's approved credential mechanism and a dedicated test identity with limited permissions.

For a shared lab, I prefer a container or locked project environment over an engineer's long-lived workstation setup. The cleaner boundary reduces "works on my laptop" failures and makes teardown visible after the exercise.

Configure one authorized target first

The PyRIT documentation describes provider targets and custom target options, including HTTP and WebSocket paths. Configure the smallest target that represents the route under review. Record the destination and authentication method. Include the test identity and permitted hours, together with the rate limit and stop condition.

Authorization belongs in the run sheet. A red-team framework can generate traffic quickly, and a custom endpoint may sit in front of a tool-enabled application. Confirm that the test cannot expose live customer data. It also must not send real messages or change production records. Use synthetic fixtures and a non-production identity when possible.

Custom HTTP targeting creates an important opportunity because the lab can aim at the same customer-controlled route used by the application, but PyRIT reaches only the target you configure. It does not discover hidden SaaS calls or non-HTTP traffic such as local commands and STDIO tool traffic by implication.

Attack strategy and scorer define the result

Select an attack strategy that fits the risk objective. A single-turn strategy can test a direct instruction conflict. Multi-turn work can test gradual context manipulation or repeated attempts to cross a policy boundary. The strategy should reflect the threat being evaluated rather than maximize novelty.

The scorer turns the response into an evaluation. Record which scorer was used, why it matches the expected behavior, and its configuration. Automated scoring can accelerate a run, while human review may still be needed for ambiguous or domain-specific output. Preserve the raw response beside the score.

A pass or fail label without the input and output is poor evidence. Open the exported record on screen and verify that the full conversation is visible. The reviewer should be able to point to the exact sentence that crossed the rule and the scorer condition that captured it.

The automated red-teaming guide explains why evaluator quality matters as much as attack generation.

Memory makes multi-turn work reproducible

Configure PyRIT memory deliberately because it stores conversations and related test data. The record should preserve messages in order and target details. It should also preserve strategy details and scorer output, together with timestamps and identifiers needed to correlate the run.

Protect the memory store as security evidence. Red-team prompts and model responses may contain sensitive test material. Define access and retention rules before the exercise. Include deletion rules in that definition. Avoid loading real secrets or customer records into the test corpus.

Memory supports replay after a repair, allowing the team to select the failed case and run it against the corrected target under documented conditions. Keep the original result beside the later one rather than overwriting it. That pair is the acceptance evidence.

Export links the test to the repair ticket

Export the case in a format the security and platform teams can retain. The artifact needs the target and test identity, plus the complete conversation and scorer result. Add the owning control and expected behavior outside the PyRIT record if the framework does not contain those business fields. Include the severity rationale there as well.

The repair owner depends on the failure. A model or prompt owner may change system instructions. IAM may repair an identity or token scope. A data team may fix retrieval permissions. A tool owner may enforce authorization at the downstream API. A gateway owner may add a request policy for routed traffic.

The AI red-team methodology covers that assignment and retest loop. PyRIT supplies test execution and evidence. The production team supplies the control change.

Replay proves the selected repair

Run the original case again after the change. Preserve the same identity and target when those conditions remain valid. Preserve the relevant state as well. Record the repaired version and the later result. If the scorer changes, explain why and retain both evaluations.

A successful replay proves the tested case under the documented conditions. It does not prove that every variant is closed. Add neighboring cases to the regression set based on the failure mechanism. Run that set on the cadence appropriate to application changes and model or prompt changes.

For a routed HTTP policy repair, retain the production control's own evidence as well. The record should show the test identity and route. It should also show the active policy version and decision, together with the timestamp. PyRIT's result shows what the target returned. The policy event shows what the control decided.

Route scoping protects the architecture claim

PyRIT can target HTTP endpoints, but that capability does not turn it into an inline proxy. It sends test traffic to an authorized target. Production applications do not depend on PyRIT for every request, and PyRIT does not provide per-request authorization for live users.

DeepInspect applies only where authenticated user or agent traffic is deliberately routed over HTTP to an LLM. A PyRIT case aimed at that route can test the policy point. Cases involving local model loading or shell execution remain outside the proxy unless their relevant interaction separately crosses the governed request path. The same limit applies to STDIO and credentials, as well as retrieval ACLs and downstream APIs.

Write the route beside every result. That one field prevents a model-response finding from being stretched into a claim about controls the lab never exercised.

DeepInspect

DeepInspect can be the authorized target for a PyRIT case when the lab is testing authenticated HTTP model traffic that the application deliberately routes through the proxy. The replay can evaluate an identity-aware policy and retain the route and policy version, together with the decision and timestamp outside the calling application's write path.

PyRIT remains the test runner while DeepInspect handles the configured route. DeepInspect does not replace attack orchestration, scorers, or memory. It also does not extend gateway coverage to local commands or STDIO. Retrieval permissions and credentials remain outside that coverage, as do downstream services outside the route. Together they can connect a reproducible test to one production enforcement point.

Book a technical deep dive at deepinspect.ai.