agent ran dbt build against the prod target instead of dev

TL;DR

The agent inherited a prod-pointing profile or a default target of prod, so its build wrote to production. First assess what the build changed, then harden the setup: make dev the default target, require an explicit --target flag for prod, and give the agent credentials that cannot write prod. A guardrail that depends on the agent remembering is not a guardrail.

agent ran dbt build against the prod target instead of dev

Use this when

• an agent or script ran dbt build and the logs show the prod target or prod schema
• the agent environment has profiles.yml with prod as the default target
• prod tables show unexpected rebuild timestamps or content from a test build

Not for this skill when

• a human intentionally deployed to prod through the normal release process, no incident handling needed
• the run failed before writing anything (compile only), document and still fix the default target
• you have no separate dev target yet, creating one is step zero before agent access resumes

Steps

1. Assess impact first: from the run logs and run_results.json, list which models built in prod, and check downstream consumers and data freshness. Decide with the data owner whether to roll back (restore or rebuild from the last good prod run) or accept the content. Verify: impacted prod models are listed and a rollback or accept decision is recorded.

2. Fix the profile defaults: reorder or set target: dev as the default output in the profiles file the agent uses, and remove prod outputs from the agent copy of profiles.yml entirely if the agent never needs prod. Verify: the agent profile defaults to dev and cannot resolve prod credentials.

3. Add an explicit gate for any prod execution: prod runs require a human-triggered job or a separate service account, and the agent service account gets read or dev-schema-only grants in the warehouse. Verify: warehouse grants enforce the boundary even if a command asks for prod.

4. Run a drill: have the agent execute its usual build command and verify from the logs that it resolved the dev target and schema. Verify: a test build lands in dev schema only, confirmed in the warehouse.

Variant phrasings

dbt Cloud environments confused

Cloud separates environments by target and credentials. Point the agent at the development environment credentials, never the deployment environment.

target flag present but wrong variable

CI variables like DBT_TARGET can silently override intentions. Print the resolved target at job start in every automated run.

Compatibility: dbt profiles.yml target selection and --target flag; dbt Cloud environments. Warehouse role grants are the enforcement layer on every adapter.

Why it happens

dbt runs against whatever the resolved target says, and resolution falls back to the profile default when no flag is passed. Agents execute commands literally and do not sanity check environments the way a human might at a prompt. If the ambient default is prod, an ordinary build command becomes a prod write without any single step looking wrong.

Edge cases / pitfalls

• Dev defaults protect against accidents, not against a determined wrong flag; warehouse grants are the real boundary.
• Shared profiles between humans and agents invite this incident; keep a separate, reduced profile for automation.
• Post-incident, check snapshots and seeds too: a full build may have advanced snapshots in prod in ways a rebuild cannot rewind.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iT7PVENxS7OczI-OIvKt9Q