{
  "video": {
    "id": "9R--1tg45Jg",
    "title": "Build-Time vs. Run-Time: Why Dev Tools Fail in Production — Averi Kitsch & Prerna Kakkar, Google",
    "duration": 1226,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer"
  },
  "analysis": {
    "video_id": "9R--1tg45Jg",
    "title": "Build-Time vs. Run-Time: Why Dev Tools Fail in Production — Averi Kitsch & Prerna Kakkar, Google",
    "one_liner": "Two Google engineers behind MCP Toolbox for Databases argue that the flexible, model-controlled database tools that work fine in a dev assistant become data-breach machines in production, and walk through the step-by-step hardening — source primitive, custom SQL tools, bound/authenticated parameters — that ends in a tool whose only input is a date.",
    "summary": "Averi Kitsch and Prerna Kakkar split database tooling into build-time (control-plane/admin tools and NL2SQL 'execute SQL', atomic and flexible, human-in-the-loop, not production-safe) and runtime (structured, predefined SQL tools serving end-user applications). They show a build-time failure where an agent asked to 'delete the table and start fresh' wiped everything with no guardrails, then use Simon Willison's lethal trifecta and the confused deputy attack to explain how an agent's privileges leak private data. The bulk of the talk is an 'evolution of a secure tool': starting from a tool where the agent is effectively a super user holding credentials, host, port and raw SQL, and progressively removing each of those from model control via Toolbox's YAML-configured source primitive, read-only sources, allowed datasets, output-size caps, custom SQL tools with prepared statements, and finally bound or authenticated parameters that extract the user identity from a signed JWT instead of letting the agent pass it. Both runtime demos failed to load, so the security material was delivered from slides.",
    "key_points": [
      "MCP Toolbox for Databases: open-source, self-managed, ~15.7K GitHub stars, 132+ active contributors, 40+ databases, with connection pooling, integrated auth and observability out of the box; the Google-managed MCP alternative adds Model Armor for secure access management and identity control and plugs into Gemini CLI, Antigravity CLI and Claude Code. Combined, they served 20 million tool calls last month.",
      "Three database tool patterns: control-plane/admin tools (create and manage instances and databases, built on already-provisioned public APIs, need a human in the loop); NL2SQL via an 'execute SQL' tool where the agent writes raw SQL, for flexible exploration like 'find all customers in California who bought a winter coat in July and returned it within 14 days, grouped by acquiring marketing campaign'; and structured SQL tools for production, where the query and parameters are predefined — preventing SQL injection, cutting latency and reducing agent hallucination.",
      "Build-time tools are the first two patterns — atomic, flexible, human-in-the-loop, not runnable in production. Runtime tools are the deterministic structured ones (their example: a 'cancel order' structured SQL query) used inside end-user apps built with frameworks like Pydantic AI or LangChain.",
      "The build-time failure demo: the agent asked to delete the table and start fresh, and everything was deleted because there were no safeguards or guardrails.",
      "Security framing: 'your database is only as secure as your agent'; the confused deputy attack lets a user trick an agent into misusing its privileges, and Simon Willison's lethal trifecta means a breach when an agent simultaneously has private data, untrusted content, and the ability to expose that data back to an external user. Worked example: a malicious insider edits a ticket a triage agent reads, telling it to query the salary database and post all employee salaries back on the ticket.",
      "Separate three identities — user (only needs access to the application), application workload identity (broader, talks to other services), and agent (only the data the end user is entitled to) — and separate agent parameters (untrusted, dynamically derived) from application parameters (factual constraints kept outside the agent's control).",
      "Evolution of a secure tool in Toolbox: the source primitive moves host, port, credentials and connection details into a YAML file injected at MCP server start; sources can be locked to read-only down to the database driver (their #1 customer request), restricted to an enum of allowed datasets on cloud-native databases, and capped on output size as a blast-radius control; custom tools then pin the exact SQL statement plus tool name and description, run through prepared statements with typed parameters.",
      "Final step removes PII from agent control: bound parameters let the application authenticate the user and bind the value directly so the agent never sees the user identity; authenticated parameters have the tool validate an OpenID signed JWT and extract user claims (user ID, email, issuer). The lookup_flights tool ends up taking only a date — what they call zero trust architecture.",
      "Tool quality best practices: design for outcomes rather than atomic REST APIs to cut round trips; write descriptions as guidance without duplicating input parameter info; separate read and write tools so reads auto-approve and writes go to the user for confirmation; return actionable, retriable errors instead of a generic HTTP 404 ('the number one thing I think we can all do better'); and use flat, simple inputs because agents build complex maps and nested primitives unreliably.",
      "Eval bench, Google's evaluation framework for agentic, MCP and skills needs, is how they know the tools actually work."
    ],
    "takeaways": [
      "Don't ship your dev-assistant database tools to production — replace agent-generated SQL with predefined, parameterised structured tools defined in config, and reserve NL2SQL and control-plane tools for human-in-the-loop developer workflows.",
      "Strip everything from the tool signature the model doesn't need to decide: connection details into a preconfigured source, the SQL statement into a custom tool, and the user identity into a bound or authenticated (JWT-validated, claims-extracted) parameter — audit your tool schema until only genuinely dynamic inputs remain.",
      "Layer blast-radius limits on the source itself: read-only enforced at the database driver (not just by omitting write tools), an allow-list of datasets, and an output size cap.",
      "Split read tools from write tools so reads can be auto-approved and writes routed to explicit user confirmation.",
      "Rewrite tool errors to be actionable and retriable rather than generic HTTP status codes, and flatten complex input structures — agents act on good errors and fail on nested primitives."
    ],
    "topics": [
      "mcp",
      "agents",
      "databases",
      "security",
      "tool-design",
      "sql",
      "authentication",
      "evals"
    ],
    "tools": [
      "MCP Toolbox for Databases",
      "Google Cloud MCP server",
      "Google-managed MCP",
      "Model Armor",
      "Gemini CLI",
      "Antigravity CLI",
      "Claude Code",
      "Eval bench",
      "LangChain",
      "Pydantic AI",
      "Google Cloud",
      "GitHub"
    ],
    "quotes": [
      {
        "text": "agent actually asked to delete the table and start fresh. We deleted everything and there were no safeguard or guardrails here.",
        "at": "06:16",
        "url": "https://www.youtube.com/watch?v=9R--1tg45Jg&t=376s"
      },
      {
        "text": "the first thing that we need to know is your database is only as secure as your agent. We all know that agents and LMS are actually pretty easy to trick.",
        "at": "08:46",
        "url": "https://www.youtube.com/watch?v=9R--1tg45Jg&t=526s"
      },
      {
        "text": "Simon Willis actually coined the phrase the lethal trifecta. And a data breach occurs when an agent has simultaneous access to three different things. One, private data. Two, untrusted content. And three, the ability to expose that content and that data back to an external user.",
        "at": "09:16",
        "url": "https://www.youtube.com/watch?v=9R--1tg45Jg&t=556s"
      },
      {
        "text": "this is actually uh the next is actionable errors. This is the number one thing that I think we can all do better.",
        "at": "16:44",
        "url": "https://www.youtube.com/watch?v=9R--1tg45Jg&t=1004s"
      }
    ],
    "words": 3443
  },
  "summary_url": "/#9R--1tg45Jg",
  "transcript": {
    "html": "/transcripts/9R--1tg45Jg.html",
    "txt": "/transcripts/9R--1tg45Jg.txt",
    "vtt": "/transcripts/9R--1tg45Jg.vtt"
  }
}