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