Today, Red Hat announced asago, a collaborative, open source AI safety project in partnership with Alquimia AI, Brave Software, EvalEval coalition, IBM Research, Interdisciplinary Transformation University Austria, Microsoft, MIT Lincoln Laboratory, North Carolina State University, NVIDIA, and The Alan Turing Institute. In this blog post, I’d like to spend some more time elaborating on why we felt a new community was necessary, what we aim to achieve, and what the state of play is at present.The open source AI safety ecosystem is a rich one. There are plenty of excellent and mature projects across areas such as guardrails, evals, red teaming, and agentic security, and these are complemented by comprehensive risk frameworks, ontologies, and mappings. These are important projects that need continued development. At Red Hat, our AI Safety team collaborates with, and contributes to, many of these upstream communities, and we'll continue to do so.Additional enterprise challenges in AI safetyHowever, when you look at a typical enterprise organization, they have additional challenges beyond these tools. When you examine the process of onboarding a new, potentially custom built, AI agent there are wider stakeholders, assets, and processes that aren't touched by existing tools.Onboarding a new agent typically follows this path:Policy development: Teams produce written policy documents encoding the organization's AI dos and don'ts, often referencing external regulation like the EU AI Act, and sometimes supplemented by use-case-specific constraints (for example, stricter rules for customer-facing agents).Risk extraction: Someone has to read those documents and identify which theoretical risks they contain.Risk triaging: Of those theoretical risks, someone has to decide which apply to this specific agent, and which are technical risks that can actually be tested.Scenario generation and red teaming: Technical teams must then build test scenarios for those risks and run them through existing red-teaming frameworks.Iteration: Results are then interpreted, guardrails or other fixes are applied, and the agent is retested until it's ready to deploy. If the process is manual, then this adds major overhead each time.This process leads to slow approvals and a disconnected audit trail, making it hard to demonstrate to internal or external auditors what was actually done.asago aims to solve these problems, collaborativelyThe asago project aims to alleviate this pain. We want to help organizations get from their AI policies to production without needing to be experts in AI safety. Importantly, our aim isn't to replace existing AI safety tooling, but rather to act as an orchestration layer to join ecosystem components together. We'll integrate with the best tools where they exist, and fill in the gaps when they don’t.Of course, this must be a collaborative process. We don’t believe that a single organization can or should do this alone. With the wide range of policy documents, model and agent types, deployment contexts, regulatory contexts, and more, a project like this needs a wide range of view points—diverse expertise is non-negotiable.This is why we have excellent initial partners that represent technology companies, research institutions, community coalitions, and government organizations. Together we won't just write the code, we'll also make sure we’re asking and answering the right questions. And as a global community, we need to make sure we have sufficient linguistic and geographical representation. We’re launching with partners across US, UK, and Europe, and we strongly encourage more collaborators to join us to expand this coverage via the links below.An evolving technical architectureThe technical architecture will evolve with the project, but here is our initial view. The process is split into 2 sections: