Read-Only Query Enforcement
ReadSentinel uses ANTLR-based SQL parsers to analyze every query at the application layer. This is fundamentally different from relying on database user permissions — even if the DB user has write access, the application blocks any non-SELECT statement.
- Oracle: PL/SQL parser blocks INSERT, UPDATE, DELETE, MERGE, EXEC, anonymous blocks, and user-defined function calls with potential side effects
- PostgreSQL: Parser blocks DML, DDL, CALL, EXECUTE, DO blocks, and user-defined functions
- MySQL: Parser blocks DML, DDL, CALL, prepared statements, administrative commands, and UDF calls
- MongoDB: Filter validation blocks write operators ($set, $unset, $inc), JavaScript execution ($where, $function), and aggregation write stages ($out, $merge)
Built-in functions like NVL(), COUNT(), TO_CHAR() are whitelisted. User-defined functions that could have side effects (e.g., Oracle's PRAGMA AUTONOMOUS_TRANSACTION) are blocked.
Full Audit Trail
Every query execution is logged to a separate audit database with complete details:
- Who executed the query (user email, role)
- Which connection was used
- The full SQL text
- Execution time and row count
- Success, rejected, timeout, or error status
- Timestamp with millisecond precision
The audit log is append-only, stored in a separate SQLite database, and accessible via the admin panel with date/user/status filters. Ideal for SOX compliance, GDPR audit requirements, and HIPAA access logging.
Role-Based Access Control (RBAC)
Control exactly which database connections each team member can access:
- Create roles (e.g., "Support", "Engineering", "Auditors")
- Assign connections to roles — support sees customer DB, not billing
- Assign users to roles — a user can have multiple roles
- Admin users manage everything; regular users only query
Different departments can install separate instances for isolation, or share one instance with role-based separation.
AES-256 Encrypted Credentials
Database connection strings are encrypted at rest using AES-256-GCM. They are never returned via the API — not even to admin users. Team members execute queries against connections without ever seeing passwords, hostnames, or ports.
The encryption key is stored as an environment variable on the server, separate from the database file.
Query Timeouts & Row Limits
Protect production databases from long-running or resource-consuming queries:
- Configurable timeout per connection (up to 120 seconds)
- Server-side cancellation — the query is killed on the database, not just abandoned
- Row limit enforcement to prevent massive result sets
- Ctrl+Space validation: check if a query is valid without executing it (EXPLAIN-based)
Self-Hosted Deployment
ReadSentinel runs entirely within your infrastructure:
- API: .NET 10 application — deploy on IIS or Docker
- Client: Flutter Windows desktop application (macOS and Linux coming soon)
- Data: SQLite control plane — no external database required for ReadSentinel itself
- Network: Your data never leaves your network. No cloud dependency for core functionality.
How ReadSentinel Compares
| Feature | ReadSentinel | DBeaver / DataGrip | DB Permissions Only |
|---|---|---|---|
| Blocks writes at application layer | ✓ | ✗ | ✗ |
| Blocks stored procedures / functions | ✓ | ✗ | Partial |
| Full query audit trail | ✓ | ✗ | Varies |
| Encrypted credential storage | ✓ | ✗ (stored locally) | N/A |
| Role-based connection access | ✓ | ✗ | ✗ |
| Team members never see passwords | ✓ | ✗ | ✗ |
| Self-hosted / air-gapped | ✓ | ✓ | ✓ |