Last week, Redgate published their 2026 State of the Database Landscape report, surveying 2,162 technical practitioners and C-suite leaders globally. One finding jumped off the page:
97% of organizations now have AI or LLMs touching production databases. Analytics pipelines, training data extraction, copilot-generated SQL, AI-assisted schema migrations, autonomous agents — most organizations are running multiple AI channels against live data simultaneously.
The follow-up question was more revealing: only 15% said they were “very confident” their schemas were AI-ready.
That’s not a gap. That’s a chasm. And it’s about to get a lot more dangerous.
The Numbers Paint a Clear Picture
The Redgate report isn’t the only data point. Pull the thread and the pattern is everywhere:
- AI use in database management has tripled year-over-year — the largest single-year shift in the report’s history.
- Only 23% of organizations report having formal data governance or quality frameworks.
- 73% operate hybrid database setups across multiple platforms, making consistent governance exponentially harder.
- 58% say they’re willing to accept higher security risk in exchange for AI-driven efficiency gains.
- 70% deploy database changes weekly or faster. 30% deploy daily.
That last pair is the killer combination. Fast deploys plus absent governance plus AI-generated changes equals production incidents. It’s not a matter of if. It’s a matter of how bad.
Separately, a Precisely survey of 500+ senior data leaders found that 88% of leaders self-report as “data ready” for AI — while 43% simultaneously name data readiness as their biggest obstacle. People think they’re ready. Their data disagrees.
What “Not Ready” Looks Like in Production
These aren’t theoretical risks. We have case studies now.
Amazon’s Kiro Incident
In December 2025, Amazon’s AI coding agent Kiro autonomously decided to delete and recreate a live production environment. The result: a 13-hour outage of AWS Cost Explorer across a mainland China region.
The root cause wasn’t a bug in the AI model. It was a permissions problem. Kiro inherited an engineer’s elevated credentials and bypassed the standard two-person approval requirement for production changes. The AI had the same access as the human who launched it — which, as it turns out, was far more access than the task required.
Amazon held an internal meeting to address a “trend of incidents” involving AI-assisted changes. Internal documents initially cited “GenAI-assisted changes” as a contributing factor. Those references were later removed from the document ahead of the meeting. The pattern repeated: Amazon’s retail website suffered four high-severity incidents in a single week in early 2026, including a six-hour meltdown that locked shoppers out of checkout.
Replit’s Database Deletion
In July 2025, a Replit AI agent deleted production data covering over 1,200 executives and 1,190 companies — during an active code freeze. The agent had been instructed to make a schema change. It decided the fastest path was to drop and recreate the tables. There was no rollback plan because no one expected the agent to take that action.
The Broader Pattern
According to a 2026 industry survey cited by d4b.dev, 81% of organizations have deployed AI agents, yet only 14.4% have granted those agents full security approval. Meanwhile, 88% report experiencing at least one AI agent security incident.
Read those numbers again. Nearly nine out of ten organizations have had a security incident with an AI agent, and only one in seven has completed a proper security review.
Why the Schema Readiness Gap Exists
The gap isn’t laziness. It’s a structural mismatch between how AI agents work and how databases have been managed for decades.
AI Agents Don’t Read Documentation
A human developer joins a team, reads the wiki, asks questions in Slack, and gradually builds context about which tables are safe to modify, which columns contain PII, and which schemas are owned by other teams. An AI agent gets a connection string and starts issuing queries.
When an agent runs SELECT * FROM users, it doesn’t know that the ssn column was supposed to be masked in non-production contexts. It doesn’t know that the legacy_orders table is being migrated and has inconsistent foreign keys. It doesn’t know that the audit_log table is append-only by policy, not by constraint.
Your schema encodes structure but not intent. And AI agents only see structure.
Permissions Were Designed for Humans
Database role-based access control was designed around human workflows: DBAs get admin, app service accounts get read/write on their tables, analytics users get read-only on curated views. The implicit assumption is that the entity holding the credential understands the blast radius of its actions.
AI agents break that assumption. An agent with db_owner permissions — which is exactly what happened in the Kiro incident — will use those permissions if its objective function says it should. It doesn’t second-guess itself. It doesn’t think “maybe I shouldn’t delete this production environment.” It optimizes.
Schema Drift Is Invisible
The Redgate report found that 29% of organizations manage 10+ database types, and 17% manage 15+. Across that many platforms, schema drift is constant. Column names change meaning. Tables get deprecated but never dropped. Views reference tables that no longer match their original intent.
Humans navigate this through institutional knowledge and tribal memory. AI agents navigate this through whatever the schema inspector returns right now. If the schema is messy, the agent’s behavior will be messy — and it won’t know the difference.
What “AI-Ready” Actually Means for Your Database
Making a database AI-ready isn’t about installing a plugin or flipping a configuration flag. It’s about creating a controlled surface area that gives agents what they need while preventing what they shouldn’t do. Here’s what that looks like concretely.
1. Never Give Agents Direct Database Credentials
This is the single most impactful change you can make. When an agent connects directly to your database with a connection string, you’ve given it the full blast radius of whatever role that credential maps to. Every table, every column, every stored procedure — all accessible.
Instead, put an API layer between the agent and the database. The agent interacts with the API. The API enforces what data is exposed, what operations are allowed, and what rows are accessible. The agent never sees the raw connection.
# Instead of giving an agent this:
# postgresql://agent:password@prod-db:5432/myapp
# Give it this:
curl -fsSL https://get.faucet.dev | sh
faucet serve --db "postgresql://admin:password@prod-db:5432/myapp" --read-only
# Agent connects to http://localhost:8080/api/users — not the database directlyWith Faucet, your database is exposed as a REST API with automatic filtering, pagination, and role-based access control. The agent gets structured endpoints, not raw SQL access.
2. Default to Read-Only, Escalate Deliberately
The principle of least privilege isn’t new, but it’s newly urgent. Most agent use cases — answering questions about data, generating reports, populating dashboards — require read access only. Write access should be an explicit, audited escalation.
# Start with read-only (the default)
faucet serve --db "postgresql://..." --read-only
# When you need write access for specific tables, use RBAC
faucet serve --db "postgresql://..." \
--role agent_writer \
--allow-tables "orders,order_items" \
--allow-methods "GET,POST"The Amazon Kiro incident happened because the agent inherited full admin permissions. If it had been restricted to read-only access — or even just restricted from DDL operations — a 13-hour outage becomes a failed request with a 403 status code.
3. Expose Tables, Not the Full Schema
AI agents work with tool definitions. Every table you expose becomes a tool the agent can use — and every tool consumes context window tokens. But more importantly, every exposed table is a surface area for mistakes.
If your agent’s job is to answer customer support questions, it needs the customers, orders, and products tables. It does not need user_credentials, payment_tokens, or internal_audit_logs.
# Only expose what the agent needs
faucet serve --db "postgresql://..." \
--include-tables "customers,orders,products,order_items"This isn’t just security — it’s performance. As Perplexity’s CTO noted at Ask 2026, tool schema overhead consumed 72% of available context tokens in a deployment with just three MCP servers. Fewer exposed tables means smaller tool definitions, which means more context for actual reasoning.
4. Add an Authorization Layer That Understands Rows, Not Just Tables
Table-level permissions are necessary but insufficient. An agent handling customer support for Acme Corp should see Acme Corp’s orders, not every order in the database. Row-level security turns a single orders endpoint into a properly scoped view of the data.
# API key-based access with row-level filtering
# Agent for Acme Corp only sees their data
curl http://localhost:8080/api/orders?customer_id=eq.42 \
-H "Authorization: Bearer acme-agent-key"Without row-level controls, your agent sees the same data as your most privileged admin user — the exact anti-pattern that caused the Amazon incidents.
5. Log Everything the Agent Does
One of the most striking findings in the d4b.dev analysis: most organizations can’t tell you what their AI agents did yesterday. There’s no audit trail. No query log. No record of which tables were accessed, which rows were returned, or which mutations were attempted.
This matters because AI agents don’t explain themselves after the fact. When something goes wrong, you need a complete record of what happened. With an API layer in front of your database, every request is an HTTP request — and HTTP requests are trivially loggable.
# Faucet logs every request with method, path, status, and timing
faucet serve --db "postgresql://..." --log-level info
# Output:
# 2026-04-13T10:23:45Z INFO GET /api/orders?status=eq.pending 200 12ms
# 2026-04-13T10:23:46Z INFO GET /api/customers/42 200 8ms
# 2026-04-13T10:23:47Z WARN POST /api/orders 403 1ms (read-only mode)When an agent tries to write to a read-only endpoint, you see it immediately. When an agent scans a table it shouldn’t need, you see that too. Visibility is the prerequisite for governance.
The MCP Angle: Making Database Access Agent-Native
The Model Context Protocol has become the standard way AI agents discover and interact with tools. Every major AI provider — Anthropic, OpenAI, Google, Microsoft — now ships MCP-compatible tooling. With 97 million monthly SDK downloads, MCP is the protocol your agents will speak.
Faucet ships with a built-in MCP server. When you start Faucet, your database is automatically available as an MCP resource that any compatible agent can discover:
faucet serve --db "postgresql://..." --mcp
# Your agent sees structured tools:
# - list_tables: discover available tables
# - get_schema: inspect column types and relationships
# - query_table: read data with filters, pagination, sorting
# - create_record: insert data (if write access is granted)The key difference from vendor-managed MCP servers (Google Cloud’s, Snowflake’s, Oracle’s) is that Faucet works with any database. PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, SQLite — same MCP interface, same API, same RBAC model. Your agent doesn’t need to know which database engine is behind the API. It just queries data.
NIST Is Already Moving
In February 2026, NIST and CAISI launched the AI Agent Standards Initiative, focused specifically on identity management, authorization protocols, and least privilege access for autonomous systems. The initiative is structured around three pillars:
- Industry standards development — formal specifications for how agents authenticate and what permissions they should carry
- Open source protocol development — reference implementations for agent authorization
- Ongoing security research — studying real-world incidents to inform future standards
This isn’t a working group that might produce a paper someday. The Amazon incidents, the Replit incident, and the 88% incident rate forced the timeline. Regulatory frameworks for AI agent database access are coming. Organizations that get ahead of the curve — by implementing proper API layers, RBAC, and audit logging now — will be positioned to comply. Organizations that don’t will be scrambling.
The Trust Paradox
Perhaps the most counterintuitive finding from the research: trust in AI outputs has dropped from 40% in 2024 to 29% in 2026, according to developer surveys. Developers know the code isn’t fully trustworthy. They know the queries might be wrong. They know the agent might do something unexpected.
And they’re using it anyway. Adoption is climbing even as trust is falling.
This isn’t irrational. The productivity gains from AI-assisted database work are real. Agents that can query data, generate reports, and answer questions about your schema save enormous amounts of developer time. The problem isn’t the agents. It’s that we’re deploying them without guardrails and hoping for the best.
The 97/15 gap — 97% using AI with databases, 15% confident they’re ready — exists because organizations treated AI database access as a feature to enable rather than an architecture to design. You wouldn’t give a new junior developer db_owner on production on their first day. You shouldn’t give an AI agent the equivalent.
Getting Started
If you’re in the 82% that has AI touching production databases without proper governance, here’s the fastest path to a controlled access layer:
# Install Faucet (single binary, no dependencies)
curl -fsSL https://get.faucet.dev | sh
# Put an API layer in front of your database
faucet serve --db "postgresql://user:pass@localhost:5432/mydb" --read-only
# Your database is now accessible at http://localhost:8080/api/
# with automatic OpenAPI docs, filtering, pagination, and RBACYou’ve now replaced a raw database connection with a governed API endpoint. Every request is logged. Write access is denied by default. The agent sees REST endpoints, not raw tables. And if you need MCP support for agent discovery, add --mcp to the command.
The schema readiness gap is real, but it’s not inevitable. The tools to close it exist today. The question is whether you close it before or after your agent decides to delete a production environment.