AI Red Teaming Research Tracker: Changes to Add to Your Regression Suite

Microsoft published a PyRIT release on September 4, 2026. That release is the current change signal for this first tracker entry. A research update earns a place here only when it changes a production test case, its expected result, or the conditions that trigger another run. I want this page to function like the clipboard beside a test bench: dated, marked up, and useful during the next release review.

TL;DR

• Add the September PyRIT release to a controlled evaluation branch before changing the production regression runner.
• Tag every new test by system layer, attacker capability, expected result, and rerun trigger.
• Use the NIST adversarial machine learning taxonomy to prevent a prompt test from being mistaken for coverage of model artifacts or retrieval stores.
• DeepInspect can record or enforce only adversarial traffic sent through its authenticated HTTP model boundary.

Tracker entry for October 23, 2026

The current entry has two primary records. Microsoft's PyRIT repository describes an open-source framework for proactively identifying risk in generative AI systems. Its inspected September 4 release was published in 2026. NIST's Adversarial Machine Learning taxonomy organizes attacks by model or lifecycle stage, attacker objective, attacker capabilities and knowledge, with corresponding mitigations.

Those records answer different questions. PyRIT supplies a test framework that can exercise a target. NIST supplies the classification language that keeps scope honest. My opinion is blunt: a red-team corpus without a layer label is a pile of prompts, not a regression program. The label is what tells a release owner which control failed and which team has to respond.

This tracker therefore records a change only after it can be translated into four fields: the affected system layer, the test case to add, the expected result, and the event that requires a rerun. That rule keeps this page separate from the evergreen AI red teaming controls guide.

Change signal: the September PyRIT release

The inspected Microsoft release establishes a dated framework update. It does not, by itself, prove that an existing target became less secure or that a new attack succeeds against every model. Treat the release as a reason to examine the framework setup and its dependencies in a branch, then decide which test definitions should move into the organization-owned suite.

The concrete test-suite change is a compatibility run against one approved model route in a non-production environment. Pin the runner to the September release, preserve the previous runner version, and send the same small acceptance corpus through both. On a whiteboard, draw two boxes labeled old runner and new runner, then connect both to the same authenticated staging endpoint. Differences belong in the change record rather than being silently accepted as new baselines.

The expected result is operational: the approved corpus executes through the intended route, produces a result for each case, and preserves enough request context to compare the old and new runs. A tool upgrade should never erase the prior evidence. If the updated runner changes case execution, scoring behavior, or route handling in a way that affects interpretation, hold the upgrade until the security engineer can explain the difference.

Rerun after a target model change, a system-prompt revision, a policy change on the routed endpoint, or another PyRIT release adopted by the team. The AI red teaming tools guide can help with framework selection; this tracker owns the dated decision to modify the regression suite.

Classification change: use NIST layer labels

NIST's taxonomy provides the discipline this ledger needs. It separates attacks by model and lifecycle stage, then records attacker objectives, capabilities, knowledge and mitigations. That structure stops one successful prompt-injection test from being reported as evidence about unrelated surfaces.

Add a layer label to each case before the next run. A test sent as an HTTP request to a deployed model route belongs to the runtime request path. A poisoned model artifact, a modified vector store, or a local model-loading path belongs elsewhere. The physical detail is simple: put the layer in the first column of the working test sheet, before the payload name. If the field is blank, the case stays out of the release gate.

For each runtime case, record the attacker capability needed to deliver the input and the knowledge assumed about the target. Then state the expected result in observable terms. A deny expectation should identify the policy decision. An allowed test should identify the evidence that proves the request reached the intended endpoint. A response-quality score cannot substitute for an enforcement outcome when the test is meant to validate policy.

Rerun the affected layer after its control changes. A new gateway policy calls for the routed HTTP cases, while a retrieval-store permission change calls for retrieval tests owned by that system. This is how a tracker prevents test-suite growth from turning into false assurance.

The regression record to keep

Each accepted change needs a compact record that survives staff rotation. Capture the source URL and publication or release date. Add the target route, environment, test identity and runner version. Then record the layer label, expected result, actual result, owner and rerun trigger. This is a working ledger, so the entry should point to stored evidence rather than copy full prompts into an article or ticket.

I would also keep the prior result beside the new one. A green result with no predecessor hides scoring drift. A screenshot of two result rows, one before the upgrade and one after it, is more useful during a release review than a slide that says red teaming passed. The record should show which byte path was exercised and which decision was observed.

The suite needs an explicit direct-call control. Run one designated case through the governed route and, in an isolated test environment, document the target's direct route separately. The comparison demonstrates which evidence comes from the policy point. It must never become a production bypass recipe. Restrict the direct target to test credentials and retain the route owner in the record.

Scope at the HTTP boundary

Red-team frameworks and corpora generate inputs. They provide no runtime enforcement by themselves. DeepInspect can enforce or record adversarial traffic only when an authenticated user or agent deliberately sends the model request through its HTTP policy point. That coverage includes the prompt and response on the routed call, plus an HTTP tool request when the application deliberately routes that request through the same governed boundary.

Local model loading sits outside that boundary. So do direct vector-store mutations, local tool execution, STDIO calls and any test path that calls the target without crossing the proxy. Research about those surfaces still belongs in the security program, but its owner and evidence source must be named separately. The AI security tools list explains why one product category rarely covers every layer.

A clean route diagram should make this visible. Draw the authenticated test identity on the left, the policy point in the middle and the model endpoint on the right. Put local tools and retrieval stores below the line rather than pretending the same arrow covers them. That picture is the fastest check against inflated coverage language.

DeepInspect

DeepInspect can provide the policy decision and evidence for the slice of this program that crosses authenticated HTTP model traffic. A regression request sent through the gateway can be evaluated against the caller identity, route and active policy, producing a per-decision record that the test owner can compare across runs.

The gateway cannot observe a local model loader, a direct vector-store write, a STDIO tool call or a target called outside the routed path. Keep those cases in the broader program with separate evidence. For the governed route, pin the test identity and policy version so a future run compares the same control boundary.

Book a demo today.