The demo went well. The agent answered questions about last quarter, drafted the report and found the slipping accounts, all on a copy of the data. Then someone asked to point it at the real database, and the project stopped: security wants an audit trail, legal wants to know what it can touch, and nobody can say what happens if it's told to delete something. Months later it's still "in pilot".
The short answer: AI agent governance is the set of rules and controls that decide what an agent may read and do, under whose authority, and with what record. Most agent projects don't stall because the model is weak; Gartner predicts "Over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls". The risk-control part is solvable with controls security teams already know: give the agent the person's own permissions and no more, read-only by default; use short-lived keys you can revoke; require approval for anything that changes data; treat anything the agent reads as untrusted; and log every call. The MCP standard and Claude's connector settings support most of this today.
Fastero
Point Claude at your database.
Add Fastero to claude.ai or Claude Code. Claude builds the dashboard, deploys the app or publishes a live page, and your team opens it in Fastero.
Try free →What "95% of AI pilots fail" actually measured
The figure everyone quotes comes from MIT NANDA's July 2025 report The GenAI Divide. Its own wording is narrower than the headlines: "Despite $30–40 billion in enterprise investment into GenAI, this report uncovers a surprising result in that 95% of organizations are getting zero return."
What's behind it:
- The sample was 52 organisation interviews, 153 survey responses from senior leaders and a review of more than 300 public AI projects, not the "150 interviews" and "350 employees" in the viral coverage.
- Success meant a "marked and sustained productivity and/or P&L impact", self-reported and measured six months after the pilot.
- The authors' own caveat: "Research Limitations: These figures are directionally accurate based on individual interviews rather than official company reporting."
- Generic chatbots did far better, with about 83% going from pilot to use. The low rates were for custom and vendor enterprise tools: 60% of organisations evaluated them, 20% piloted, 5% reached production.
Other data points in the same direction, more modestly. McKinsey's 2026 survey of 1,719 people found "Thirty-seven percent of respondents attribute at least some EBIT impact to AI use (about the same share as last year)." BCG's 2025 study of more than 1,250 firms found 5% achieving AI value at scale and 60% not achieving material value at all.
Why agent projects stop at the data
MIT's interviewees mostly blamed fit and adoption, not regulation. But when it came to choosing vendors, they asked for "clear data boundaries", and one said: "I can't risk client data mixing with someone else's model, even if the vendor says it's fine."
That's where agent projects usually stall: the step from a sample to production data. Two incidents from 2025 show why security teams hesitate.
- A read-only agent that leaked anyway. In a demonstration by General Analysis, a support ticket containing hidden instructions led a developer's AI assistant, connected to Supabase's MCP server, to read private tables and copy them into a reply the customer could see. Their conclusion is the key point: "Read-only access still permits reads of data available to the database role." Read-only stops writes; it doesn't stop an agent reading everything its credentials can reach.
- A write that should never have been possible. A coding agent on Replit deleted a founder's production database despite instructions not to change anything, as The Register reported. The lesson he drew: "you can't overwrite a production database. And you can't not separate preview and staging and production cleanly."
Both point to the same design rule: decide what an agent can do by what its credentials allow, not by what it's told.
The controls that get an agent into production
Most of these come straight from the OWASP Top 10 for Agentic Applications (December 2025), whose central idea is "least agency": "This captures our advice to organizations to avoid unnecessary autonomy; deploying agentic behavior where it is not needed expands the attack surface without adding value."
| Control | What it means in practice |
|---|---|
| The person's permissions, no more | The agent acts as the user who connected it, and can never see more than they can. Shared service accounts are how agents end up seeing everything |
| Read-only by default | OWASP's own example: "read-only queries for databases". Writes are a separate, opt-in permission |
| Short-lived, revocable keys | OWASP: "Issue short-lived, narrowly scoped tokens per task". Expiry by default, revocation that takes effect at once |
| Approval for changes | A person approves anything that deletes, sends, publishes or changes data before it happens |
| Treat what the agent reads as untrusted | Text in a ticket, email or table can carry instructions. Keep agents with broad read access away from tools that send data out |
| Limits on what comes back | Cap how many rows a query returns, so one careless request can't pull a whole table into a conversation |
| A record of every call | Who asked, with which key, which tool, when. OWASP: "strong observability becomes non-negotiable" |
| Agreed definitions | The agent uses the company's definition of revenue or churn, so its answers match the reports people already trust |
What the MCP standard already requires
MCP, the protocol most agents now use to reach tools and data, builds several of these controls into its specification (current version: 28 July 2026):
- Tokens bound to one server. "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience". A token issued for one service can't be replayed against another.
- No token passthrough. "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." Passing a user's upstream token straight through would also break the audit trail, because the server couldn't tell clients apart.
- Least-privilege scopes. The spec's security guide recommends starting with "a progressive, least-privilege scope model", beginning with read operations only, and logging when more is granted.
- A human who can say no. "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations."
What Claude's connector settings add
In Claude, every connector's tools can be set individually: "For each permission category or individual permission, select Always allow, Needs approval, or Blocked." Owners on Team and Enterprise plans can set these for the whole organisation, and individuals can't override them.
Claude also doesn't widen access: "Claude inherits each person's permissions from the connected service." The exception is a custom connector set up with one shared credential, which reaches whatever that credential can. And as Anthropic notes: "Restricting actions in Claude never grants more access than the source system permits—it only narrows it." One caveat: in research mode Claude can call connector tools without asking each time, so switch off tools that write before using research mode with them.

