Agent Gateway
The safe data door for AI agents.
Your AI agents need to read company data. Don't hand them raw database credentials — and don't hand-build a locked-down API for every one. Register a database, set a policy, give the agent a token. It reads only what you allow, with PII masked, rate-limited, and every query logged.
Raw DB credentials to an agent
It can read every customer's PII, run anything, with zero audit. No security team signs off on that.
A hand-built API per agent
Slow, brittle, and rewritten for every new agent and every schema change. There's no standard safe door — until now.
What it does
Scoped to exactly what you allow
Pick the tables and columns an agent may read. Everything else is invisible — no joins to off-limits data, no SELECT *, no surprises.
PII masked by default
We scan for emails, phone numbers, cards and SSNs on connect and mask them server-side. The agent gets useful data, never the raw secret.
Read-only by default — writes need a human
Reads can't mutate anything, by construction. Writes exist only as named, parameterized actions an agent may propose — nothing runs until you approve it, and executed actions carry a one-click undo.
Speaks MCP natively
Register the gateway as an MCP server and your agent gets list_tables, query_table, list_views, query_view and propose_action out of the box. Or call the plain REST endpoint.
Every query audited
Who asked for what, when, which columns were masked, and what was denied — a full activity log you can finally answer questions from.
No raw credentials
Agents authenticate with a scoped, revocable token — never your database password. Revoke one agent without touching the others.
Named views — you define what "customers" means
Expose curated slices under stable names: chosen columns, forced filters, a row cap. Agents query the view, not your raw tables — structured definitions, never SQL.
Approve from Slack
Write proposals land in your Slack channel with Approve / Reject buttons. Clicks are signature-verified and nonce-pinned — a forged or replayed click approves nothing.
Preview before you trust
The policy sandbox shows exactly what a token would see — table by table, column by column — before you issue it. Usage analytics show what each agent actually did.
Every agent write is diffable and revertible
Every approved write auto-commits onto a version-controlled history of the table — not just a single-action undo. Diff exactly what an agent changed against any earlier point, or revert further back than its last action.
How it works
Register a database
Connect read-only and we introspect the schema and scan for PII automatically.
Set the policy
Tick the tables and columns agents may read, set PII masking, row caps and rate limits.
Issue a token
Hand one agent a scoped agt_ token — over MCP or REST. Revoke it anytime.
Ship with confidence
The agent reads only what's allowed, masked and rate-limited, with every query logged.
Plug into any agent over MCP
Point your agent at the gateway's MCP endpoint with a scoped token. It gets eight tools — list_tables, query_table, aggregate_table, query_related, list_views, query_view, list_actions and propose_action — every one governed, masked and audited, and none of them accepting raw SQL.
{
"mcpServers": {
"support-copilot": {
"url": "https://dbshifts.com/api/v1/agent-gateways/mcp",
"headers": { "Authorization": "Bearer agt_..." }
}
}
}Setup guides by client:
MCP server by database:
Frequently asked questions
How do I give an AI agent access to my database safely?
Don't hand it credentials. Register the database with DBShifts Agent Gateway, choose which tables and columns are visible, and issue the agent a scoped, revocable token. The agent connects over MCP or REST and can only read what the policy allows — PII masked, row-capped, rate-limited, and every query logged.
What is an MCP server for a database?
MCP (Model Context Protocol) is the standard AI agents use to call tools. Agent Gateway exposes your database as a governed MCP server: the agent gets tools like list_tables, query_table, query_view and aggregate_table, and every call passes through your access policy, masking and audit log — instead of raw SQL against production.
Can an AI agent see or leak customer PII through the gateway?
No. On connect the gateway scans for emails, phone numbers, cards, SSNs and other sensitive columns, and masks them in the SQL layer — masking is enforced even in aggregates and joins, so a masked column can't be read, grouped on, or filtered into visibility. Agents never hold unmask rights.
Can the agent write to or delete data?
Reads are read-only by construction. Writes exist only as named, parameterized actions an agent may propose — a human approves each one (in the app or from Slack), execution is audited, and there's a one-click undo.
How do I stop an AI agent from extracting my whole database?
Layered limits: per-query row caps, per-minute rate limits, and cumulative usage budgets — daily query and row budgets per token, plus gateway-wide totals across all tokens. Tokens can also be IP-bound so a leaked token is useless off your network.
Which databases does Agent Gateway support?
MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, MariaDB, SQLite and more — the same engines DBShifts migrates. One gateway policy model across all of them.
Can I undo everything an AI agent changed, not just its last write?
Yes. Every approved agent write auto-commits onto a version-controlled history of the table it touched, separate from the built-in one-click undo on a single action. Diff any two points in that history to see exactly what an agent changed, or check out an earlier commit to see the table before the agent ever touched it.
What is AI data governance?
AI data governance means controlling and auditing exactly what data an AI system can reach — which tables and columns, with PII masked, usage capped, and every query and write logged. Agent Gateway is DBShifts' implementation of it: register a database, set the policy once, and every agent connection is governed automatically instead of trusted with raw credentials.
Is it safe to give ChatGPT or Claude access to my database?
Not directly — handing an assistant a connection string gives it everything: every customer record, every column, with no audit trail and no way to revoke one agent without rotating the password for all of them. The safe pattern is a governed gateway in between: the model gets a scoped, revocable token instead of credentials, sees only the tables and columns you allow, gets PII masked before results leave your server, and every query is logged. Reads can't mutate anything, and writes require a human approval.
How do I stop an AI agent from seeing customer PII?
Scan first, then mask server-side. On connect, the gateway detects emails, phone numbers, cards, SSNs and similar columns, and masks them in the SQL layer — before results ever reach the agent or the model provider. Masking holds inside aggregates and joins too, so a masked column can't be grouped, filtered, or joined back into visibility. Agents never hold unmask rights.
Is text-to-SQL safe to run against a production database?
Letting a model author raw SQL against production is the risky part — a generated query can join to anything, scan everything, or mutate data. Agent Gateway doesn't accept raw SQL at all. Agents call structured tools (filters, projection, named aggregates, single-hop joins along real foreign keys), so the query shape is bounded by construction rather than by hoping the model behaves. Row caps, rate limits and usage budgets bound the volume on top.
What guardrails should an AI agent have before it touches production data?
Five that matter: least-privilege scope (explicit table and column allowlists, default-deny), PII masking enforced server-side rather than by prompt, hard limits (row caps, rate limits, cumulative usage budgets) so nothing can quietly page out the whole database, credentials the agent never holds (scoped revocable tokens, optionally IP-bound and time-windowed), and a complete audit log you can replay. Agent Gateway provides all five as configuration rather than code you have to write per agent.
Should I use RAG or give the agent direct database access?
RAG suits unstructured documents. For live relational data it's a poor fit — embeddings go stale the moment a row changes, aggregates and joins can't be answered from retrieved chunks, and you end up duplicating regulated data into a vector store. Querying the source through a governed gateway keeps answers current and keeps the data where your access controls already are. The governance question doesn't disappear either way, which is what the gateway solves.
Further reading
How we think about agent access, and the failure modes we found in our own gateway.
Your PII masking is decorative if the column is still filterable
An agent never has to read a masked column to steal it. Row counts alone reconstruct the value.
Read the post →Rate limits won't catch an agent reading your whole table
200 rows a day for 90 days sits under every limit you have — and takes the entire table.
Read the post →Ship agents without betting the database on them.
Free to start — no card. Read-only, masked, rate-limited, fully audited.