ENTERPRISE SAFETY & SECURITY

DBAnchor Safety & Security Model

How DBAnchor enforces Zero Data Loss in production, protects sensitive credentials, and operates in 100% offline environments.

1. Zero Data Loss First Philosophy

In modern web engineering, a minor mistake in a migration file (such as an accidental DROP COLUMN or table rename) can permanently destroy data within milliseconds.

DBAnchor treats safety as an invariant rather than an optional configuration flag. Every migration and DDL command passed through DBAnchor is evaluated against our strict risk classification engine before execution.

2. Comprehensive DDL Risk Taxonomy

Every SQL operation is categorized into one of four deterministic risk tiers:

Operation Risk Tier Development Production Policy
CREATE TABLE LOW Allowed Allowed automatically
ADD COLUMN (nullable) LOW Allowed Allowed automatically
ADD COLUMN (NOT NULL with default) MEDIUM Allowed Warning: locks table on older Postgres
CREATE INDEX CONCURRENTLY MEDIUM Allowed Allowed with transaction notice
DROP COLUMN HIGH Warning BLOCKED (Requires override)
DROP TABLE CRITICAL Warning BLOCKED (Requires override)
TRUNCATE TABLE CRITICAL Warning BLOCKED (Requires override)
DROP SCHEMA CASCADE CRITICAL Warning BLOCKED (Requires override)

3. AST-Level SQL Analysis

DBAnchor does not rely on naive regex string matching, which can be easily bypassed by comments, multi-line formatting, or nested subqueries. Instead, DBAnchor leverages a deterministic SQL Abstract Syntax Tree (AST) parser to inspect the structural intent of every statement:

AST Gate Example 
-- DBAnchor AST tokenizes statement:
ALTER TABLE "public"."users" DROP COLUMN "phone_number";

-- AST Node Identified:
{
  "statement_type": "ALTER_TABLE",
  "target_table": "public.users",
  "action": "DROP_COLUMN",
  "target_column": "phone_number",
  "risk_classification": "HIGH",
  "action_decision": "BLOCK_IN_PRODUCTION"
}

4. Environment Classification (APP_ENV)

DBAnchor determines its safety profile from standard environment variables:

  • APP_ENV=production or ENVIRONMENT=prod: Strict safety gates enabled. All High and Critical operations are blocked by default.
  • APP_ENV=staging: Strict warnings emitted with dry-run verification required.
  • APP_ENV=development or APP_ENV=local: Permissive execution with informative warnings.
  • APP_ENV=test: Fast execution mode for test harnesses.

5. Zero Credential Leaks Guarantee

Database connection URLs contain raw plaintext passwords, authentication tokens, and private hostnames. DBAnchor contains an automated redaction engine active across all output layers:

Terminal Logs & Tables

All URI passwords appear as postgresql://postgres:***@db.host:5432/app.

Stack Traces & JSON Exports

Exception frames sanitize raw DSN strings prior to printing or writing to JSON reports.

6. 100% Offline & Deterministic Architecture

Enterprise security compliance requires that database schemas and query patterns are never sent to third-party endpoints. DBAnchor adheres to strict architectural boundaries:

Zero External AI / LLM Calls: DBAnchor contains no external OpenAI, Anthropic, or proprietary AI API dependencies. All diagnostic heuristics and error translations run 100% locally in your Python process.
Zero Outbound Telemetry: DBAnchor never collects, phones home, or transmits your SQL statements, table structures, record counts, or database payloads.

7. Emergency Override Protocol

When an intentionally destructive migration must be applied to production (e.g. dropping a deprecated column after a zero-downtime deprecation cycle), DBAnchor requires an explicit command-line override:

Explicit Override Flag 
$ dbx migrate --force-destructive
[WARNING] Explicit override supplied.
Applying 1 high-risk migration: 7b84c19d (drop_legacy_tokens)
✓ Migration complete.

8. Vulnerability Reporting

If you discover a security vulnerability or bypass in DBAnchor's safety gates, please report it privately. Do not open a public GitHub issue for sensitive security disclosures.

Please send security reports directly to: calgebrity@gmail.com.

Reports will be acknowledged within 48 hours, followed by coordinated patch releases under Apache License 2.0.