An AI agent drops a column. The SQL query executes cleanly. No syntax error is thrown. No on-call engineer is paged. Three production models depended on that column, and nobody finds out until churn scores go quietly wrong next week. The failure is that nothing appears to break until it's expensive.
Data platform teams who have started letting AI agents propose schema changes, dbt refactors, and database migrations on production infrastructure — and want a second opinion before any of it ships.
A PRODUCTION ML model (churn_model) depends on this column. Dropping it breaks live predictions with no error thrown.
Your AI agent proposes a schema change — a dropped column, an altered type. Bulwark intercepts it before it reaches the database.
A separate agent queries DataHub's actual downstream graph via mcp-server-datahub — which dashboards, models, and pipelines depend on this column, for real.
Bulwark allows, warns, or contains the change — and writes the verdict back into DataHub so every future agent inherits the ruling.
An AI worker agent proposed a task. If that same worker checks its own work, it shares the exact same blind spots that produced the initial proposal. Bulwark splits authority: the worker has permission to propose, the governor has permission to block, and neither can override the other.
The governor reads end-to-end DataHub lineage via mcp-server-datahub. Its veto is derived dynamically from the graph, catching what the worker structurally cannot.
When Bulwark contains a proposal, it writes metadata tags urn:li:tag:bulwark-contain back into DataHub. This creates a ratchet effect: every decision feeds back into the graph, ensuring subsequent AI agents and human engineers inherit the governor's ruling.
Open the review queue to evaluate contained worker proposals, inspect downstream blast radius, and execute human decisions.
Open console queue