AI governance often breaks at the handoff between policy and engineering. Compliance teams write requirements, evaluators design tests, platform teams configure controls and auditors later try to reconstruct why a safeguard exists. Red Hat’s new open-source asago project aims to connect those steps in one traceable workflow.
Backed by contributors including NVIDIA, IBM Research, Microsoft and academic institutions, asago is being released under the Apache License 2.0. Its promise is ambitious: translate policy into risk assessments and deployment-ready controls for AI systems. Its current reality is more modest—the project is still in formation, with no published production deployment or independent performance evidence.
Policy clauses become tests and controls
Red Hat describes a four-stage workflow. Risk mapping begins with an organisation’s governance policy and connects its requirements to frameworks such as the NIST AI Risk Management Framework, the OWASP LLM Top 10 and the EU AI Act, using IBM’s AI Risk Atlas as a catalogue.
The project then generates risk-assessment scenarios tailored to the intended use case. Instead of applying only a generic checklist, it is meant to test for behaviours associated with the risks identified during mapping. Results feed into mitigation, where asago recommends guardrails and records a rationale for each choice.
Finally, the workflow is intended to turn those controls into configurations that can run in hybrid-cloud and Kubernetes environments. Red Hat says this could reduce deployment timelines from months to days. That figure is a project goal, not a result supported by a customer case study in the source.
The attraction is clear. A control described only in a report can drift away from the system it supposedly governs. A declarative configuration can be versioned, reviewed and deployed alongside other infrastructure, making governance part of engineering change rather than a separate paperwork exercise.
A continuous audit trail is the central proposition
Asago is designed to link each policy clause to a test and each test to a running control. In principle, a reviewer could start with a safeguard in production and trace it back to the requirement that justified it—or begin with a policy statement and verify how it is enforced.
That chain becomes more valuable as organisations move from short AI pilots to agents that operate for extended periods. Models, tools, permissions and external data can change after approval. A static assessment says what was examined at one moment; a continuous workflow can reveal whether the active system still matches the approved risk posture.
Infrastructure independence is another stated aim. Red Hat says asago will produce declarative configurations for Kubernetes, Terraform and Ansible, reducing the need to rebuild governance controls for each cloud. Portability will nevertheless depend on how abstract policies map to provider-specific services and whether equivalent controls behave consistently.
Automation also introduces a new review problem. Policy language is frequently ambiguous, overlapping or jurisdiction-specific. If software maps a clause to the wrong risk or selects an inadequate guardrail, a complete audit trail can document an error without preventing it.
Open collaboration must still prove operational trust
The contributor list is broader than a single vendor: Brave Software, MIT Lincoln Laboratory, North Carolina State University, the Alan Turing Institute and others join Red Hat, NVIDIA, IBM Research and Microsoft. That diversity could help the project cover different safety perspectives and technical environments.
It can also produce disagreement. The source does not explain how conflicting interpretations, changes to risk frameworks or disputes over acceptable tests will be resolved. Project governance will matter as much as the repository’s code because these decisions shape what organisations later treat as compliant behaviour.
Early adopters should therefore test traceability, not just generation speed. A pilot should select several concrete policy clauses, inspect the proposed risk mappings, challenge the test scenarios, deploy controls in a non-production environment and confirm that evidence remains understandable after configuration changes.
Teams should also establish who approves machine-generated mitigations and how exceptions expire. No automated workflow removes accountability from the people operating the system.
Asago targets a genuine enterprise bottleneck by treating governance as deployable infrastructure. Whether it succeeds will depend on the quality of its mappings, the portability of its controls and the willingness of reviewers to question automated recommendations. For now, it is an open invitation to help build that evidence—not a finished compliance product.
