Asago turns AI policy into an engineering pipeline—but the hard part is still ahead

Red Hat’s asago project starts from a useful observation: enterprises do not lack AI safety tools so much as they lack a repeatable system for connecting policy, risk analysis, testing and remediation. The project introduction describes asago as an orchestration layer rather than a replacement for guardrails, evaluation frameworks or red-team tooling.

What the architecture does

The proposed workflow has two parts. First, a policy mapper extracts risks from written policies and maps them to the IBM Risk Atlas. A scenario generator then narrows those theoretical risks to the tests that matter for a specific agent and its deployment context. The result is a set of scenarios that evaluation and red-team systems can execute.

The second part is iterative. Asago is intended to trigger evaluation frameworks through EvalHub, pass the resulting artifacts to a recommender, and produce candidate mitigations. Red Hat says those mitigations could include guardrails and should be deployable as Kubernetes custom resources or ConfigMaps, so teams can retest the changed system rather than treating review as a one-time document exercise.

That is the important design choice. The project treats AI governance as a delivery pipeline with versionable inputs and testable outputs—not as a final approval meeting held after an agent is already built.

Who should care

Platform and AI engineering teams should watch asago if they are building an internal agent platform or trying to standardize onboarding across many application teams. The architecture could provide the missing connective tissue between governance documents, risk catalogs, agent-specific tests and deployment controls.

Security and compliance teams also gain a clearer audit path. Red Hat argues that today’s manual handoffs create slow approvals and disconnected evidence. A system that records how a policy produced a risk card, a scenario, a test result and a mitigation could make that chain easier to inspect.

What to try—and what not to assume

Asago is early. Red Hat explicitly calls the architecture an initial view and says the roadmap is still evolving. The available work includes a policy mapper, examples and midojo, a framework for testing agents against indirect prompt injection. Teams evaluating it should begin with one real policy and one bounded agent, then inspect the quality of the risk mapping and generated scenarios before connecting the workflow to production controls.

The unresolved questions matter: policy interpretation can be ambiguous, synthetic tests can miss operational failures, and a generated recommendation is not the same as a validated fix. Asago’s value will depend on transparent mappings, reproducible evidence and integrations that let specialists challenge each stage.

Still, the project puts the boundary in the right place. Rather than promising a universal safety score, it proposes an open pipeline that makes policy-to-production work visible, repeatable and contestable.