Security & SQLShield
Security is the primary design goal of TernoDBI. When giving AI Agents access to databases, the risk of data exfiltration or destruction is high. TernoDBI mitigates this with a defense-in-depth approach.
1. SQLShield: The Query Firewall
SQLShield is our proprietary SQL validation engine. Unlike regex-based filters (which are easily
bypassed), SQLShield parses SQL into an Abstract Syntax Tree (AST) using sqlglot.
How it works
- Parsing: The incoming query is parsed into a structural representation.
- Analysis: The AST is traversed to check for forbidden node types.
- Transformation: The query is rewritten (e.g., adding
LIMITclauses) before execution.
Protections
- ReadOnly Enforcement: Rejects
INSERT,UPDATE,DELETE,DROP,ALTER,GRANT,TRUNCATE. - System Catalog Protection: Prevents access to
information_schemaorpg_catalogunless explicitly allowed. - Limit Enforcement: Automatically appends
LIMIT 100(or configurable max) to prevent DOS attacks via massive result sets.
2. Service Token Authentication
TernoDBI uses a custom implementation of API Key authentication (ServiceToken).
Token Types
- Query Token: Read-only access. Can be scoped to specific Datasources.
- Admin Token: Full access to the Admin API (Datasource creation, Metadata updates).
Scoping
Tokens can be restricted to specific Datasource IDs.
# Only allow access to Financial DB (ID: 5)
ternodbi manage issue_token --name "FinBot" --type query --datasource 5
Expiration
Tokens can be set to auto-expire.
# Valid for 24 hours
ternodbi manage issue_token --name "TempAccess" --expires 1
3. Best Practices
- Least Privilege: Always create database users (on Postgres/Snowflake) with
read-only permissions. Do not give TernoDBI a
rootoradminDB connection string. - Ephemeral Tokens: For chat sessions, generate a short-lived token per session.
- Network Isolation: Run TernoDBI in a private subnet, accessible only by your Agent infrastructure.