Let AI agents change production data, safely
Most teams keep agents read-only because one bad write can wipe a table. Data Workers gives agents write access through a single approval path: every change is proposed with its impact and an undo path, approved by a named owner and recorded in a tamper-evident audit trail.
Before and after
| Today | With Data Workers |
|---|---|
| Agents kept read-only, or given a service account that can write anything | Agents read freely and write only through one approval path |
| A change described in a chat message, if at all | Every change proposed with what it touches and how to undo it |
| Approval by whoever happens to be online | A named owner approves, and the highest-risk changes need two people |
| Broad write permissions that outlast the task | Writes limited to the statements the change was approved for |
| Logs scattered across tools, reconstructed after an incident | One tamper-evident audit trail of what was asked, approved and run |
Agent write access is where most data teams stop. The risk is real, and agents that have wiped production databases are public record, so the answer cannot be "trust the model". This page is the operating model for the write path; is it safe to let AI agents change production data is the deep dive on the risk question itself.
How it works
1. Propose the change with its impact and undo path
An agent that wants to change production data does not run anything. The Data Context & Catalog Agent shows what the change would touch downstream with blast_radius_analysis, and the Data Access & Governance Agent tests the request against your rules with check_policy. The proposal that reaches your team carries the full change, what it would affect and how to undo it.
2. Approve it by a named owner
The Data Access & Governance Agent routes the proposal to the owner of that data with request_governance_review. Anything irreversible waits for a named person. The highest-risk changes need two different people, and the person who asked can never be the one who approves. See how approvals work for AI data agents for what the owner sees.
3. Run only what was approved, and keep the record
After approval, the agent that owns the work runs it, for example the Schema Evolution Agent with apply_migration or the Pipeline Building Agent with deploy_pipeline. Warehouse writes are limited to the statements the change was approved for. The Observability Agent reads back the signed record of what was asked, approved and run, with get_audit_trail.
The impact metrics we move
- •A proposed change with impact and undo plan: from about 2 days to ~15 min
- •An agent change approved by a named owner: from about a week to ~1 h
- •An export of every agent write for an auditor: from about 2 weeks to 2 h
Where teams start
- •Schema migrations. The Schema Evolution Agent proposes the change and its rollback plan; the table owner approves.
- •Pipeline fixes. Failed Airflow or dbt jobs get a proposed repair instead of a 2am manual patch.
- •Access grants. Requests for Snowflake, Databricks or BigQuery data proposed with the policy check attached.
- •Dead table cleanup. Retirements proposed with the dependents listed, approved by the table's owner.
- •Coding agents on the warehouse. Claude Code or Cursor asking for a write, held to the same approval path as our own agents.
What powers it
Safe writes come with the Data-Agents Swarm: one approval path and one audit trail shared by every agent, in your own environment if you run it there. The Autonomous Data-Conductor keeps each agent inside the autonomy its domain allows, Autopilot Standards hold every domain to the rule you set once, and the Spellbook Data Catalog supplies the owners that make a named approver possible. The Data Access & Governance Agent, Data Context & Catalog Agent and Observability Agent do the work. The pattern is explained in approval gates for data agents, and guardrails for AI in data pipelines covers the mistakes they are built to catch.
Where this shows up: AI agent governance, every agent change reversible, audit logging and AI and ML platform data teams.
The climb: from assisted to autonomous to agentic
Every transformation runs on the same ladder from our thesis: agents first watch and suggest with receipts, then act after approval, and a domain moves up only on its own review record. L0 to L2 run today, and only a domain's owner can raise its level. L3 and L4 are where a domain can go on evidence; the autonomy levels explained lay out the scale.
The pilot
- •Scope. One data domain, one warehouse and the agents that write to it.
- •First week. Agents start by watching and suggesting. We show the changes they would have proposed, each with its impact, its undo path and the approver it would go to.
- •By week two. Routine changes flow through the approval path to named owners; anything irreversible stays with a person, and the highest-risk changes need two.
- •At day 30. We review the impact metrics against your baseline:
- •A proposed change with impact and undo plan: from about 2 days to ~15 min
- •An agent change approved by a named owner: from about a week to ~1 h
- •An export of every agent write for an auditor: from about 2 weeks to 2 h
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Can an agent write to production without a person? Not through Data Workers. Every write goes through the approval path, and anything irreversible waits for a named person. You choose, per domain, how much an agent may do on its own.
Who approves, and can the requester approve their own change? The owner of the data approves. The highest-risk changes need two different people, and the person who asked cannot be one of them.
What if an approved change turns out to be wrong? Every change records how to undo it before it runs, and supported changes can be reverted from that record. Code changes are reverted the normal way, through a pull request. If people keep reverting an agent's changes in a domain, the agents there stop acting on their own and hand back to a person.
What do auditors get? A signed, tamper-evident record of each change that can be verified independently, and an evidence pack you can export in one step.
Which stacks? Snowflake, Databricks and BigQuery, with dbt and Airflow, among 50+ connectors.