AI Engineer · Published 2026-09-09

Build-Time vs. Run-Time: Why Dev Tools Fail in Production — Averi Kitsch & Prerna Kakkar, Google

privateReview: unreviewedConfidence: high
MCPdatabasessecurityGuardrailsagentssqlagent-toolingaccess-controlprompt-injectionzero-trusttool-design
Open on YouTube ↗

Summary

Overview

  • Speaker: Averi Kitsch & Prerna Kakkar
  • Channel: AI Engineer
  • Main topic: Build-Time vs. Run-Time Architecture in AI Agents and Tooling for Databases
  • Purpose: To educate AI engineers on why development tools fail in production and how to build secure, robust database tooling for agents using proper architecture, parameter controls, and guardrails. Averi Kitsch and Prerna Kakkar from Google Cloud Database discuss the differences between build-time developer assistant tools and run-time end-user application agents. They cover MCP Toolbox for Databases, common tool patterns for database access (control plane tools, Natural Language to SQL, and structured SQL tools), and security guardrails such as addressing the 'Confused Deputy' attack pattern and implementing Model-Controlled vs Application-Controlled parameter security.

Topic Map

Background & Introduction to MCP Toolbox

  • Explanation: Introduction of the speakers and MCP Toolbox for Databases, an open-source, self-managed server and fully managed Google Cloud MCP service providing secure database access for agents.
  • Key claims:
    • MCP Toolbox for Databases has over 15.7K GitHub stars and 132+ contributors across 40+ databases.
    • Provides connection pooling, integrated auth, and out-of-the-box observability.
    • Google Managed MCP provides fully managed hosting, agent-first design, common governance, simplified discovery via Gemini CLIs and IDEs, and Model Armor for data protection.
  • Examples:
    • Connecting AlloyDB, Spanner, Cloud SQL, Bigtable, and Firestore through MCP.
  • Terminology:
    • MCP Toolbox
    • Google Managed MCP
    • Model Armor
    • Connection Pooling
  • Why it matters: Provides a secure, scalable standard for integrating LLM agents with enterprise databases.

Common Tool Patterns for Databases

  • Explanation: Exploration of three tool patterns used for databases: Control Plane Tools (infrastructure and admin), Natural Language to SQL (NL2SQL), and Structured SQL Tools.
  • Key claims:
    • Control plane tools automate database instance creation and lifecycle management but require human-in-the-loop oversight.
    • NL2SQL tools generate raw SQL dynamically via LLMs for analytical agents and flexible exploration.
    • Structured SQL tools pre-approve queries ahead of time for production-grade applications, preventing SQL injection.
  • Examples:
    • Creating database instances with execute_sql or create_instance.
    • Querying 'Find all customers in California who bought a winter coat in July and returned it within 14 days'.
  • Terminology:
    • Control Plane Tools
    • Natural Language to SQL (NL2SQL)
    • Structured SQL Tools
    • SQL Injection
  • Why it matters: Understanding different tool patterns helps architects choose the right balance of flexibility and safety.

Build-Time vs. Run-Time Agents

  • Explanation: Distinction between developer assistant agents used at build-time (in IDEs/CLIs with generic tools) and end-user application agents running in production workflows.
  • Key claims:
    • Build-time tools are atomic and flexible, but rely on human-in-the-loop and cannot be safely exposed to end users in production.
    • Run-time end-user application agents require composite, constrained, deterministic tools with zero-trust boundaries and low latency.
  • Examples:
    • Developer assistants using generic database execution tools vs. end-user chatbots executing specific cancel_order workflows.
  • Terminology:
    • Build-Time Agents
    • Run-Time Agents
    • Human-in-the-Loop
    • Zero-Trust Boundaries
  • Why it matters: Developer tools that work in local environments fail in production because they lack production-grade security and constraints.

