Microsoft Open-Sources RAMPART and Clarity for Agent Security Testing

Microsoft released two open-source tools in May 2026 aimed at a problem that has been widening faster than the industry has been addressing it: AI agents are being deployed to production before anyone has run structured security tests against them.

The tools are RAMPART and Clarity. They target different phases of the development lifecycle but share the same premise — agent security work needs to happen inside the development workflow, not as a separate review that happens once before launch and then gets skipped on every subsequent update.

The Gap They Are Filling

The problem is structural. Most security evaluation for AI agents today consists of ad hoc red-teaming: a team of people running manual attacks before a major release. That works, once, imperfectly. It does not scale to the pace at which agentic applications are now being updated — model swaps, new tool integrations, expanded permission scopes, and retrieval corpus changes all represent potential regressions in safety behavior, and none of them reliably trigger a new red team engagement.

The result is a fleet of agents where the security posture at month six is unknown relative to the initial review. RAMPART is Microsoft’s answer to that problem.

RAMPART: Red-Teaming as a CI Gate

RAMPART stands for Risk Assessment and Measurement Platform for Agentic Red Teaming. It is a Pytest-native framework, meaning developers write agent security tests using the same tooling they use for unit and integration tests. Those tests then run automatically in CI on every code change.

The framework is built on top of PyRIT, Microsoft’s existing open-source red-teaming library, and extends it with agent-specific attack primitives. Where PyRIT provides the scaffolding for generating adversarial prompts and evaluating model responses, RAMPART adds the ability to describe full adversarial scenarios across an agent’s tool call graph.

A test in RAMPART looks like a normal pytest function. It defines an agent configuration, specifies an adversarial scenario (for example: a malicious calendar invite containing a prompt injection payload), and asserts on the outcome. Did the agent call the network when it should not have? Did it include user data in a tool argument that goes to an external API? Did it take an action outside the scope of what the user requested?

The framework covers four primary attack classes. Cross-prompt injection tests whether injected content from documents, emails, or retrieved chunks can override the agent’s task instruction. Unsafe tool execution tests whether the agent can be triggered to invoke a tool that the current task does not require. Data exfiltration tests whether agent responses or tool call arguments contain content from the context window that should not leave the session. Behavioral regression tests verify that safety behaviors present in a prior version of the agent are still intact after a model update or configuration change.

Microsoft released RAMPART alongside a library of starter test cases covering the most common attack patterns observed in its internal deployments. The tests are designed to be extended: teams add scenarios based on their agent’s specific tool set and data access patterns.

Clarity: Design Intent as Version-Controlled Artifact

Clarity addresses a different problem, earlier in the lifecycle. It is a structured design tool that guides engineering teams through the problem definition, solution exploration, failure analysis, and decision-tracking phases before a line of code is written.

It runs as a desktop application, a web interface, or embedded directly inside a coding agent. As a team works through a design session, Clarity writes the results to a .clarity-protocol/ directory in the repository as plain markdown files. Those files are committed, appear in pull requests, and accumulate as a reviewable history of the assumptions and decisions behind the codebase.

The output files cover four areas: the problem statement as the team actually understands it (which often differs from the stated requirement), the solution rationale and alternatives considered, a structured failure analysis covering what could go wrong at each design decision point, and the key decisions made and why.

The security-relevant piece is the failure analysis. Standard design reviews tend to skip structured failure mode analysis, especially under schedule pressure. Clarity makes it part of the session rather than a separate step. For agent applications in particular — where the failure modes often involve adversarial inputs, unexpected tool combinations, or data handling decisions that only become visible under load — having those failure cases documented at design time provides a baseline that security reviewers can evaluate against.

Context: Why Now

The timing of the May 2026 release reflects where the industry is. Agent deployments accelerated through late 2025 and early 2026 without a corresponding maturation in security practices. The dominant model was still: build the agent, run a manual red team engagement, ship it, and monitor for incidents. The regression testing gap, the lack of version-controlled design intent, and the absence of CI-integrated safety gates were recognized problems with no standardized solutions.

RAMPART and Clarity are not the first tools to address any of these problems individually, but they are among the first to package them as developer-native tooling that integrates into existing workflows without requiring a dedicated security team to operate.

Microsoft’s parallel investment in PyRIT and its AI Safety Evaluation Service (AISE) frames RAMPART and Clarity as part of a broader commitment to making safety testing infrastructure available to teams outside Microsoft that do not have the resources to build their own. Both tools are permissively licensed.

What Security Teams Should Know

For teams building or securing agentic applications, RAMPART addresses a concrete operational gap: without automated regression testing, you cannot know whether a model update, a prompt template change, or a new tool integration broke a safety behavior that was previously working. That is not a hypothetical risk — it is the default state of most agentic deployments today.

The Pytest integration matters because it puts safety tests in the same place and tooling as functional tests. Security controls that exist in a separate system are controls that get skipped when schedules compress. Controls in CI run on every commit.

Clarity matters most for teams that are still in design. For teams operating existing agents, the relevant question is whether the design decisions that shaped the current deployment were ever documented in a form that security reviewers can audit. In most cases the answer is no.

Both tools are available on GitHub under Microsoft’s AI Safety repository. The RAMPART starter test library and Clarity documentation are linked from the Microsoft Security Blog post dated May 20, 2026.