Security overview

Hyperterse is designed with security as a baseline. This section covers the security model and best practices for production deployments.

Security features

Feature	Description
Credential Protection	Connection strings never exposed in API responses
Input Validation	All inputs validated and typed before execution
SQL Injection Prevention	Template substitution with proper escaping
Error Sanitization	Internal errors never leaked to clients
Declarative Access	Only defined queries can be executed

How it works

1
┌────────────────┐              ┌─────────────────────┐
2
│     Client     │              │     Hyperterse      │
3
│  (REST/MCP)    │───Request───▶│                     │
4
│                │              │  ┌───────────────┐  │
5
│ Cannot access: │              │  │ Input         │  │
6
│ - SQL queries  │              │  │ Validation    │  │
7
│ - Credentials  │              │  └───────┬───────┘  │
8
│ - Schema       │              │          │          │
9
└────────────────┘              │  ┌───────▼───────┐  │
10
                                │  │ Query         │  │
11
                                │  │ Execution     │  │
12
                                │  └───────────────┘  │
13
                                │                     │
14
                                │  Connection strings │
15
                                │  never leave here   │
16
                                └─────────────────────┘

Security guides

Connection security

Protect credentials and database connections.

Production hardening

Best practices for production deployments.

What’s protected

Connection strings

Connection strings are stored in the Hyperterse configuration and never exposed:

Not in API responses
Not in OpenAPI documentation
Not in MCP tool descriptions
Not in error messages
Not in generated llms.txt

SQL statements

Raw SQL is also protected:

Clients call named queries, not SQL
Query statements are not exposed in API responses
Only validated inputs are substituted

Schema information

Database schema stays hidden:

Table names not exposed
Column names only visible if returned in results
Database errors are wrapped

What clients can see

Clients can access:

Query names and descriptions
Input parameter names, types, and descriptions
Output field names (if defined in data section)
Query results

Limitations

Hyperterse provides application-layer security. You still need:

Network security — Firewalls, VPCs, etc.
Authentication — User identity verification
Authorization — Access control per user/role
Rate limiting — Request throttling
TLS/SSL — Transport encryption

For production, place Hyperterse behind a reverse proxy that handles these concerns.