Security & Guardrails: The Confused Deputy & Application Control

  • Explanation: Discussion of database security vulnerabilities in agents, focusing on the 'Confused Deputy' attack and Simon Willison's 'Lethal Trifecta'.
  • Key claims:
    • Databases are only as secure as their agent; LLMs are susceptible to prompt injection.
    • The Lethal Trifecta occurs when an agent has access to private data, untrusted content, and the ability to expose that data externally.
    • Application-controlled parameters enforce strict boundaries compared to model-controlled parameters where agents handle raw credentials.
  • Examples:
    • A malicious insider injecting a prompt inside a ticket to query and leak all employee salaries.
    • Transitioning from raw access to configurable sources, custom semantic tools, and binding authenticated parameters.
  • Terminology:
    • Confused Deputy Attack
    • Lethal Trifecta
    • Application Control
    • Source Primitive
    • Read-Only Enforcement
    • Allowed Datasets
    • Bounded Parameters
    • AuthN Parameters
  • Why it matters: Securing database access requires removing raw connection details and user identifiers from agent control entirely.

Key Points

Build-Time vs. Run-Time Failure

  • Explanation: Developer tools fail in production because they assume a human-in-the-loop and broad access permissions that are unsafe for end-user runtime agents.
  • Evidence: Demonstrations showing agents executing destructive DELETE statements when prompted by untrusted user text without guardrails.
  • Practical implication: Engineers must transition from generic developer tools to constrained, production-ready runtime tools.

The Lethal Trifecta in Agents

  • Explanation: When an agent combines access to private data, untrusted inputs, and external communication channels, data breaches occur via prompt injection.
  • Evidence: Simon Willison's concept of the Confused Deputy attack where ticket-processing agents are tricked into querying salary tables.
  • Practical implication: Isolate identity and abstract connection strings using Source primitives and bound/authenticated parameters.

Best Practices for Tool Quality

  • Explanation: High-quality agent tools must focus on outcomes rather than atomic REST APIs, provide actionable errors for retries, and use simple flattened inputs.
  • Evidence: Separating read and write tools, returning descriptive retryable errors instead of generic 404s, and avoiding complex nested maps.
  • Practical implication: Improves agent reliability and reduces round trips and hallucinations.

Frameworks, Models & Processes

Evolution of a Secure Tool Architecture

  • How it works: Progresses from insecure raw database access to zero-trust architecture by abstracting connection details and binding user identity at the application layer.
  • Components:
    • Raw Access (Insecure)
    • Configurable Sources
    • Custom Semantic Tools
    • Binding & Authenticated Parameters
  • When to use: When building any database-connected AI agent for production deployment.

Examples & Case Studies

An agent tasked with cleaning up a user table takes user input literally and executes a destructive DROP or DELETE query without safeguards.

  • Illustrates: The danger of exposing raw SQL execution tools to agents without guardrails or human confirmation.
  • Lesson: Never give runtime agents raw execute_sql capabilities over sensitive databases without strict pre-defined logic and parameter binding.

Actionable Takeaways

  • Immediate:
    • Separate read and write tools to enable automatic approval for read-only actions.
    • Return actionable error messages so agents can self-correct and retry.
    • Use flat parameter structures instead of complex nested maps.
  • Strategic:
    • Treat LLM agents as untrusted privileged users requiring zero-trust boundaries.
    • Abstract database connection credentials out of agent control using Source primitives.
    • Enforce authentication at the application level and pass claims (user ID, email) via bounded or AuthN parameters.
  • Questions to investigate:
    • How can we further reduce latency when implementing multi-layer security guardrails?
    • What are the best automated evaluation frameworks for testing agent tool security?

Claims Worth Verifying

  • MCP Toolbox for Databases has over 15.7K GitHub stars and 132+ contributors. (Statistic)
  • Model Armor provides secure access management and identity control for managed MCP. (Technical Feature)

Notable Quotes

"Your Database is only as Secure as your Agent" "A data breach occurs when an agent has simultaneous access to private data, untrusted content, and three the ability to expose that content and that data back to an external user."

Compressed Summary

  • Developer tools built for local build-time assistance fail when deployed to production run-time agents.
  • Prevent the Confused Deputy problem by removing raw database connection strings and credentials from agent control using Source primitives.
  • Enforce zero-trust architecture by using application-controlled bounded parameters and authenticated user claims rather than letting agents generate raw SQL.
  • Keywords: mcp, databases, security, guardrails, agents, sql
  • Core insight: Production AI agents require strict parameter binding, read/write separation, and application-controlled guardrails to prevent data breaches caused by prompt injection and the Confused Deputy vulnerability.

