Write your own tools. Dont use something off the shelf. If you want it to read from a database, create a db connector that exposes only the capabilities you want it to have.

This is what I do, and I am 100% confident that Claude cannot drop my database or truncate a table, or read from sensitive tables. I know this because the tool it uses to interface with the database doesn't have those capabilities, thus Claude doesn't have that capability.

It won't save you from Claude maliciously ex-filtrating data it has access to via DNS or some other side channel, but it will protect from worst-case scenarios.

▲ ptx 7 hours ago | parent | next [-]

This is like trying to fix SQL injection by limiting the permissions of the database user instead of using parameterized queries (for which there is no equivalent with LLMs). It doesn't solve the problem.

	▲	Terr_ 4 hours ago \| parent [-]
		It also has no effect on whole classes of vulnerabilities which don't rely on unusual writes, where the system (SQL or LLM) is expected to execute some logic and yield a result, and the attacker wins by determining the outcome. Using the SQL analogy, suppose this is intended: `SELECT hash('$input') == secretfiles.hashed_access_code FROM secretfiles WHERE secretfiles.id = '$file_id';` And here the attacker supplying a malicious $input so that it becomes something else with a comment on the end: `SELECT hash('') == hash('') -- ') == secretfiles.hashed_access_code FROM secretfiles WHERE secretfiles.id = '123';` Bad outcome, and no extra permissions required.

▲ acjohnson55 3 hours ago | parent | prev | next [-]

This is reminding me of the crypto self-custody problem. If you want complete trustlessness, the lengths you have to go to are extreme. How do you really know that the machine using your private key to sign your transactions is absolutely secure?

▲ pbasista 7 hours ago | parent | prev | next [-]

> I am 100% confident

Famous last words.

> the tool it uses to interface with the database doesn't have those capabilities

Fair enough. It can e.g. use a DB user with read-only privileges or something like that. Or it might sanitize the allowed queries.

But there may still be some way to drop the database or delete all its data which your tool might not be able to guard against. Some indirect deletions made by a trigger or a stored procedure or something like that, for instance.

The point is, your tool might be relatively safe. But I would be cautious when saying that it is "100 %" safe, as you claim.

That being said, I think that your point still stands. Given safe enough interfaces between the LLM and the other parts of the system, one can be fairly sure that the actions performed by the LLM would be safe.

▲ alienbaby 7 hours ago | parent | prev | next [-]

Until Claude decides to build its own tool on the fly to talk to your dB and drop the tables

	▲	spockz 6 hours ago \| parent [-]
		That is why the credentials used for that connection are tied to permissions you want it to have. This would exclude the drop table permission.

▲ nh2 7 hours ago | parent | prev [-]

Unclear why this is being downvoted. It makes sense.

If you connect to the database with a connector that only has read access, then the LLM cannot drop the database, period.

If that were bugged (e.g. if Postgres allowed writing to a DB that was configured readonly), then that problem is much bigger has not much to do with LLMs.