Security at the Core

dbward is designed so that database safety is the default, not an afterthought. Every architectural decision prioritizes preventing unauthorized access and ensuring accountability.

Security Principles

Credential Isolation

Only the agent process connects to your database. The CLI and server never see or store database credentials. Even if the server is compromised, your database credentials remain safe.

Fail-Closed by Default

If no workflow matches an operation, the request is rejected at creation — not queued, not allowed. Errors in authentication or policy evaluation result in denial. dbward always fails toward safety.

Cryptographic Execution Tokens

Every approved operation receives an Ed25519-signed token bound to the exact SQL content, target database, and a 5-minute expiry. The agent independently verifies this signature before executing anything. A tampered or expired token is rejected.

Tamper-Evident Audit

Every action — request, approval, execution, result — is recorded in a hash-chain audit log. Each entry includes a SHA-256 hash linking to the previous entry, making any modification or deletion detectable.

Zero-Trust Between Components

The agent does not blindly trust the server. It verifies execution tokens with the server's public key, recomputes the SQL content hash, and checks its own capability configuration before executing. Each boundary enforces its own authentication.

Architecture

Key insight: The server manages approval state but never touches your database. The agent executes but cannot approve. No single component has both authority and access. If the server is compromised, the attacker gains the signing key and could forge execution tokens — but only for databases the agent is configured to reach, limited by the agent's capability restrictions, and with a maximum 5-minute token validity window.

AI Agent Safety

Proposals are not permissions. When an AI assistant (via MCP) proposes a database operation, it enters the same approval workflow as any human request. The AI cannot bypass approval, cannot execute directly, and cannot escalate its own privileges.

• SQL Review (10 rules) checks for destructive operations, missing WHERE clauses, and schema risks
• Statement timeout prevents runaway queries
• Execution tokens are content-bound — changing the SQL invalidates the token
• Break-glass requires explicit human action with mandatory reason

Data Handling

• API tokens: Stored as SHA-256 hashes only. Plaintext is never persisted.
• SQL in webhooks: Literals are redacted (replaced with ?). If parsing fails, only the SHA-256 hash is sent.
• Query results: Sent from agent to server, stored in the configured result store (local or S3). Clients retrieve results via the server API. Results can be configured with retention days for automatic cleanup.
• Runs in your environment: dbward is self-hosted. No data leaves your infrastructure. No telemetry.

Failure Modes

Known Limitations

We believe transparency builds trust. These are current limitations we plan to address:

• SQLite at-rest: Not encrypted. Relies on filesystem permissions. Encrypted storage planned for a future release.
• Single-instance server: Horizontal scaling not yet supported. Suitable for teams up to ~100 concurrent users.
• Signing key: File-based Ed25519 key. KMS/HSM integration planned.

Responsible Disclosure

Found a vulnerability? Please report it via GitHub Private Vulnerability Reporting. Only you and the maintainers can see your report.

See our SECURITY.md for details on response timelines and disclosure policy.

Learn More

• Threat Model (STRIDE)
• Deployment Hardening Guide
• Pre-Deployment Checklist