Core insights

6
Architecturemedium noveltystrong evidence

The same database tool cannot safely serve both build-time and run-time agents: developer assistant tools are atomic and flexible because a human is in the loop, while production end-user agents require composite, constrained, deterministic tools with zero-trust boundaries and low latency. The build-time/run-time boundary is therefore an architectural boundary, not a deployment detail.

Why it matters

It reframes 'why dev tools fail in production' as a category error — tools designed around human oversight and broad permissions are structurally unsafe for autonomous end-user paths, so reuse across the boundary is the failure, not a bug to patch.

Generalization

Any agent tool designed against an interactive developer surface (IDE, CLI) should be treated as a different artifact class from the tool exposed to untrusted end users, even when both call the same backend.

Build-time tools are atomic and flexible, but rely on human-in-the-loop and cannot be safely exposed to end users in production.
Open source video
Run-time end-user application agents require composite, constrained, deterministic tools with zero-trust boundaries and low latency.
Open source video
Architecturemedium noveltystrong evidence

Identity and connection material must be moved out of model control entirely: application-controlled parameters (configurable sources, bound and authenticated parameters) replace model-controlled parameters where the agent handles raw credentials. The application, not the LLM, resolves who the caller is and which data source applies.

Why it matters

This removes the credential/identifier surface from the prompt-injection attack surface — even a fully hijacked model cannot select another user's identity or connection string because those values are never its inputs.

Generalization

For any tool that touches multi-tenant or permissioned resources, bind authn identity at the harness layer and expose only business-level arguments to the model.

Application-controlled parameters enforce strict boundaries compared to model-controlled parameters where agents handle raw credentials.
Open source video
Securing database access requires removing raw connection details and user identifiers from agent control entirely.
Open source video
Tradeoffmedium noveltymoderate evidence

Structured SQL tools pre-approve queries ahead of time, constraining the action space itself to prevent SQL injection, whereas NL2SQL dynamically generates raw SQL for flexible exploration. Safety is achieved by bounding what can be expressed, not by filtering what was generated.

Why it matters

It gives a concrete production-grade pattern for database agents (curated, pre-approved statements) and marks NL2SQL as an exploration/analytical pattern rather than a production default.

Generalization

Constrain the reachable action set at design time rather than post-hoc validating model output; pre-approved operations are the durable safety primitive.

Structured SQL tools pre-approve queries ahead of time for production-grade applications, preventing SQL injection.
Open source video
NL2SQL tools generate raw SQL dynamically via LLMs for analytical agents and flexible exploration.
Open source video
Mental Modelmedium noveltymoderate evidence

The Lethal Trifecta is treated as an actionable design test: a breach requires simultaneous access to private data, untrusted content, and an external exposure channel. The fix is to remove at least one leg, e.g. via source primitives and bound/authenticated parameters, rather than to 'harden' the agent.

Why it matters

Converts a diffuse security worry into a per-agent checklist that produces a binary design decision (which leg can be eliminated) instead of incremental prompt-level mitigation.

Generalization

Audit every production agent for the three-leg combination and break it structurally — capability removal beats behavioral instruction.

The Lethal Trifecta occurs when an agent has access to private data, untrusted content, and the ability to expose that data externally.
Open source video
Databases are only as secure as their agent; LLMs are susceptible to prompt injection.
Open source video
Practicemedium noveltymoderate evidence

Tool ergonomics are reliability engineering: outcome-shaped composite tools instead of atomic REST wrappers, descriptive retryable errors instead of generic 404s, simple flattened inputs instead of nested maps, and separated read and write tools. These choices reduce round trips and hallucination.

Why it matters

Treats tool interface design as a lever on agent reliability and cost (round trips) rather than a cosmetic API concern, and gives concrete, implementable rules.

Generalization

Tool schemas should encode the business outcome and the recovery path (what to retry) rather than mirror the backend's CRUD surface.

