AI Agent Gateway
The AI agent gateway for your database.
The safe data door for AI agents. Your 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, rows scanned for prompt injection, and every query logged — and one click stops it.
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.
Each person signs in with their own access
Give people the gateway's MCP URL instead of a shared token. An MCP client that supports sign-in (OAuth 2.1 with PKCE) gets a token bound to that person: the owner's policy, the scope you set for them, or their identity-provider group's — checked again on every call.
Search for RAG, governed
Full-text search on PostgreSQL and MySQL, or nearest-neighbour search on a pgvector column. Results pass the same masking, row filters, budgets and injection shield as any read, and a masked column can never be searched.
Share data, not the database
Send a partner or auditor a link to chosen views and metrics. It expires, can require a passcode and can be revoked; they need no account, and every read is logged with a receipt.
Several databases, one endpoint
Group gateways into a federation: one MCP endpoint and token, each database still under its own policy and log. Joins across databases only follow links you define — never on a masked column.
Keep the database in your network
Run a data plane next to your database. It connects out, keeps the credentials, and refuses anything but reads on its own side — DBShifts never holds the database password.
When an agent goes wrong
Access rules decide what an agent may read. These are for the day it reads something hostile, starts probing, or you need it stopped — and for changing the rules without breaking the agents that follow them.
Prompt-injection shield
Rows are untrusted input. Every value an agent reads is scanned for instructions aimed at a model, chat-role markup, tool-call syntax, hidden Unicode and auto-loading image links. Flag (the default, data unchanged), sanitize the matched span, or withhold the value. Deterministic — no model, same verdict every time — and the audit log records counts, never the text.
How it works →Kill switch
Pause one agent's token from the Live view or the token list. Its next request is refused — tokens are checked on every request, no cache — and every per-user token it delegated stops with it. The token keeps its scope and history; resume is one click.
Pause versus revoke →Auto-quarantine
Opt in, and the gateway pauses a token by itself when it reads a canary row or hits a burst of policy denials in a window you set — the usual sign of a hijacked prompt. Rate limits and budgets don't count: busy is not the same as steered. An anomaly webhook tells whoever is on call.
Policy impact preview
Before you save a tighter policy, replay up to 50,000 recorded agent requests from the last day, week or month against it. Per agent: what would be blocked, narrowed, masked, exposed or cut by the row cap. Nothing saved, database never queried — and what can't be known is labelled, not guessed.
What it can and can't tell you →Live view
Every agent talking to the gateway, what it reads, where time goes and where it fails — computed from the audit log itself, never a second counter, with exact nearest-rank percentiles. It shows when a token was last seen, because MCP over HTTP has no “connected” state.
Why one source of truth →Signed access ledger
Every access is hash-chained, and signed anchors you export and keep let you prove later that the history they cover was not altered or trimmed. An access report lists what each agent touched, with a CSV export for auditors.
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 26 tools — list_tables, query_table, list_views, query_view, aggregate_table, list_search_indexes, search, list_metrics, query_metric, query_related, submit_job, get_job, list_jobs, cancel_job, list_feeds, subscribe_changes, poll_changes, unsubscribe_changes, list_history, diff_history, query_at_commit, request_access, list_access_requests, list_actions, propose_action and propose_action_plan — every one governed, masked and audited, and none of them accepting raw SQL.
| list_tables | List the tables and columns this token is allowed to read. Masked columns are reported as masked. |
| query_table | Structured read with filters, projection and a row cap. No raw SQL is ever accepted. |
| list_views | Curated named views the owner defined — chosen columns, forced filters, own row cap. |
| query_view | Query a named view. View filters are forced; the agent cannot widen them. |
| aggregate_table | Grouped count/sum/avg/min/max. Masking is enforced at the aggregate level, so a masked column can't be grouped into visibility. On a privacy-protected table the totals carry calibrated noise. |
| list_search_indexes | The search indexes the owner defined for retrieval: full-text over chosen text columns, or nearest-neighbour over a pgvector column. |
| search | The rows that best match a query (or an embedding), ranked. Masked columns are never searched; row filters, masking, the injection shield and receipts apply. |
| list_metrics | The business metrics the owner defined — revenue, active customers — each with its exact definition and the dimensions it may be cut by. |
| query_metric | Compute a metric by name with the owner's definition. The agent groups and filters only on the allowed dimensions and cannot drop the definition's filters. |
| query_related | Single-hop join, only along a real foreign key the schema actually declares. Both sides are policy-checked and masked. |
| submit_job | Run a heavier aggregate, metric or column profile in the background under the owner's job time limit, when the owner has enabled jobs. Returns a job id at once; the same rules apply as to the interactive tools. |
| get_job | A job's status, and its result once it has finished. Only the token that submitted the job can read the result. |
| list_jobs | This token's recent jobs and their status. |
| cancel_job | Cancel a queued or running job. |
| list_feeds | Tables the owner opened a change feed on, and this token's subscriptions. |
| subscribe_changes | Subscribe to a table's changes, from now or from the beginning, with the same column and filter rules as query_table. |
| poll_changes | Rows inserted or updated since the last poll, oldest first, masked like any read. Can wait up to 25 seconds for new rows. Deletes are not delivered. |
| unsubscribe_changes | End a change-feed subscription. |
| list_history | The commits for a table — the points in time it can be read at. Approved agent writes are committed here too. |
| diff_history | What changed between two commits: rows added, removed and changed, with a sample. Masked columns stay masked in the sample. |
| query_at_commit | Read a table as it stood at a commit. History is not a way around a mask: the allowlist, column rules and masking apply as they stand now. |
| request_access | Ask the owner for temporary access to a table the token can't read, with a reason. A person decides; masked columns stay masked even when access is granted. |
| list_access_requests | This token's access requests and whether each is pending, granted (with its expiry), refused or expired. |
| list_actions | Named write actions the owner defined. Listing them does not run anything. |
| propose_action | Propose a governed write. A human approves it in-app or from Slack before it executes. |
| propose_action_plan | Propose several writes as ONE approval. Steps run in order and stop at the first failure — not a single transaction, so the important write goes first. |
{
"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
What is an AI agent gateway?
An AI agent gateway is the single door AI agents use to reach your data, enforcing your rules on every request instead of trusting each agent to behave. DBShifts Agent Gateway does it for databases: agents connect over MCP or REST with a scoped, revocable token, call structured tools rather than writing SQL, and every call passes allowlists, PII masking, row caps, rate limits, usage budgets and a prompt-injection scan before it is answered and logged.
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.
How does the gateway handle prompt injection hidden in database rows?
It treats rows as untrusted input. Before results reach the agent, every text value — including strings inside JSON columns — is checked for instructions addressed to a model, chat-template role tags, tool-call syntax, invisible Unicode and remote image links that would leak data when a chat UI loads them. In the default flag mode the data is delivered unchanged and the agent gets a warning before the rows; sanitize removes the matched span; withhold replaces the value. Detection is rule-based, so it covers known shapes of attack, not every possible phrasing.
What happens when I pause an agent token?
Its next request is refused with a 403, logged with the reason. Tokens are read from the database on every request, so there is no delay while a cache expires, and any per-user tokens the agent delegated stop with it. Unlike a revoke, a pause keeps the token's scope, budgets and history, so resuming takes one click and the agent's configuration does not change.
Can I see what a policy change would break before I save it?
Yes. Preview impact replays up to 50,000 recorded agent requests from the last 24 hours, 7 days or 30 days against the unsaved policy, using the same rules the live gateway enforces, and reports per agent what would be blocked, narrowed, masked, exposed or truncated. Row-filter changes are reported as 'results may change' rather than a guessed count, and budgets are not simulated because they depend on running totals.
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. When the text an agent needs already lives in the database, the gateway's search indexes retrieve it in place — full-text on PostgreSQL and MySQL, or pgvector — under the same masking and limits as every other read.
Can each employee's AI assistant read with their own permissions?
Yes. Each gateway has its own MCP URL that MCP clients can sign in to with OAuth 2.1. The token they get is bound to that person and that gateway: the owner gets the gateway policy, a person you listed by email gets the scope you set, and anyone else gets the first matching rule for their identity-provider group — or nothing. It is checked again on every request, and reads are logged under their email.
Can one AI agent query several databases?
Yes, through a federation: several of your gateways behind one MCP endpoint and one token. Every tool takes a source and runs through that database's own policy, masking and audit log, and query_linked joins two databases only along links you defined, never on a masked column.
Can the database stay inside my network?
Yes. Run a DBShifts data plane next to it: a small process that connects out over HTTPS, keeps the database credentials in its own config, and runs only the reads a gateway sends — it refuses anything else itself and uses read-only transactions on PostgreSQL and MySQL. Nothing connects in, and DBShifts stores no password for that database. The rows an agent is allowed to read still travel to the gateway, which masks them before the agent sees them.
How do I share data with a partner without giving them database access?
Create a share link on the gateway for the views and metrics they need. The link expires after 1 to 90 days, can require a passcode, and can be revoked at any time. The partner needs no account; what they read passes the gateway's masking, row filters and limits, is logged, and carries a receipt they can verify.
Questions teams ask before connecting an agent
Short, straight answers. See all 18.
Further reading
How we think about agent access, and the failure modes we found in our own gateway.
Your Database Rows Can Prompt-Inject Your AI Agent
A support ticket that says “ignore previous instructions” is harmless in a table and an attack the moment an agent reads it into its context. Allowlists and masking never look at what the data says.
Read the post →Stopping an AI Agent Should Take One Click, Not a Password Rotation
When an agent starts doing something it shouldn't, the usual off switch is rotating the database password, which stops every other consumer too. A pause should hit one agent, on its next request, and be undoable.
Read the post →Find Out What a Policy Change Breaks Before Your Agents Do
Tightening an AI agent's access is easy to type and hard to predict. Replaying last week's recorded requests against the new policy turns “what breaks?” from a guess into a list.
Read the post →Your AI Agent Dashboard Should Agree With Your Audit Log
A live view of agent traffic that keeps its own counters will eventually disagree with the audit log, and then nobody trusts either. Ours computes every number from the log itself.
Read the post →Your PII Masking Is Decorative If the Column Is Still Filterable
An AI agent never has to read a masked column to steal it. If it can put that column in a WHERE clause, row counts alone reconstruct the value character by character — and every audit line says the system worked.
Read the post →Rate Limits Won't Catch an AI Agent Reading Your Whole Table
An agent re-reading the same 50 rows a thousand times is harmless. One reading 50 new rows a thousand times has taken your table. Every volume dashboard shows them as identical.
Read the post →Ship agents without betting the database on them.
Free to start — no card. Read-only, masked, rate-limited, fully audited.