# Production data & databases: enterprise AI policy pack

Keep agents useful for diagnosis, query authoring and migration preparation while preventing them from destroying production data, database services or recovery paths.

Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values.

## Control scope

- Protected assets: Production databases, schemas, tables, datasets, snapshots and backups
- Consequential actions: Destructive DDL, service deletion, bulk mutation, recovery changes and schema migration
- Applicable systems: SQL engines, cloud database services, warehouses, migration tools and database CLIs
- Context to resolve: Resolve the credential, endpoint, account/project, database, schema, object, environment classification and estimated impact before deciding.
- Enforcement boundary: Enforce in database privileges and cloud IAM first. Intercept agent, CLI and MCP execution for intent-aware decisions and explanations; direct consoles and SDKs need the same downstream deny.

## Owners

Database platform owner + service owner

## Configure first

- Authoritative production database, account, project and dataset inventory
- Protected schemas and tables, criticality tier, data owner and recovery objective
- Row-impact thresholds, approved migration runner and emergency recovery process

## Shared decision baseline

### Resolve the real target

Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority.

### Fail closed on consequential ambiguity

If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk.

### Bind approval to the exact action

An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action.

### Keep an evidence-grade decision record

Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity.

## Policies

### PD-01: Block destructive DDL against production data

- Severity: Critical
- Decision: Block
- Owner: Database platform owner

#### Policy statement

Deny any request that drops or truncates a production database, schema, table, collection or dataset. Unknown environment classification is treated as production for destructive DDL.

#### Covered operations

- DROP DATABASE
- DROP SCHEMA
- DROP TABLE
- DROP COLLECTION / DATASET
- TRUNCATE TABLE, including CASCADE or partition-wide variants
- Equivalent SDK, warehouse, migration-tool and admin API operations

#### Evaluation rules

- Resolve the live connection endpoint and immutable database/project identifier; do not infer safety from a local profile, alias or resource name.
- Parse every statement in a batch, migration and stored procedure. Expand CASCADE, wildcard, selector and dependency effects before deciding.
- Deny when any resolved target is production, protected or unresolved. Read-only introspection and EXPLAIN remain permitted.
- Do not allow the agent that requested the action to relabel the target or disable this policy.

#### Example decisions (illustrative; do not run against live systems)

- **PostgreSQL:** `DROP TABLE public.orders CASCADE`. Block when the connection resolves to production.
- **BigQuery:** `Delete dataset analytics_prod with contents`. Block even when issued through an SDK or console-backed tool.

#### Applicable tools and systems

- PostgreSQL
- MySQL
- Microsoft SQL Server
- Oracle Database
- Snowflake
- BigQuery
- Databricks SQL

#### Enforcement

Remove destructive ownership/DDL privileges from routine agent identities and route production migrations through a controlled runner. Intercept SQL, database CLIs, migration tools and MCP calls before execution; database permissions remain the final boundary.

#### Exception / approval

No self-service exception. Use a separately authenticated break-glass or approved migration workflow with backup verification and an independent operator.

#### Test fixtures

- Should remain permitted: Run SELECT, EXPLAIN and schema introspection against a permitted production database, and execute destructive DDL only in an explicitly classified ephemeral test database.
- Should be blocked or held: Drop a production table, truncate a protected partition, hide DROP in a multi-statement batch, or target an endpoint whose environment cannot be resolved.

#### Implementation references

