Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow

The AI systems shipping inside enterprises today are fundamentally different from the ones we were building even two years ago, because they have moved well past answering questions and into accessing your email, retrieving records from your CRM, writing and executing code, and taking actions on your behalf across dozens of connected systems. The post Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow appeared first on Microsoft Security Blog .

In this article Why we are investing in this RAMPART: Continuous safety testing for agentic AI Clarity: Helping check software engineering assumptions RAMPART and Clarity available now The AI systems shipping inside enterprises today are fundamentally different from the ones we were building even two years ago, because they have moved well past answering questions and into accessing your email, retrieving records from your CRM, writing and executing code, and taking actions on your behalf across dozens of connected systems.

That shift from “generate text” to “do things in the world” changes the safety equation entirely, because an agent that can act can also potentially act in ways nobody intended. Today Microsoft is open-sourcing two tools designed to help engineers: Microsoft RAMPART , an agent test framework for encoding adversarial and benign scenarios as repeatable tests that can run in CI, making it easy to turn red-team findings and AI incidents into lasting regression coverage; and Clarity , a structured sounding board that helps teams figure out whether they are building the right thing before they write a single line of code.

We built these tools because we believe that AI safety has to become a continuous engineering discipline rather than a periodic checkpoint, and we think the best way to make that happen is to put practical, open tools in the hands of the people doing the building. Why we are investing in this Helping teams think through the “why,” before the “how” of software building: In the vibe coding era, execution is easy and the harder question is the “why.

” The most expensive safety failures we see almost always trace back to design mistakes that nobody questioned early enough, long before any adversary got involved — say, when a product team decided their agent should have access to a tool, or handle a particular user flow, without fully working through what could go wrong. By the time a red team engagement surfaces the issue, the system is largely built, and addressing it means going back to the drawing board.

We wanted to give product managers and engineers a way to pressure-test their assumptions at the start of a project, when changing course is cheap and the right conversation can save months of rework. Scaling the lessons of red teaming across the industry. The techniques that uncover vulnerabilities in one agentic product almost always shed light on another. A cross-prompt injection attack that works against one system will often work, with minor variations, against a customer service agent or a coding assistant. But those lessons tend to stay locked inside individual engagement reports.

Our goal was to build a system where the lessons of red teaming exercises can be turned into runnable engineering assets.   Making incidents reproducible and mitigations verifiable.