High-quality agent tools must focus on outcomes rather than atomic REST APIs, provide actionable errors for retries, and use simple flattened inputs.
Open source video
Separating read and write tools, returning descriptive retryable errors instead of generic 404s, and avoiding complex nested maps.
Open source video
Architecturemedium noveltymoderate evidence

Secure agent-database architecture is a staged migration: Raw Access (insecure) → Configurable Sources → Custom Semantic Tools → Binding & Authenticated Parameters, each stage abstracting more connection detail away from the model.

Why it matters

Provides an incremental adoption path for teams currently exposing raw execute_sql, so security can be improved without a full rewrite.

Generalization

Retrofitting trust into an existing agent integration follows an abstraction ladder: remove credentials, then narrow semantics, then bind identity.

Progresses from insecure raw database access to zero-trust architecture by abstracting connection details and binding user identity at the application layer.
Open source video
Raw Access (Insecure)
Open source video
Custom Semantic Tools
Open source video
Binding & Authenticated Parameters
Open source video

Deep dives

5

Coverage limits of pre-approved SQL tool libraries versus NL2SQL

Research question

What fraction of real production end-user query traffic can be satisfied by a fixed library of pre-approved structured SQL statements before coverage collapse forces teams back to dynamically generated SQL, and what do the residual unbounded queries look like?

Why

The build-time/run-time argument hinges on structured SQL being production-grade and NL2SQL being exploration-only, but without a coverage number that boundary is a preference rather than an engineering constraint. If coverage is high, the safety pattern generalizes; if it collapses, teams will silently reintroduce raw SQL generation under production load and the architectural claim becomes aspirational.

Structured SQL tools pre-approve queries ahead of time for production-grade applications, preventing SQL injection.
Open source video
NL2SQL tools generate raw SQL dynamically via LLMs for analytical agents and flexible exploration.
Open source video
Source video

Composition semantics for bound identity and multi-dataset agents

Research question

When a single runtime agent legitimately spans multiple tenants or datasets, how should application-bound authenticated parameters and configurable sources compose so that per-request identity cannot be widened by adversarial prompts?

Why

Application-controlled parameters remove the credential surface only if the binding is unambiguous. The moment one agent must reach several allowed datasets, the application layer reintroduces a selection problem the model may be able to influence, which is exactly the confused-deputy shape the pattern was meant to eliminate. The composition rules, not the single-tenant case, decide whether this is a real boundary.

Application-controlled parameters enforce strict boundaries compared to model-controlled parameters where agents handle raw credentials.
Open source video
Securing database access requires removing raw connection details and user identifiers from agent control entirely.
Open source video
Source video

Measurable reliability delta from tool schema ergonomics

Research question

What magnitude of change in task success rate, round-trip count, and retry behavior results from swapping atomic REST-shaped tools for outcome-shaped composite tools with retryable errors and flattened inputs?

Why

The claim that ergonomics reduce hallucination and round trips is stated as a practice with no instrumentation, so it is currently unactionable for teams deciding whether to invest in a tool schema rewrite. A controlled paired-schema benchmark converts tool design from taste into a budgetable reliability lever.

High-quality agent tools must focus on outcomes rather than atomic REST APIs, provide actionable errors for retries, and use simple flattened inputs.
Open source video
Improves agent reliability and reduces round trips and hallucinations.
Open source video
Source video

Gate granularity for agent-invoked control-plane operations

Research question

At what approval granularity — per action, per plan, or per policy class — does a human-in-the-loop gate on control-plane tools preserve operator capacity while still reducing incident rate compared to unattended execution?

Why

Oversight is asserted as mandatory but the gate's latency budget and failure handling are unspecified, which means the only two implementable options today are unusably slow or effectively unattended. A granularity curve is what makes the requirement schedulable instead of rhetorical.

Control plane tools automate database instance creation and lifecycle management but require human-in-the-loop oversight.
Open source video
Progresses from insecure raw database access to zero-trust architecture by abstracting connection details and binding user identity at the application layer.
Open source video
Source video

Sufficiency of single-leg removal against exfiltration under adversarial prompts

Research question

