Microsoft AI safety tools RAMPART and Clarity move safety into CI

Microsoft is putting more of its AI safety work directly into developers’ hands. With the release of Microsoft AI safety tools RAMPART and Clarity as open source projects, the company is trying to move safety checks closer to the daily workflow of building agentic software, not just the final review stage.

That matters because the newest AI systems are no longer limited to generating text. They can access business tools, retrieve records, write code, and take actions across connected systems. Once software starts acting on behalf of users, mistakes become more than awkward chatbot answers.

Microsoft’s latest move centers on two different points in that lifecycle. RAMPART is aimed at testing agents continuously as they evolve. Clarity is built for an earlier moment, before code is written, when teams are still deciding what they should build and what could go wrong.

Microsoft opens two AI safety tools to developers

Microsoft open-sourced RAMPART and Clarity on May 20, 2026, making both projects available now for developers to use.

The two releases are closely related, but they solve different problems. RAMPART is an agent testing framework for continuous safety testing. Clarity is a structured tool designed to help teams check software engineering assumptions before coding begins.

Together, the new Microsoft AI safety tools reflect a broader push toward making safety an engineering discipline embedded in normal product work. Instead of treating AI safety like a periodic checkpoint, the idea is to turn it into something teams can revisit, measure, and improve in the same way they handle bugs, tests, and design reviews.

That is the bigger shift here. Open-sourcing tools is one thing. Trying to normalize safety as part of CI pipelines and repo workflows is something more consequential for teams building agents that can actually take action.

RAMPART brings safety testing into CI

RAMPART is built for a simple but hard-to-solve problem: how to turn AI safety failures into repeatable tests.

Microsoft describes RAMPART as an agent test framework for continuous safety testing, built on top of PyRIT. It supports adversarial and benign scenarios as repeatable CI tests, giving teams a way to encode known threats and expected behaviors directly into their development workflow.

In practice, that means engineers can treat certain AI risks more like software regressions. If a red-team exercise uncovers a weakness, or if an incident appears in production, the issue can be turned into a reusable test rather than living on as a one-off report or internal lesson.

That is one reason this release stands out. A recurring problem in AI development is that lessons from red teaming often stay trapped in documents or internal discussions. RAMPART tries to convert those lessons into engineering assets that can run again and again.

RAMPART focuses on prompt injection and probabilistic behavior

RAMPART’s most mature coverage today focuses on prompt injection attacks and probabilistic behavior.

Those two areas are especially important for agentic systems. Prompt injection can manipulate an agent indirectly through content it retrieves or processes, while probabilistic behavior makes AI systems harder to validate with one-time checks. A single successful run does not necessarily prove a system is safe, and a single failure may not capture the full pattern either.

RAMPART addresses that by supporting repeated testing in CI and by framing safety as something measurable over time, not a single pass-or-fail event checked at launch.

The framework also builds on PyRIT, Microsoft’s open automation framework for red teaming generative AI systems. That connection ties RAMPART to an existing red-teaming base while shifting the emphasis toward engineering teams working during development, not only researchers testing systems after they are already built.

Clarity checks assumptions before code is written

If RAMPART is about testing behavior, Clarity is about questioning intent.

Microsoft says Clarity is a structured tool to validate software assumptions before coding. The goal is to help teams pressure-test whether they are building the right thing before implementation locks in expensive decisions.

That may sound less dramatic than adversarial testing, but it points to a major source of AI failures: design choices that were never fully challenged early on. If a team gives an agent access to a tool, a workflow, or a sensitive path without thinking through edge cases and failure modes, the problem starts long before red teaming ever begins.

Clarity is meant to slow teams down at exactly that point.

How Clarity fits into the developer workflow

Clarity can run as a desktop app, a web UI, or inside a coding agent. It guides teams through structured conversations around problem clarification, solution exploration, failure analysis, and decision tracking.

Its outputs are stored in a .clarity-protocol/ repo directory, creating a written trail of the reasoning behind a project. That makes decisions visible inside the same place developers already work: the repository itself.

In practical terms, Clarity gives teams a shared artifact they can review and revisit. By writing those materials into the repo, it treats assumptions, rationale, and failure analysis as first-class engineering objects rather than loose notes that disappear into meetings.

This is another “why this matters” moment. AI systems often fail because teams move fast on implementation while leaving key design logic scattered across documents, chats, and memory. A tool that captures those assumptions directly in a repo could make it easier to revisit what changed, why it changed, and whether earlier safety reasoning still holds.

What Microsoft is really signaling with these releases

The release of Microsoft AI safety tools RAMPART and Clarity is also a statement about where AI engineering is heading.

The company is framing both tools as part of a move toward continuous, engineering-native safety for agentic systems. In that model, safety is not handled only by a separate review function at the end of development. It becomes part of the product lifecycle itself, from early design assumptions to CI testing of known attack paths.

That framing matches the structure of the tools:

• Clarity tackles assumptions before teams write code
• RAMPART turns safety scenarios into repeatable tests during development

Seen together, the pair covers two moments that often get missed: the early “should we build it this way?” phase and the later “does it still behave safely after changes?” phase.

For developers building agents, that is a meaningful distinction. The risk profile of systems that can read, decide, and act is different from that of static models. Safety work that lives only in final reviews can miss both early design mistakes and later regressions.

The people behind the projects

Microsoft lists Bashir Partovi as the lead for Microsoft RAMPART.

Clarity contributors include Yonatan Zunger, Dharmin Shah, Elliot H Omiya, Eve Kazarian, Sarah Cooley, and Neil Coles. Microsoft also credits Richard Lundeen, Nina Chikanov, Spencer Schoenberg, and Toby Kohlenberg among contributors tied to RAMPART and related work.

Those names matter less for star power than for what they suggest about the projects themselves: these tools are being positioned as working software for engineers, not just high-level principles for AI governance.

A push to make AI safety more operational

The strongest thread running through both releases is operationalization.

RAMPART is about making adversarial and benign scenarios repeatable in CI. Clarity is about making design assumptions explicit before coding and keeping those decisions attached to the repo through the .clarity-protocol/ directory.

That combination is a practical answer to one of the biggest challenges in modern AI development: safety knowledge is often fragmented. Some of it lives in security work, some in product design, some in engineering reviews, and some in post-incident debugging. Microsoft’s new open-source push tries to pull more of that into everyday development systems.

For teams building agents, that could be the real significance of these Microsoft AI safety tools. Not just that two projects were released, but that the company is betting safety has to be built into the same loops where software already gets designed, tested, reviewed, and shipped.