Your deploy job also applies schema migrations to the production ledger. How would you argue that design must change?

## The modelling claim A deploy job's identity is not "the credential to deploy". It is the union of every authority the job exercises, and the model should draw it that way. Once migrations are part of the deploy step, the pipeline holds application deployment authority *and* the ability to execute arbitrary statements against the production database. From the diagram's point of view, a data flow now runs from a file in the repository, through the deploy process, into the store that holds the money — and every merged change rides it. ## Why review does not cover it The attacker here need not be an outsider. It is a developer whose change is reviewed for logic by a colleague who is not thinking about database authority at all. Migration review in most teams asks: does it apply, is it reversible, will it lock a table for too long. It does not ask: what does this statement do to the rows. The reviewer approves the change with no sense that they are authorizing a money-affecting operation, and the resulting production change is attributed to the pipeline identity rather than to either of them, which is a repudiation problem on top of an authorization one. That asymmetry is the heart of the argument. The control everyone points to — code review — is real, but it is not scoped to the authority being exercised. A control that exists but does not look at the threat is not a mitigation. ## Framing the argument for a decision-maker Do not argue that running SQL from a pipeline is inelegant. Argue three things: 1. **Authority.** One merged file executes with an identity permitted to rewrite financial records. Name what that identity can do today, in plain language. 2. **Coverage.** Nothing in the review path is scoped to that authority, so the likelihood is not held down by the control we claim holds it down. 3. **Reversibility.** A bad code deploy is undone by deploying again. A migration that overwrites rows in place may have no prior version to restore, and reconstructing a ledger from backups plus replay is an incident measured in days, with regulatory exposure attached. ## The options and their real costs **Split the database privileges.** Give the deploy identity rights over schema objects and withhold row-level write rights on the ledger tables, so an unbounded rewrite is refused by the database itself rather than by a reviewer's attention. This is usually the cheapest large reduction available. Cost: some legitimate data backfills stop working through the pipeline and need another route, and someone must own the privilege model as tables are added. **Separate the path.** Move migrations to their own gated flow with its own approver and its own identity, distinct from application deploys. Cost is real: you reintroduce ordering problems — the application version that expects the new column versus the schema change that has not run — and you have made release engineering harder for every team, in exchange for a boundary that only matters on the tables that hold value. **Keep it and compensate.** Require a named second reviewer specifically for migration files, forbid data-mutating statements by policy, and run invariant checks against the ledger after every deploy so a bad change is detected in minutes. Cost: it depends on human diligence and on detection rather than prevention, which is exactly the class of control that decays. **Restrict the shape of migrations.** Permit structural changes through the pipeline, and require anything that rewrites existing rows to run as a reviewed operational task with its own authorization. This splits by risk rather than by mechanism and is often the pragmatic middle. ## How to close There is no single right answer, and a principal is expected to say so while still recommending one. My recommendation is normally privilege separation first, because it converts a policy hope into a database refusal and costs least; then restricting migration shape; and a fully separate path only where the value at stake justifies the ordering pain. What I would not accept is the status quo defended on the grounds that it has never gone wrong: the model's job is to price a consequence that is irreversible before it is realised, and "we review everything" is a claim about diligence, not about authority. ## Keeping scope honest This is a question about what authority the delivery path holds, not about database administration practice or about how migrations should be authored. The output of the exercise is a decision about the deploy identity and about which flows into production data are permitted to originate from a merged commit.