Does removing exactly one leg of the Lethal Trifecta — private data, untrusted content, or an external exposure channel — reliably prevent exfiltration across models and prompt phrasings, or do side channels reconstruct the removed leg?

Why

The trifecta is presented as a binary design test, but if removal of one leg is only partially effective then the checklist yields false confidence. Testing each leg's removal independently is what converts a mental model into a verifiable control.

The Lethal Trifecta occurs when an agent has access to private data, untrusted content, and the ability to expose that data externally.
Open source video
Databases are only as secure as their agent; LLMs are susceptible to prompt injection.
Open source video
Source video

Article ideas

4

The Boundary Is the Architecture: Dev Tooling Is a Different Artifact Class, Not a Deploy Target

Reusing a build-time developer tool in a production end-user path is a category error, not a hardening task: the human-in-the-loop assumption and broad permission scope are load-bearing parts of the tool's design, so the failure is structural and cannot be patched with prompt rules. Teams should maintain two tool classes against the same backend rather than one tool with a safety toggle.

Angle

Treat presence or absence of human oversight as the variable that classifies a component, then show why every attempt to 'productionize' a dev tool by adding guardrails is really an undeclared rewrite.

Source video

Capability Removal Beats Behavioral Instruction: Why Prompt-Level Hardening Loses to Structural Constraints

Agent security arguments that rely on instructing the model to behave are unfalsifiable and fail under prompt injection, whereas pre-approved statements, application-bound identity, and outcome-shaped narrowed tool surfaces are verifiable by construction. The article argues for migrating safety properties out of the prompt and into the reachable action set, and shows that the cost is bounded expressiveness rather than lost capability.

Angle

Frame the debate as design-time action-space constraint versus post-hoc output filtering, and score each approach by what it can prove rather than what it can express.

Source video

Stop Passing Identity Through the Model: The Confused Deputy Is an Interface Bug

Any tool argument that names a user, tenant, or connection is an attack primitive regardless of how well the prompt is written. The fix is to bind identity and data source in the harness and expose only business-level arguments to the model, which makes cross-tenant redirection unrepresentable rather than merely unlikely — and this is a schema decision, not a detection problem.

Angle

Walk from a hijacked-model scenario to the tool schema and show which parameters were model-controlled, then present the migration ladder from raw access to bound authenticated parameters as the concrete remedy.

Source video

Tool Schemas Are Reliability Infrastructure: Outcomes, Retryable Errors, and Flattened Inputs

Tool interface design is a control loop on agent reliability and cost, not cosmetic API tidiness: atomic REST wrappers inflate round trips, generic 404s destroy the agent's recovery path, and nested maps raise argument-level hallucination. Separating read and write tools and shaping schemas around business outcomes should be treated as testable engineering with measurable success and round-trip effects.

Angle

Argue that the cheapest reliability win available to most agent teams is a schema rewrite, and that the absence of benchmarks is why teams keep tuning prompts instead.

Source video

Project ideas

4

Harness-Bound Identity Proxy for Agent Database Tools

gatehouse

If user identity and data source are resolved and bound at the harness layer before the model sees a tool call, then adversarially prompted agents will produce zero successful cross-tenant or cross-dataset redirections, even when the prompt fully controls every remaining business argument.

Proof of concept

Intercept MCP tool invocations in a thin proxy that strips model-supplied identity/source arguments, injects the authenticated principal and an allowlisted dataset, and exposes only business parameters. Run a red-team suite that attempts confused-deputy redirection, credential substitution, and dataset hopping across at least two models.

Measurement

Cross-tenant leakage rate (target zero) and business-task success rate versus a baseline where identity and source remain model-controlled parameters; also record how many legitimate multi-dataset requests are broken by the binding rule.

Source video

Paired-Schema Agent Reliability Benchmark

beyond-evals

Outcome-shaped composite tools with actionable retryable errors and flattened inputs will raise task success and cut round trips by a measurable margin over atomic REST-wrapped equivalents, independently of model choice.

Proof of concept

