AI agents and your data
Straight answers before you let AI agents near your data.
AI agents are most useful on real company data, and that is exactly where a mistake is expensive. These answers cover what security and data teams ask first: how agents should connect, what can leak, what can be injected, and how to prove what an agent saw. Each one starts with a short answer and separates general advice from what DBShifts does.
Getting started
What it means to give AI agents access to company data, and the shape of a safe setup.
What is an AI agent gateway?
An AI agent gateway is a control point between AI agents and the systems they read from. Instead of database credentials, each agent gets a scoped token. The gateway checks every request against your policy — which tables and columns, PII masking, volume limits — records it, and only then returns data.
Read the answer →How do I give AI agents access to my database safely?
Don't give the agent a connection string. Put a governed layer in between: a scoped, revocable token per agent, only the tables and columns it needs, PII masked on the server, limits on how much it can read, returned data scanned for prompt injection, and every request logged so you can see exactly what it accessed.
Read the answer →What is AI data governance?
AI data governance means controlling and proving what data AI systems can reach and what they did with it: which tables and columns, with sensitive values masked, within usage limits, with every access logged in a record auditors can trust. It applies the discipline of human data access to agents, assistants and AI features.
Read the answer →Should AI agents use RAG or query the database directly?
Use retrieval-augmented generation (RAG) for unstructured documents, and governed queries for live structured data. Embedding database rows into a vector store goes stale as rows change, cannot answer totals or joins reliably, and copies regulated data into a second system. Querying the source keeps answers current and data under existing controls.
Read the answer →Security
Where AI access to databases goes wrong: MCP tools, generated SQL, injected instructions, broad permissions.
Is it safe to connect an MCP server to a production database?
It depends on what the MCP server exposes. A server that offers a 'run SQL' tool backed by full credentials is only as safe as the model's choices. A safe setup uses a read-only user, structured tools instead of raw SQL, a token per client, server-side PII masking, volume limits and a log of every tool call.
Read the answer →Is text-to-SQL safe to run against a production database?
Not on its own. When a model writes raw SQL, the query can join anything, scan everything, bypass masking with SQL functions, or change data if the user allows it. Safer designs give the model structured tools — filter, aggregate, follow a real foreign key — and enforce allowlists, masking and limits on the server.
Read the answer →Can data in my database prompt-inject an AI agent?
Yes. It's called indirect prompt injection: text stored in a row — a support ticket, a review, a form field — that addresses the model, such as 'ignore previous instructions'. When an agent reads that row into its context, the model may obey it. Access controls decide which data an agent gets; they don't inspect what the data says.
Read the answer →What permissions should an AI agent have on a database?
Only what the task needs: read-only access, specific tables and columns with everything else denied, sensitive columns masked, rows scoped to the user or tenant it serves, capped volume per request and per day, a token that expires, and changes only through named actions a person approves.
Read the answer →Privacy and oversight
Keeping personal data away from models, proving what agents saw, and stopping one fast.
How do I stop AI agents from seeing customer PII?
Find the sensitive columns first, then mask them on the server before results leave your infrastructure, so neither the agent nor the AI provider receives raw values. Masking must also block filtering, grouping and joining on masked columns, or an agent can reconstruct a value from row counts without ever reading it.
Read the answer →How do I audit what data an AI agent accessed?
Log every agent request where the data is served, not inside the agent: which token, which tool, which table and columns, what was masked or refused, how many rows came back, and when. Make the record complete — including failed requests — tamper-evident and exportable, so you can answer what an agent saw.
Read the answer →How do I stop a misbehaving AI agent immediately?
Pause its access at the gateway rather than the database. A per-agent token that can be paused stops that one agent on its very next request, without rotating shared passwords or touching other agents. Add automatic quarantine on strong signals, such as reading a canary row or a burst of requests for data it was never allowed.
Read the answer →People, databases and networks
Each person's own permissions, one agent across several databases, and databases that stay inside your network.
How do I give each employee's AI assistant their own data permissions?
Don't give the assistant one shared credential. Have each person sign in from their own AI client, so the client receives a token bound to them, and work out what they may read from their own grants or identity-provider groups. Re-check that on every request, so removing someone ends their access at once, and log every read under their name.
Read the answer →Can one AI agent safely query several databases?
Yes, if each database keeps its own rules. Give the agent one endpoint that routes every call to the right database's gateway, so that database's allowlist, masking and limits still apply. Allow cross-database joins only along links you define, never on masked columns, and keep every read in the log of the database it came from.
Read the answer →How can AI agents reach a database that stays in my network?
Run a small process inside your network that connects out to the gateway, keeps the database credentials in its own configuration, and runs only the reads the gateway sends — refusing anything that is not a read on its own side. Nothing connects in, no database password leaves your network, and revoking its key stops it at once.
Read the answer →Agents working together
When agents call each other and their tools: what may cross, which tools they may use, and stopping a runaway chain.
How do I secure communication between AI agents (A2A)?
Route every agent-to-agent call through one control point. Allow only the pairs you choose, decide per pair what data may cross, carry the original user and every agent that acted in a signed token, and have each agent refuse calls that skipped the control point. Then log every hop, without the content.
Read the answer →How do I control which MCP tools an AI agent can call?
Put a policy point between the agent and the MCP server. Allow and deny tools per agent by name, check argument values before a call reaches the server, hide disallowed tools from the list the model sees, and scan tool descriptions and results for injected instructions. Answer refusals as tool errors so the model can adapt.
Read the answer →How do I stop AI agents from looping or running up costs?
Track the chain of calls each request sets off and limit it: how deep it goes, how often one agent is called again, how often a request repeats, how fast it fans out, its total calls and cost, and how long it runs. When a limit is crossed, stop the whole chain, not just one call.
Read the answer →Asking your data
Plain-English questions answered from real rows, without giving a model the keys.
Put a governed gateway between your agents and your data
Scoped tokens instead of credentials, PII masked on the server, every request audited.