Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/FloxTBoTyy/BoardPulse-AI/llms.txt

Use this file to discover all available pages before exploring further.

BoardPulse AI is not free-form database access. Before any SQL reaches your database, it passes through a validation layer that enforces a strict read-only policy, checks every table reference against your approved list, and rejects anything that could modify or expose data outside your defined scope. This guardrail runs on every request — there is no way to bypass it.

​
Read-only-first principle

The core rule is simple: only SELECT statements are permitted. BoardPulse AI will never write to, modify, or delete data in your source database. If the AI model generates a query that starts with anything other than SELECT, the request is rejected before execution with an HTTP 422 response. This is enforced at two levels:
  1. Keyword check — the normalized SQL is scanned for any forbidden keyword
  2. Statement type check — the query must begin with SELECT

​
Forbidden keywords

The following SQL keywords are blocked regardless of context. If any of them appear in a generated query, the request fails immediately: 
FORBIDDEN_KEYWORDS = {
    "INSERT",
    "UPDATE",
    "DELETE",
    "DROP",
    "ALTER",
    "TRUNCATE",
    "CREATE",
}
If the AI model generates SQL containing any forbidden keyword — even inside a subquery or comment — the entire request is rejected with HTTP 422 and a "Forbidden SQL operation detected" error. The query is never executed.

​
How validation works

BoardPulse AI uses SQLGlot to parse and validate SQL before execution. SQLGlot performs dialect-aware AST parsing, which is more reliable than simple string matching. The validation sequence for every query:
1

Parse

SQLGlot parses the raw SQL string into an AST. If the SQL is syntactically invalid, a ParseError is raised and the request returns HTTP 422.
2

Single-statement check

Only one SQL statement is allowed per request. Multi-statement queries (e.g., SELECT 1; DROP TABLE users) are rejected immediately.
3

SELECT-only check

The normalized query must start with SELECT. CTEs are accepted since they resolve to a SELECT.
4

Forbidden keyword scan

The full normalized SQL is checked for any keyword in FORBIDDEN_KEYWORDS.
5

Table allowlist check

SQLGlot walks the AST to extract every table reference. Any table not in your approved list causes a rejection that names the offending tables.
6

Normalized SQL returned

If all checks pass, the normalized (pretty-printed) SQL is returned and forwarded to the execution layer.

​
Table allowlisting

Only tables you explicitly approve can appear in queries. The allowlist is configured with the DEFAULT_SOURCE_INCLUDE_TABLES environment variable: 
DEFAULT_SOURCE_INCLUDE_TABLES=sales_orders,customers,products,invoices
If the AI generates a query that references a table outside this list, the request fails with HTTP 422 and a message like: 
SQL references tables outside the certified allowlist: raw_logs, system_audit
The table names in DEFAULT_SOURCE_INCLUDE_TABLES are matched case-insensitively. You do not need to worry about capitalization.

​
Execution safety limit

After validation, the query is wrapped with a configurable LIMIT before it runs. This prevents accidental full-table scans from returning millions of rows. The executed_sql field in the response always reflects the final query — including this limit — so you can see exactly what ran.

​
Error reference

ConditionHTTP statusDetail message
Invalid SQL syntax422Invalid SQL generated: <reason>
Multiple statements422Only a single SQL statement is allowed
Non-SELECT statement422Only SELECT statements are allowed
Forbidden keyword detected422Forbidden SQL operation detected
Table outside allowlist422SQL references tables outside the certified allowlist: <tables>

Build docs developers (and LLMs) love

Get started for freeTalk to us