Build two tool surfaces over the same database backend — one atomic with generic 404 errors and nested parameter maps, one outcome-shaped with flattened inputs, separated read/write tools, and descriptive retryable errors. Run an identical task suite against both across multiple models and log the full call trace.

Measurement

Task success rate, mean round trips per completed task, retry-after-error success rate, and argument-validation failure rate, reported per model to separate schema effect from model effect.

Source video

Pre-Approved Statement Coverage Analyzer

new

A curated library of pre-approved SQL statements can satisfy a majority of production end-user query traffic, and the residual uncovered requests cluster into a small, enumerable set of analytic patterns rather than a long tail.

Proof of concept

Ingest a real or synthetic end-user query workload, map each request against a pre-approved statement library, classify the failures, and route only unmapped requests to an NL2SQL exploration path. Report coverage as the library grows.

Measurement

Coverage percentage versus library size, residual query diversity (distinct patterns per uncovered request), and SQL-injection surface area measured as the count of requests reaching dynamic generation.

Source video

Agent Integration Trust Ladder Conformance Scorer

movement-lab

An automated conformance scorer can place any existing agent-database integration at a specific rung of the raw-access-to-bound-parameters ladder and predict its exploitability, letting teams improve trust incrementally instead of rewriting.

Proof of concept

Define machine-checkable criteria per stage (raw execute_sql present, configurable sources declared, custom semantic tools defined, parameters bound and authenticated) and score representative open-source agent integrations, then attempt a destructive-action probe against each.

Measurement

Stage assignment versus observed probe resistance — destructive DROP/DELETE execution under untrusted input — and the measured security delta per upgrade step between adjacent rungs.

Source video

Architectural implications

3

Identity and data-source selection currently sit inside the model's tool arguments in typical developer-oriented tooling.

Before

The agent supplies user identifiers and connection details as model-controlled parameters and can call a raw execute_sql tool.

After

The application binds authenticated identity and a configured source, exposing only business-level, bounded parameters to the model.

Consequence

Prompt injection can no longer redirect queries to another tenant's data, and the tool surface becomes auditable per caller.

Source video

Database statements are currently generated freely by the LLM for flexibility.

Before

NL2SQL generates arbitrary SQL at run time for any question.

After

Production paths route through pre-approved structured statements; NL2SQL is reserved for analytical or exploratory agents.

Consequence

The reachable query set becomes finite and reviewable, trading expressive flexibility for a much smaller injection and blast-radius surface.

Source video

Control-plane lifecycle operations are being tool-ified for agents.

Before

Infrastructure changes are made by humans through consoles or scripts.

After

Agents propose instance creation/lifecycle actions via control-plane tools with human-in-the-loop oversight.

Consequence

Automation gains speed but retains a mandatory approval gate, meaning control-plane tooling cannot be an unattended run-time path.

Source video

Tradeoffs and failure modes

4

NL2SQL flexibility vs. injection safety

Benefit

Dynamic SQL generation supports flexible exploration and analytical questions that cannot be enumerated in advance.

Cost or risk

Generated raw SQL reintroduces SQL injection and unbounded query scope, so it is unsuitable as a production end-user path.

Structured SQL tools pre-approve queries ahead of time for production-grade applications, preventing SQL injection.
Open source video
Source video

Model-controlled vs. application-controlled parameters

Benefit

Model-controlled parameters give the agent maximum latitude, including handling credentials and identifiers directly.

Cost or risk

The agent then owns the identity and connection decision, enabling confused-deputy exploitation where injected content redirects privileged queries.

Application-controlled parameters enforce strict boundaries compared to model-controlled parameters where agents handle raw credentials.
Open source video
Source video

Control-plane automation vs. oversight

Benefit

Control-plane tools automate database instance creation and lifecycle management.

Cost or risk

They require human-in-the-loop oversight, so they cannot be exposed as unattended run-time capabilities for end users.

Control plane tools automate database instance creation and lifecycle management but require human-in-the-loop oversight.
Open source video
Source video

Raw execution tools exposed to runtime agents

Benefit

A generic execute_sql tool is maximally capable and simple to implement.

Cost or risk

An agent prompted by untrusted user text can execute destructive DELETE/DROP statements with no safeguard.

