Text-to-SQL has dominated the conversation around AI and databases. Getting an AI agent to generate correct SQL from natural language is a hard problem. But it's only half the story.
Imagine that problem is solved: your AI agent has a well-curated semantic layer and consistently crafts accurate SQL. But can that agent only see the data it's supposed to see?
A customer support agent is asked "Show me billing details for user #123." It generates correct SQL â joining users, billing, and payments â but the result includes the user's unmasked SSN from the users table. The SQL was accurate. The data leak happened anyway.
Generating correct SQL and governing data access are separate problems:
| Problem 1: Accuracy | Problem 2: Governance | |
|---|---|---|
| Question | Is the SQL correct? | Can the agent see this data? |
| Domain | AI / Text-to-SQL | Security / Access Control |
| Failure mode | Wrong query results | Data leak with correct results |
| Example | SELECT * FROM uesrs (typo) | Agent returns unmasked SSN from users table |
Without governance, correct SQL becomes a liability.
Same Governance Fundamentals as Human Access
Agents need the same controls as any human user querying your databases:
-
Access Control. Least privilege â scoped to only the databases, schemas, and tables the agent needs. A sales analytics agent has no business touching
hr.payroll. -
Data Masking. Sensitive columns â SSNs, credit cards, health records â should be dynamically masked before results reach the agent. If a human analyst sees
***-**-1234, so should the agent. -
Audit Logging. Every query recorded â what, when, by which agent, on behalf of which user. When something goes wrong, the audit trail is how you trace it.
The stakes are higher with agents â a misconfigured agent can exfiltrate more data in seconds than a human could in hours.
What's Different About Agents
Same principles, different operational model.
Agents Are Ephemeral
An agent spins up, executes a task, and disappears â often in seconds. Provisioning a database account and leaving it active for months is a poor fit. Agents need credentials scoped to a single task and revoked immediately after.
Each Agent Needs Its Own Identity
When multiple agents share a single database user account, you lose all visibility into who did what. Each agent type should have a distinct identity with its own access policy, so that access control and audit logging remain meaningful.
Just-in-Time Access Becomes the Default
For human users, just-in-time (JIT) database access is a best practice. For agents, it's the natural model â spin up, query, return results, done. No reason to hold database access before or after the task. JIT becomes less of a security upgrade and more of a default architecture.
Govern Agent Access with Bytebase
Bytebase provides a unified governance layer for AI agents across PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, BigQuery, and more.
Governance infrastructure built in:
- Fine-grained access control at the database, schema, and table level
- Dynamic data masking applied at the column level
- Just-in-time access that grants and revokes permissions per task
- Audit logging with full agent and user attribution
Agent identity is a first-class concept. Bytebase supports service accounts and workload identities so each agent operates under its own access policy. Connect via the Bytebase MCP server, or call the API to build custom agentic workflows with governance baked in.
