Every parameter you leave in the tool is a permission you handed the model

Averi Kitsch and Prerna Kakkar of Google gave a talk published September 9 about why tools built for a developer’s laptop break when they reach production. Their split is clean. Build-time tools are the assistant lane: natural language to SQL, control plane admin, flexible, atomic, and requiring a human in the loop, which they illustrated with a clip of an agent asking to delete a table and start fresh because nothing was there to stop it. Run-time tools are what a shipped application calls, a fixed statement with typed parameters behind a named action like cancel order.

Then they walk one tool from the first shape to the second, and the walk is the argument. The first version hands the agent database credentials, the host, the port, and a raw SQL string, which makes it a superuser wearing a schema. Move the connection details into a configuration file the server injects and the agent no longer holds them. Replace the SQL string with a named query and prepared statements and the agent no longer writes the query. What is left is the user ID, and that is the interesting one, because it is the parameter that decides whose data comes back. They bind it from an authenticated token instead, so the agent never sees the identity it is acting for. The final tool signature takes a date.

They cite Simon Willison’s lethal trifecta for why any of this matters. The vault’s tool interface page says the same thing as a design rule: expose the minimum safe capability, prefer read-only and narrow scopes first, and enforce authorization outside the model rather than inside the prompt.

Concede that build-time flexibility is why people adopted these tools in the first place. Nobody explores a schema through a fixed query.

My version is shorter than theirs. The tool signature is the permission grant. Whatever is still in it, the model decides.