MP091WARNINGFree
warn-privilege-drift
What It Detects
GRANT/REVOKE mixed into a DDL migration makes access-control changes invisible to review and impossible to audit in one place.
Why It's Dangerous
A GRANT in the middle of a schema migration is a permanent access-control change being reviewed as though it were a schema change — the reviewer is checking whether the column type is right, and the privilege line goes past in the same diff. The durable problem is auditing: "who can read this table, and who approved that" has no answer short of replaying every migration in order. Rollback is asymmetric too, because reverting the schema change does not revert the grant.
Bad Example
-- migrations/012_add_reports.sql CREATE TABLE reports (id BIGINT PRIMARY KEY, body TEXT); CREATE INDEX idx_reports_created ON reports (created_at); GRANT SELECT ON reports TO analyst; -- Access decision buried in a schema diff
Good Example
-- migrations/012_add_reports.sql — schema only CREATE TABLE reports (id BIGINT PRIMARY KEY, body TEXT); CREATE INDEX idx_reports_created ON reports (created_at); -- The GRANT moves to 013_grant_reports_access.sql, so a search for -- GRANT across the migrations directory returns something meaningful.
Configuration
Disable this rule:
# .migrationpilotrc.yml rules: MP091: false
Or change its severity:
# .migrationpilotrc.yml
rules:
MP091:
severity: warning