- [PostgreSQL · DROP TABLE](https://www.postgresql.org/docs/current/sql-droptable.html)
- [PostgreSQL · Database privileges](https://www.postgresql.org/docs/current/ddl-priv.html)

### PD-02: Block deletion of production database services

- Severity: Critical
- Decision: Block
- Owner: Database service owner

#### Policy statement

Deny deletion of a production database instance, cluster, server, warehouse or account and deny changes whose purpose is to remove deletion protection immediately before deletion.

#### Covered operations

- Delete database instance, cluster, logical server, warehouse or project dataset
- Disable deletion protection, remove a protective resource lock or skip the final snapshot
- Delete the last production replica when it eliminates service or recovery capacity

#### Evaluation rules

- Resolve the provider account/project/subscription, resource ID, environment tag and dependency graph from the active identity.
- Treat protection removal followed by deletion as one sequence, including attempts split across agent turns or tools.
- Block deletion of protected production resources regardless of final-snapshot options; a snapshot does not make unilateral deletion acceptable.

#### Example decisions (illustrative; do not run against live systems)

- **AWS RDS:** `DeleteDBInstance(prod-orders, SkipFinalSnapshot=true)`. Block.
- **Google Cloud SQL:** `Disable deletion protection on orders-prod`. Block as a precursor to a protected deletion.

#### Applicable tools and systems

- AWS RDS / Aurora
- Google Cloud SQL / Spanner
- Azure SQL / Cosmos DB
- MongoDB Atlas
- Snowflake
- Databricks

#### Enforcement

Enable native deletion protection or locks and deny delete/protection-change permissions to the agent principal. Protect the identity that can remove the native guardrail with a separate approval path.

#### Exception / approval

A decommission workflow must verify dependency removal, recovery evidence, retention obligations and two-person authorisation; it runs outside the routine agent identity.

#### Test fixtures

- Should remain permitted: Describe configuration, create a restore drill in an approved sandbox or delete an explicitly ephemeral database instance.
- Should be blocked or held: Delete a protected instance, disable its deletion protection, remove its lock or perform the same action through an API alias.

#### Implementation references

- [AWS · Deleting an RDS DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html)
- [Google Cloud · Cloud SQL deletion protection](https://cloud.google.com/sql/docs/postgres/deletion-protection)
- [Microsoft · Lock Azure resources](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources)

### PD-03: Review high-blast-radius production mutations

- Severity: High
- Decision: Require approval
- Owner: Data owner

#### Policy statement

Hold production DELETE, UPDATE, MERGE and overwrite operations when impact is unbounded or exceeds the data owner’s configured row, partition or percentage threshold.

#### Covered operations

- DELETE or UPDATE without a selective predicate
- MERGE, overwrite or partition replacement
- Batch and repeated writes whose cumulative impact crosses a threshold

#### Evaluation rules

- Use a query plan, dry run or transaction-safe estimate to calculate affected rows/bytes/partitions; never execute the write to discover its impact.
- Hold statements without a predicate, with always-true predicates or with an unresolved estimate.
- Aggregate related requests by actor, target and time window so a large change cannot be split below the threshold.
- Bind approval to the query digest, resolved target set, estimated impact and short expiry.

#### Example decisions (illustrative; do not run against live systems)

- **SQL:** `UPDATE customers SET status='inactive'`. Hold because the statement is unbounded.
- **Snowflake:** `DELETE FROM events WHERE created_at < :cutoff`. Hold when the estimate exceeds the configured partition or row threshold.

#### Applicable tools and systems

- PostgreSQL
- MySQL
- Microsoft SQL Server
- Snowflake
- BigQuery
- Redshift
- Databricks SQL

#### Enforcement

Use a query gateway or controlled write role that can require an approved query digest. Apply statement timeouts, transaction controls and workload limits in the database as secondary safeguards.

#### Exception / approval

One approval for the exact target, statement digest and estimated impact. Require a fresh decision if the plan, parameters or affected-row estimate changes materially.

#### Test fixtures

- Should remain permitted: Update one synthetic record by immutable primary key within delegated authority.
- Should be blocked or held: Remove the predicate after approval, change the cutoff to include more partitions or split one mass update into repeated smaller requests.

#### Implementation references

- [PostgreSQL · Database privileges](https://www.postgresql.org/docs/current/ddl-priv.html)

### PD-04: Block degradation of production recovery controls

- Severity: Critical
- Decision: Block
- Owner: Resilience and recovery owner

#### Policy statement

Deny agent-initiated changes that disable backups, point-in-time recovery, versioning or deletion protection, or reduce retention below the approved recovery baseline.

#### Covered operations

- Disable automated backup or point-in-time recovery
- Reduce retention or delete protected recovery points
- Remove object versioning, immutability or recovery vault protection

#### Evaluation rules

- Resolve the protected resource and current approved RPO/RTO baseline before evaluating a configuration diff.
- Treat a sequence of individually small retention reductions as one change and deny the resulting non-compliant state.
- Protect backup copies and the controls governing them with an identity independent of the production workload and routine agent.

#### Example decisions (illustrative; do not run against live systems)

- **Azure SQL:** `Reduce long-term backup retention from 12 months to 0`. Block.
- **AWS RDS:** `Set BackupRetentionPeriod to 0 on a production DB`. Block.

#### Applicable tools and systems

- AWS RDS / Backup
- Google Cloud SQL / Backup and DR
- Azure SQL / Recovery Services
- MongoDB Atlas
- S3 / GCS / Azure Blob

#### Enforcement

Use separate backup accounts/projects, immutable storage and provider policy to deny destructive recovery changes. Alert the recovery owner on every blocked attempt.

#### Exception / approval

No routine exception. A documented retention change requires records, security and service-owner review through a separately privileged workflow.

#### Test fixtures

- Should remain permitted: Increase retention or create an additional protected recovery point.
- Should be blocked or held: Disable point-in-time recovery, reduce retention below policy or delete the only valid recovery copy.

#### Implementation references

- [AWS · Deleting an RDS DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html)
- [Microsoft · Lock Azure resources](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources)

### PD-05: Review unsafe production schema migrations

- Severity: High
- Decision: Require approval
- Owner: Service owner + database owner

#### Policy statement

Hold production schema changes that can destroy data, rewrite large tables, take blocking locks, remove compatibility or run outside the approved migration mechanism.

#### Covered operations

- DROP or destructive ALTER of a column, index or constraint
- Table rewrite, blocking index build or type conversion
- Migration execution outside the approved runner or release

#### Evaluation rules

- Evaluate the migration diff and database plan, including implicit locks, rewrites, cascades and rollback viability.
- Require expand/contract sequencing for compatibility-sensitive changes and a verified backup or rollback path.
- Bind approval to migration digest, release, database ID and maintenance window; edited migrations require new approval.

#### Example decisions (illustrative; do not run against live systems)

- **Flyway:** `ALTER TABLE orders DROP COLUMN legacy_total`. Hold for data-owner and service-owner review.
- **Prisma / ORM migration:** `Apply generated migration directly to production`. Hold when it bypasses the approved release runner.

#### Applicable tools and systems

- Flyway
- Liquibase
- Prisma
- Django migrations
- Rails migrations
- Terraform database providers
- Native database CLIs

#### Enforcement

Permit production DDL only to a controlled migration identity. Require plan artefacts, lock/impact checks and release approval in the deployment pipeline.

#### Exception / approval

Emergency execution requires the incident commander, database owner, captured command digest and confirmed recovery point; access expires after the incident action.

#### Test fixtures

- Should remain permitted: Generate and review a migration plan or apply a reversible migration in an isolated staging copy.
- Should be blocked or held: Apply a changed migration, bypass the release identity or run an unplanned destructive ALTER in production.

#### Implementation references

- [PostgreSQL · DROP TABLE](https://www.postgresql.org/docs/current/sql-droptable.html)

## Rollout checklist

- [ ] Inventory authoritative resource IDs, environments, classifications and owners.
- [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console.
- [ ] Put the hard deny or least-privilege boundary in the destination system.
- [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox.
- [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope.
- [ ] Observe matches, tune false positives and then enforce a bounded production scope.

Coverage: https://tracelet.ai/platform#coverage