Start here · How it works
How SignalPilot works
You ask a question in an AI tool. The tool asks SignalPilot. SignalPilot asks your database, checks what comes back, and hands the answer to the tool. That is the whole picture.
The important part is the middle. Your AI tool never talks to the database directly. Every request goes through SignalPilot, and SignalPilot does three things with each one:
- Checks it. Only read-only queries get through. Anything that would change or delete data is refused before it runs. Result sizes are capped, sensitive columns can be hidden, and tables you have blocked stay invisible.
- Applies your team's definitions. If your knowledge base says an "active customer" means a purchase in the last 90 days, that is what the AI uses, every time, in every tool.
- Keeps a record. Each query, who ran it, which tool it came from, and what the guardrails decided is written to an audit log you can read later.
Because all of this happens in SignalPilot rather than in the AI tool, it works the same whether the question comes from Claude, Claude Code, Cursor, ChatGPT, or something your team built.
Glossary
| Term | What it means |
|---|---|
| Gateway | The SignalPilot service that sits between AI tools and your databases. When the docs say "SignalPilot checks every request", the gateway is what does the checking. |
| MCP | Model Context Protocol, the open standard AI tools use to call outside services. SignalPilot is an MCP server, which is why so many tools can connect to it without special support. |
| Connection | A database or warehouse you have added to SignalPilot. Credentials are stored encrypted and never leave SignalPilot; the AI only ever sees results. |
| Connector | The reverse direction: an outside service (an issue tracker, a wiki) that SignalPilot's own chat can call. See Add MCP servers to chat. |
| Knowledge base | Your team's definitions, rules, and notes about the data. The AI reads them before answering so everyone gets the same numbers. |
| Governance | The set of checks applied to every query: read-only enforcement, row limits, blocked tables, hidden columns, budget caps. If a check cannot run, the query is refused rather than allowed through. |
| Audit log | The record of every request: when, who, which connection, what SQL, and what governance decided. Text values in the SQL are redacted so personal data does not end up in the log. |
| Plugin | An add-on for Claude Code and Codex that teaches the AI how to use SignalPilot well. It brings skills and verifier agents. |
| Skill | A short guide the AI follows for a specific kind of task, such as building a dbt model or writing SQL for a particular warehouse. Skills load automatically when the task matches. |
| Verifier agent | A check that runs after a build to confirm the result is right: row counts, duplicated rows, unexpected nulls, missing columns, and so on. It returns a report, not just pass or fail. |
| Eval | A saved set of questions with known answers, run against the AI to measure how often it gets them right. Useful for checking that a change to the knowledge base or a new model helped. |
| Project | A dbt project SignalPilot knows about, usually linked to a repository. Lets the AI understand how your models fit together and build new ones safely. |
For engineers
The gateway is a FastAPI service that exposes 62 MCP tools over the streamable HTTP transport at /mcp. The cloud endpoint is https://gateway.signalpilot.ai/mcp; a self-hosted gateway defaults to http://localhost:3300/mcp. Authentication is by API key (x-api-key header, or Authorization: Bearer), stored as a one-way hash. The Claude Code and Codex plugins add 24 skills and 2 verifier agents on top of the tools; other MCP clients get the tools alone. Governance is parse-time and fail-closed: DDL and DML are rejected, dangerous functions are denied, LIMIT is injected, multi-statement input is refused, and every decision is written to the audit log. Connection credentials are encrypted at rest.