Red Hat makes data lineage the control plane for AI agents

Red Hat has published a practical enterprise-data architecture for AI agents that puts discovery, lineage and policy enforcement ahead of model selection. The useful part is not the familiar warning that data quality matters. It is the proposed control path: instrument every component, expose capabilities through open interfaces, and test whether an agent can stay inside its data boundary.

Lineage becomes runtime infrastructure

The Red Hat engineering post organizes the architecture around three dimensions: foundation, trust and ecosystem. The foundation starts with automated discovery, metadata cataloging, standard APIs and end-to-end lineage across both structured and unstructured data.

For lineage, the authors recommend a decoupled event model in which each pipeline component emits its own lineage events and a shared service correlates them. That is a consequential design choice for platform teams: provenance becomes runtime telemetry rather than a cataloging exercise performed after deployment. It also lets teams trace changes from ingestion and transformation through model training and agent use without tightly coupling the components.

The layered path runs from batch, streaming and change-data-capture ingestion through compute, catalogs and data abstraction, then into orchestration and governance. Developers and agents reach those capabilities through standard APIs and Model Context Protocol servers. Red Hat’s stated preference is for open contracts that allow individual implementations to be replaced without breaking consumers.

Access control is necessary but incomplete

The post draws a sharper boundary around agent governance. Traditional role-based access control can decide whether an identity may use a tool or dataset, but it cannot by itself stop prompt injection or prevent a model from reproducing sensitive material in an answer. Red Hat therefore pairs system-level authorization with semantic controls such as guardrails and prompt filtering.

It also calls for policy documents to be translated into machine-enforceable rules, then verified with positive and negative tests for each role. Token scoping, audit trails and conformity scores are treated as prerequisites for agent access, not compliance work to add later. For platform engineers, that shifts the acceptance test from “can this agent call the service?” to “can it prove that every task-specific data path stays within policy?”

Open, but not magically distributed

The ecosystem recommendation is deliberately federated: retain existing pipelines and storage, place governance and cataloging around them, and use stable interfaces between layers. The guide warns, however, that federation has physical limits. Training and heavy vector-embedding jobs may still need data placed close to compute to avoid latency and egress costs.

Red Hat also argues against reaching automatically for a standalone vector database. For early generative-AI workloads, adding vector search to an existing relational database may be sufficient; dedicated systems become more compelling at very large scale.

The resulting checklist is practical: audit catalog coverage, instrument lineage from the beginning, choose open standards, define agent governance before granting data access, and plan hybrid placement around data gravity. The common thread is that an enterprise AI platform is not just a serving layer. It is a governed data-routing system whose evidence must survive every hop.