Microsoft Open-Sources Rampart and Clarity for Production Agent Safety

Microsoft Rampart and Clarity for AI agent safety

Microsoft has released two open-source tools aimed at the same gap: safe deployment of AI agents. Rampart and Clarity sit at different stages of the build process, but together they cover a problem most teams still treat as a one-off review rather than engineering discipline.

The issue is practical. Agents that act on email, move data between systems, execute code, or call internal APIs can cause real damage when instructions are misinterpreted or permissions are too broad. Many teams rely on ad hoc red-teaming or vague governance docs. Microsoft’s answer is to make safety testable and to make its absence expensive to ignore.

Rampart: agent safety testing in CI

Rampart is a pytest-native safety and security testing framework for agentic AI applications. It encodes red-team findings as repeatable tests and runs them inside the same pipeline that ships the agent.

That means a prompt injection regression, a privilege escalation path, or an unsafe tool-binding choice becomes a failed build instead of a production incident. The framework includes workflows for adversarial attacker simulations, reproducing bad behaviour, and validating fixes. Those workflows map to certification activities, which makes it useful for teams that need to show evidence of control to internal audit or compliance reviewers.

Rampart builds on PyRIT, Microsoft’s Python Risk Identification Tool for generative AI. PyRIT already covers red-teaming and risk identification for generative AI systems. Rampart applies that foundation to agent-specific failure modes: orchestration, tool use, and permission boundaries rather than simple prompt-output testing.

The GitHub repo is live now.

Clarity: design-stage agent engineering

Clarity works earlier. It is an AI thinking partner that runs as a desktop app, web UI, or embedded component inside a coding agent. Its job is to surface failure modes, design conflicts, and trust-boundary assumptions before implementation starts.

The output is stored as markdown files in the repo. That makes the design conversation reviewable in pull requests, versioned with the rest of the codebase, and auditable later. Clarity keeps a current plan by distilling intent, surfacing where requirements conflict, and tracking how decisions change over time.

That matters because the cost of fixing a bad agent design grows fast once tool bindings, permissions, and orchestration layers are hard-coded. Changing a document is cheap. Changing a deployed agent that can write emails or modify records is not.

The GitHub repo is also live now.

What this changes

These tools do not make an agent safe by themselves. What they do is move safety out of the annual review cycle and into the parts of the workflow where problems are cheapest to fix.

Rampart gives engineering teams a regression surface for agent behaviour. Clarity gives product and engineering leads a structured way to ask the hard questions before coding begins. If the answers end up in the repo as design documents, then reviewers can assess whether the agent was built for the right failure modes instead of whichever ones happened to appear during testing.

The source used for these details is the public Microsoft repositories themselves, because the README and repo metadata describe the intended behaviour better than any summary.

For teams already building on Azure AI or any other agent platform, the useful next step is to add one Rampart test to the CI suite and run one Clarity session before the next feature write. That is enough to see whether the gap between “the red team found a problem” and “the team has a regression test for it” is actually closed.

Connect with me on LinkedIn.