The agent never holds a credential
Datasource passwords and tokens are encrypted at rest and never returned — not through a tool, not through the UI, not in a pipeline's JSON. Pipelines reference datasources by name; the server connects.
For the person who has to say yes
Letting an AI agent near your databases, without handing it a password
The usual way to connect an agent to a database is a connection string on a laptop — one credential, every privilege that credential has, no record of what the agent did with it. datapipelines is built so that shape cannot occur: the agent holds a key to this server, the server holds the credentials, every action is scoped, audited, and — for anything that reaches production — released by a person.
The trust model
Five boundaries, each enforced by the server, not by a prompt
One key, a scope, a workspace
An agent's key carries a scope — read, execute, author — and is pinned to one workspace. Every tool and every REST route declares the scope it needs; the matrix is a spec, and a test keeps the code equal to it.
Read-only where you say so
Mark a datasource readonly and every write-shaped node against it is refused when the pipeline is saved, and again when it runs — two checks, so a flag flipped between them cannot ship a write.
Agents leave drafts; people release
No tool releases a version. A draft is runnable — that is how an agent tests its work — but what an endpoint serves and what promotion carries is a version a person locked. A release is immutable; a discarded one is restorable.
Everything is audited
Every MCP call, every lifecycle verb, every endpoint serve: who, through which surface (session, API key, MCP), on what, with the outcome. Never the SQL text, the row data or the parameter values — those are yours.
Secured by default, public by allowlist
Every route requires a credential unless it is on an enumerated public list with a written reason — the marketing site, the docs, the health probe. A route that is not on the list is not public. A test freezes the list.
Keys, precisely
What a key can reach is a property of the key, not of the caller
A key holds a scope, and a scope is a row in a matrix that names every operation it permits: listing and
reading pipelines and schemas under read; running them under execute; creating
and editing drafts, probing a SELECT, registering lake tables under author. The
matrix is the authority — the MCP server and the REST API are two adapters over it — and the scope every
tool requires is printed beside it in the tool list.
A second kind of key exists for published endpoints: bound to a path prefix under /api/x, it can
call that subtree and nothing else. That is the key you give a partner, a workbook or a service — one per
contract, revocable by the person who owns it, useless anywhere but the paths it was bound to.
Keys are owned by people, pinned to a workspace, and can be revoked; validation checks the key, its expiry and its owner's status on every request. Revoking one person's key never touches another's — the reason keys, not shared passwords, are the only way in for programs.
Blast radius
What a runaway agent can and cannot do
An agent that writes a bad query gets a bounded failure, not an outage: every statement carries a query timeout, every run an overall deadline, and every instance a ceiling on concurrent executions. A statement that outlives its budget is cancelled at the driver and the node fails with the budget it blew and the time it took. Staging memory is capped per run. A slow query is the agent's problem to fix from the plan the SQL probe returns, never the database's problem to survive.
An agent that tries to write where it should not is refused before the write, by the read-only flag on the datasource and by the scope on its key. An agent that tries to release or promote finds no tool for it — it can publish an endpoint, but only over a version a person already released. An agent that tries to read a credential finds none in any response.
And whatever it did, the audit log says so — by key, by tool, by outcome — so the question after an incident is a query, not an investigation.
Operating it
Your infrastructure, your keys, your logs
Encryption keys you control
Datasource credentials are encrypted with a master key the server reads from its environment — never from the database it protects; the key-provider contract is written for a KMS, with AWS KMS as the worked recipe, so the master key can live where your other secrets do.
Your identity provider
People sign in through OIDC — Google, Microsoft, Okta, Keycloak, any compliant provider — or through local accounts when you choose; there is no datapipelines account to create anywhere.
Open source, self-hosted
AGPL-3.0. The server runs on your machines; the code that handles your credentials is code you can read. No data leaves your network unless a pipeline you released sends it somewhere.
If you find a hole
Report a vulnerability
Email datapipelines.co@gmail.com directly — the address reaches the owner, and the code you read is the code that runs.
Asked before
Security questions, answered plainly
Does my agent get my database password?
No. The agent holds an API key to datapipelines; the server holds the datasource credentials, encrypted at rest, and never returns them — not through a tool, not through the UI. A datasource can be marked read-only so write-shaped nodes are refused at save time. Credential storage is docs/datasources.md §7 and the read-only flag docs/datasources.md §3.
How is this different from a Postgres MCP server?
A single-database MCP server gives one agent one database and usually one connection string on a laptop. This gives the agent all of your databases through one scoped key, a scratch engine to join their results, versioned drafts a person reviews, an audit trail per call, and an HTTP API for what it builds. Every tool is specified in docs/mcp-server.md §6.2.
What can an agent do, and what can it never do?
It can read schemas, catalogue statistics and indexes, probe a SELECT, create and iterate a draft pipeline, run it, read the result, and cancel its own runs. It can never release a version, never read a credential, and never touch a datasource marked read-only with a write. Scopes are per key and the matrix is docs/auth.md §7.6.
Is every agent action logged?
Yes. Every MCP tool call is written to the audit log with the key that made it and the tool — never the SQL text, row data or parameter values, which are your data; every lifecycle verb records who did it and through which surface (session, API key or MCP). The audit log is docs/auth.md §10 and the MCP events docs/mcp-server.md §10.
Can an agent release a pipeline to production?
No, by design. Agents create and iterate drafts; a person releases. A released version is immutable — a later edit becomes a new draft — and a published endpoint serves the version you point it at. The lifecycle is docs/versioning.md §3.