Never give runtime agents raw execute_sql
Open source video
Source video

Open questions

4

Does pre-approving structured SQL tools actually cover real end-user query workloads, or does coverage collapse force teams back to NL2SQL?

Why unresolved

The summary asserts structured tools are production-grade and NL2SQL is for exploration, but gives no data on how much of a typical workload can be pre-approved.

Research direction

Instrument a production agent to measure the fraction of user requests satisfiable by a fixed library of pre-approved statements, and catalog the residual unbounded queries.

Source video

How should configurable sources and bound authenticated parameters be composed when a single agent legitimately spans multiple datasets or tenants?

Why unresolved

The summary lists 'Allowed Datasets' and 'AuthN Parameters' as terminology but does not describe the composition or multi-source semantics.

Research direction

Prototype an application layer that binds per-request identity to an allowlisted dataset set and test for cross-tenant leakage under adversarial prompts.

Source video

What is the measurable reliability delta from outcome-shaped tools, retryable errors, and flattened inputs?

Why unresolved

The claim that these practices reduce round trips and hallucinations is stated as a practical implication without supporting measurement.

Research direction

Benchmark a database agent with paired tool schemas (atomic vs. outcome-shaped; generic 404 vs. retryable error) and compare task success, round trips, and retry behavior.

Source video

Where exactly should the human-in-the-loop gate sit for control-plane tools without destroying the value of automating lifecycle operations?

Why unresolved

Oversight is asserted as a requirement but the granularity, approval latency budget, and failure handling of the gate are not specified.

Research direction

Define approval granularity levels (per action, per plan, per policy class) and measure operator burden versus incident reduction.

Source video

Key claims

7
causalVerification needed

Developer-oriented build-time database tools cannot be safely exposed to production end users because they depend on human-in-the-loop oversight and broad access.

Evidence

Build-time tools are atomic and flexible, but rely on human-in-the-loop and cannot be safely exposed to end users in production.

Question

What specific incidents or red-team results show build-time tools producing unsafe production behavior when reused?

Source video
comparativeVerification needed

Structured SQL tools are production-grade for applications because pre-approval prevents SQL injection, unlike dynamically generated NL2SQL.

Evidence

Structured SQL tools pre-approve queries ahead of time for production-grade applications, preventing SQL injection.

Question

Does pre-approval fully eliminate injection risk (e.g. parameter binding, second-order injection), or only the model-generated SQL vector?

Source video
causalVerification needed

The Lethal Trifecta — private data access, untrusted content, and external exposure capability — is the condition under which agent data breaches occur.

Evidence

The Lethal Trifecta occurs when an agent has access to private data, untrusted content, and the ability to expose that data externally.

Question

Is removal of any single leg sufficient to prevent exfiltration in practice, or are there bypass paths?

Source video
comparativeVerification not requested

Application-controlled parameters enforce boundaries that model-controlled parameters cannot, because the latter require the agent to handle raw credentials.

Evidence

Application-controlled parameters enforce strict boundaries compared to model-controlled parameters where agents handle raw credentials.

Source video
causalVerification needed

An agent given a raw SQL execution tool and untrusted user input will execute destructive statements without safeguards.

Evidence

An agent tasked with cleaning up a user table takes user input literally and executes a destructive DROP or DELETE query without safeguards.

Question

How reproducible is destructive behavior across models and prompt phrasings, and what guardrails reliably block it?

Source video
factualVerification needed

MCP Toolbox for Databases has over 15.7K GitHub stars and 132+ contributors across 40+ databases, and provides connection pooling, integrated auth, and observability.

Evidence

MCP Toolbox for Databases has over 15.7K GitHub stars and 132+ contributors across 40+ databases.

Question

Are the repository metrics and database coverage current as of the claim date?

Source video
causalVerification needed

Outcome-shaped tools, actionable retryable errors, and flattened inputs improve agent reliability and reduce round trips and hallucinations.

Evidence

Improves agent reliability and reduces round trips and hallucinations.

Question

What magnitude of improvement in task success and round-trip count do these schema changes produce in a controlled benchmark?

Source video

Connections

4