Data Mutation Gate
Gate AI agent data mutations before production changes.
AI agents do not only write code. When they hold database, provider, or tool credentials, the dangerous action is the mutation itself. Permission Protocol puts a signer in front of that action boundary.
The problem
Agents can delete production rows, backups, volumes, or provider resources through APIs that never pass through GitHub.
A PR approval does not cover a direct database command or provider API call made by an agent session.
After an incident, teams need evidence of who approved the exact resource, environment, and destructive action.
How Permission Protocol handles it
Wrap destructive database and provider methods with a pre-execution authorization check.
Require approval for production data mutation, backup deletion, and volume deletion based on environment and resource.
Issue a receipt that binds the actor, tool, action, resource, environment, approver, and expiry.
Concrete bad scenario
An agent has a provider token that can delete a production database, backup, or volume. The change does not require a PR, so the gate must sit before the provider API call.
Policy Permission Protocol applies
Read-only production inspection can clear automatically. Production database deletion, backup deletion, bulk row deletion, and volume deletion require a named human signer. Unscoped destructive actions are denied.
Exact enforcement point
The database proxy, provider API wrapper, job runner, or MCP tool calls Permission Protocol before executing the mutation. If no valid receipt exists for the exact action, resource, environment, and actor, the call fails closed.
Sample receipt
Would Permission Protocol block this?
Production backup deletion
An agent attempts to delete a production backup through a provider API. The call pauses until an authorized signer approves that exact backup and environment.
Read-only customer lookup
The agent reads a customer status field. Policy treats the read as low risk and lets the call proceed without manual approval.
Unscoped table truncate
The agent requests a broad production truncate without a specific resource or recovery path. Policy denies the action instead of offering an approval shortcut.
Implementation checklist
- 1Identify agent tools, provider APIs, and scripts that can mutate production data or backups.
- 2Route destructive mutations through a Permission Protocol wrapper before execution.
- 3Set policies for allowed reads, approval-required mutations, and denied destructive actions.
- 4Store receipts next to database, provider, and incident logs for review.
FAQ
Is this the same as Deploy Gate?
No. Deploy Gate covers PRs and deploy workflows. Data Mutation Gate covers direct database, provider, or tool actions that can change production data without a PR.
Does every data operation need a human?
No. Reads and low-risk mutations can clear under policy. Destructive production mutations need a signer because the blast radius is immediate.
Where should the gate live?
Place it at the real action boundary: database proxy, provider wrapper, job runner, MCP tool, or internal admin tool. A GitHub-only gate will miss direct credential paths.