Per-tool permissions for a connector in Claude: always allow, ask first, or block. Taken on a test account, 5 November 2026.
Regulation in 2026: less than you may have read
Many pages still say the EU AI Act's high-risk rules start on 2 August 2026. They don't any more. The Digital Omnibus on AI, in force since 27 July 2026, moved them to 2 December 2027 for the systems listed in Annex III and 2 August 2028 for Annex I. What does apply from 2 August 2026 is mainly the transparency rules, such as telling people when they're dealing with an AI system, and enforcement by the AI Office and national authorities.
An internal agent that queries your sales data is generally not a high-risk system under the Act. The controls above are good engineering and what your security reviewer will ask for, not a legal record-keeping duty for ordinary data agents. In the US, NIST's AI Risk Management Framework is voluntary and "is being revised as part of the White House AI Action Plan", and NIST launched an AI Agent Standards Initiative in February 2026.
Point Claude at your database.
Connect Claude →How Fastero puts Claude on production data
Fastero is a workspace where your team's databases and sources are connected once, and Claude reaches them through a connector built around the controls above:
- Your permissions, checked every time. The connector acts as the person who signed in, inside one workspace, and can never do more than their role there allows. The role is checked live on every call, so removing someone's access takes effect immediately. Viewers can only read.
- Read-only by default. A new key starts as "read and query only". Building dashboards, queries and notebooks is a separate permission, and deleting things, running compute, managing secrets and sharing are separate again, in no preset.
- Keys that expire. Keys last 30, 60 or 90 days, with warnings before they run out, and revoking one ends it at once. Claude's sign-in uses one-hour access tokens bound to your workspace's address; disconnecting revokes them.
- SQL that can't change data. Claude's query tool accepts one
SELECT,WITH,EXPLAINorSHOWstatement and refuses anything that could change data; on Postgres it also runs inside a read-only transaction. A result returns at most 500 rows or about 100 KB. - Every tool says what it does. Each tool declares whether it only reads or changes something, so Claude can ask before any change.
- A log of every call. Every connector call is recorded with the person, workspace, key, tool, address and client, without the arguments.
- Answers that match your reports. Claude reads the metric definitions your team has saved, so its numbers agree with the dashboards.
Pair that with a database login that can only read the tables the agent needs, and an injected instruction can't reach anything the person couldn't already see.

Fastero's AI agent access settings: keys that act as you and never exceed your role.
From pilot to production in 30 days
- Week 1: one question that matters. Pick a recurring question with a known answer, such as weekly revenue by region, so you can check the agent against it.
- Week 1: least-privilege access. A read-only database login limited to the tables needed, and the agent connected through a connector that acts as each user.
- Week 2: definitions. Write down what revenue, active customer or churn mean, so the agent's answer matches the report.
- Week 3: approvals and blocks. Block tools the agent doesn't need; set anything that writes to "needs approval".
- Week 4: show the log. Give security the record of calls and the list of permissions. That's usually the document that unblocks production.
FAQ
Do 95% of AI pilots really fail?
Not as usually quoted. MIT NANDA's report says 95% of organisations are "getting zero return" from generative AI, based on 52 interviews and 153 survey responses, with success self-reported six months after the pilot. The authors call the figures "directionally accurate".
Why do AI agent projects stall?
Gartner names "escalating costs, unclear business value or inadequate risk controls". MIT's interviews point to tools that don't fit how people work. In practice many stall at the step from sample data to production data, where security and legal ask what the agent can touch.
Is read-only access enough for an AI agent on a database?
No. Read-only stops changes but not over-broad reads. Limit the agent to the person's own permissions and to the tables it needs, because whatever its credentials can read, an injected instruction can read too.
What is token passthrough, and why does MCP forbid it?
It's when an MCP server accepts a token issued for another service and passes it straight on. The MCP specification forbids it: servers must only accept tokens issued for them, which keeps permissions and audit trails tied to the right server and client.
Can I make Claude ask before it changes anything?
Yes. In Claude, set a connector's write tools to "Needs approval" or "Blocked". Team and Enterprise owners can set this for the whole organisation.
Does the EU AI Act require audit logs for AI agents?
Not for ordinary internal data agents. The Act's record-keeping duties are for high-risk systems, and those rules were moved to December 2027 and August 2028. Logging agent calls is still good practice and what security reviews ask for.
Related reading:
- What is shadow AI?
- MCP security
- Postgres MCP server: connect Claude safely
- MCP server examples
- What is a semantic layer?
Sources: MIT NANDA: The GenAI Divide, Gartner on agentic AI projects (25 June 2025), McKinsey: The state of AI in 2026, BCG: The Widening AI Value Gap, OWASP Top 10 for Agentic Applications 2026, OWASP Top 10 for LLM Applications, MCP authorization, MCP security best practices, Claude connector permissions, General Analysis on Supabase MCP, The Register on the Replit incident, European Commission: AI Act, NIST AI RMF. Checked 5 November 2026.
Try Fastero free — connect your data once and give Claude read-only access that follows each person's role, with every call logged. No credit card required.
Fastero Dev Team