Red Hat tests a translation layer from AI governance policy to runtime permissions

Red Hat engineers have tested a policy-driven data-access workflow that turns governance text into adversarial scenarios, permission recommendations and a repeatable validation loop for AI agents. The proof of concept is an early design rather than a product feature, but it makes a useful distinction: authorizing an agent to call a tool is not the same as controlling which records and fields that tool may return. (Red Hat)

What the prototype does

The team used and extended the open source Asago framework around a read-only retrieval assistant for an insurance scenario. Underwriters were meant to retrieve underwriting guidance and property-risk information, while compliance reviewers could reach both underwriting and claims domains. A governance policy and a plain-language description of the assistant supplied the starting inputs. (Red Hat)

Asago generated harmful scenarios designed to violate those boundaries. In the baseline configuration, a cross-domain request from an underwriter returned claims information alongside permitted underwriting material. The evaluation marked that response as a policy violation. A permission recommender then combined the policy artifacts, the finding and the deployed asset configuration to propose changes for a data registry and Feast-based retrieval layer. (Red Hat)

After the permissions were applied, the same evaluation denied claims retrieval for the underwriter while retaining access to underwriting data; the compliance role kept access to both domains. That sequence matters because the control is not merely generated—it is tested before and after remediation. (Red Hat)

Why MCP authorization is not enough

MCP and comparable protocols can answer whether an agent may invoke a tool or connect to a service. The Red Hat post argues that a separate decision remains inside the data path: which assets, records and fields that invocation may expose for a particular user and task. Enforcement may span vector databases, feature stores, catalogs, object storage and MCP servers, each with its own identity and policy model. (Red Hat)

The proposed translation layer therefore has three stages: extract structured access rules from governance documents, map them to the authorization mechanisms already used by each system, and generate allowed and denied tests against the live deployment. It is not presented as a replacement policy engine or runtime proxy. (Red Hat)

What platform teams should take from it

This is still a proof of concept, and Red Hat says the current approach works at dataset granularity. Field-level masking—for example, exposing a claims narrative while redacting personally identifiable information by role—remains future work. Red Hat is exploring how OpenShift AI might surface policy-driven controls, but the post does not announce a supported OpenShift AI capability. (Red Hat)

The immediate engineering lesson is narrower and practical: treat governance-to-policy translation and negative access testing as a deployment pipeline, not as a one-time configuration exercise. For teams already combining MCP tools with multiple data stores, that validation loop is the missing control worth prototyping first.