| HN Mirror

"please get all the entries from the table foo and then remove them all"

SELECT * from foo; DELETE FROM foo ...

...because you know people will deploy a general SQL function or agent

That'S not how it works. The user questions are expressed in business-domain language.

"give me the names of all the employees and then remove them all"

is parsed, maybe as: " employees(), delete(employees())".

It's up to the programmer to define the available functions, if employees() is available, then the first result will be provided, if not it won't.

If the functoin delete with a list of employees as parameter is defined, then that will be executed.

I personally work with existing implementations, traditional software that predates LLMs, typically offered through an API, there's a division of labour, a typical encapsulation at the human organizaiton layer.

Even if you were to directly connect the database to the LLM and let GPT generate SQL queries (which is legitimate), the solution is user/role based permission, a solution as old as UNIX.

Just don't give the LLM or the LLM user-agent write permissions.

> That'S not how it works

They are actually quite flexible and you can do anything you want. You supply the LLM with the function names and possible args. I can easily define "sql(query: string)" as a flexible SQL function the LLM can use

re: permissions, as soon as you have write permissions, you have dangerous potential. LLMs are not reliable enough, nor are humans, which is why we use code review.

Correct, by "it" I was referring specifically to the "Tools" functionality that is the subject of the linked article.

Tools DON'T generate sql queries, they generate function calls. Of course you can hack it to output sql queries, you can always hack something beyond its intended design purpose, but it's not what it's supposed to be doing.

Re: permissions, nothing new here, give your LLM agent the permissions of a Junior DBA.

viraptor 726 days ago

1. Lots of libraries prevent you from submitting multiple queries. It's a good idea to do that in general.

2. If only the second part of my message covered this...

1 & 2. requires that you audit the agents and have uniform permissions, or additional plumbing to lookup user permissions and pass those along.

Have you looked at the agents prepackaged in popular frameworks? They aren't doing permission propagation or using additional libraries as guardrails.

What are most people going to do? This is why people are hesitant and ask about auditability

Considering 2 further, I only described deletion. A read-only database is of limited value. If you have write permissions, you could alternatively change values maliciously, even if you disable deletions. This might not be a malicious, and could be the result of an LLM error or hallucination.

btw that's not how tools work at all. Tools are function/API based. (Unless you expose a function run_sql(query), but that's on you.)

I brought it up because popular frameworks are offering this type of agent or function out of the box

There is no "way that tools work"

You pass OpenAPI like schemas along with the prompt and you get back a JSON object. The rest is code and you can do anything you want with. The LLM is merely mapping from unstructured text onto a schema best it can, and we know they are imperfect.

https://en.wikipedia.org/wiki/Robustness_principle

"be conservative in what you send, be liberal in what you accept"

LLM parses text into a list of parameters. You design your function such that it is safe regardless of what the parameters are.