Overall it's been great. However, I find myself having to review every single command, a lot of which are repetitive. It still saves me a ton of time, but it's quickly becoming a bit tedious
I wish I could give the agent some more autonomy. Like giving it a list of pre-approved commands or actions that it is allowed to run over ssh
For example:
OK: ls, grep, cat, tail
Not OK: rm, mv, chmod, etc
OK: SELECT queries
Not OK: INSERT, DELETE, DROP, TRUNCATE
What setups have actually worked for you, and where do you draw the line between autonomy and risk?
I recommend giving LLMs credentials that are extremely fine-grained, where the credentials can only permit the actions you want to allow and not permit the actions you don't want to allow.
Often, it may be hard or impossible to do this with your database settings alone - in that case, you can use proxies to separate the credentials the LLM/agent has from the credentials that are actually made to the DB. The proxy can then enforce what you want to allow or block.
SSH is trickier because commands are mixed in with all the other data going on in the bytestream during your session. I previously wrote another blog post about just how tricky enforcing command allowlists can be as well: https://www.joinformal.com/blog/allowlisting-some-bash-comma.... A lot of developer CLI tools were not designed to be run by potentially malicious users who can add arbitrary flags!
I also have really appreciated simonw's writing on the topic.
Disclaimer: I work at Formal, a company that helps organizations use proxies for least privilege.
I've found as well that while you can run agents with a lot of tools and set them free autonomously they tend not to be prompted correctly by default to not get enormously stuck and do really dumb things along the way.
Never open pandoras box without understanding the implications and principle of least privilege and trust apply at every layer of the equation now
Giving LLM even read access to PII is a big "no" in my book.
On PII, if you need LLMs to work on production extracted data then https://github.com/microsoft/presidio is a pretty good tool to redact PII. Still needs a bit of an audit but as a first pass does a terrific job.
E.g. I used this method when I wanted to carry out a large (almost every source file) refactoring of Cytoscape.js. I fed the LLM a bunch of examples, and I told it to write a script to carry out the refactoring (largely using regex). I reviewed the script, ran the script, and then the code base was refactored.
At the time, agents were not capable enough of doing large-scale refactors directly, as far as I was aware. And the script was probably much faster, anyway.
Claude code runs in a container, and I just connect that container to the right network.
It's nice to be able to keep mid-task state in that environment without stepping on my own toes. It's easy to control what data is accessible in there, even if I have to work with real data in my dev environment.
Among the many other reasons why you shouldn't do this, there are regularly reported cases of AIs working around these types of restrictions using the tools they have to substitute for the tools they don't.
Don't be the next headline about AI deleting your database.
Do you mean "Don't give it more autonomy", or "Don't use it to access servers/dbs" ?
I definitely want to be cautious, but I don't think I can go back to doing everything manually either
You get a lot of leverage that way, but it's still better than letting AI use your keys and act with full autonomy on stuff of consequence.
Agents are here. Maybe a fad, maybe a mainstay. Doesn't hurt to play around with them and understand where you can (and can't) use them
No need to mess around with regular expressions against SQL queries when you can instead give the agent a PostgreSQL user account that's only allowed read access to specific tables.
How do you provide db access? For example, to access an RDS db, you have to connect from within the AWS/EC2 environment, which means either providing the agent ssh access to a server, from which it can run psql, or creating a tunnel
Additionally, with multiple apps/dbs, that means having to do the setup multiple times. It would be nice to be able to only configure the agent instead of all the apps/dbs/servers
I'll set it loose on a development or staging system but wouldn't let it around a production system.
Don't forget your backups. There was that time I was doing an upgrade of the library management system at my Uni and I was sitting at the sysadmin's computer and did a DROP DATABASE against the wrong db which instantly brought down the production system -- she took down a binder from the shelf behind me that had the restore procedures written down and we had it back up in 30 seconds!
You cannot. The best you can ever hope for is creating VM environments, and even then it's going to surprise you sometimes. See https://gtfobins.github.io/.
SSH I just let it roll because it's my personal stuff. Both Claude and Codex will perform unholy modifications to your environment so I do the one bare thing of making `sudo` password-protected.
For the production stuff I use, you can create an appropriate read-only role. I occasionally let it use my role but it inevitably decides to live-create resources like `kubectl create pod << YAML` which I never want. It's fine because they'll still try and fail and prompt me.
For prod DB read-only I just add tables/columns as they become relevant (so it's allowlist). Claude usually sequences table schema and stuff from staging DB / local migrations and then reads prod DB. When it fails access to something I decide if I want to give it or not. It eventually reaches a stage where I'm comfortable with always starting my day with `claude --dangerously-skip-permissions --continue`.
The prod DB read/write creds are in company 1password which I don't have app installed (I rarely need company creds). LLM maybe could figure out some way to get into my Bitwarden which I do routinely use but short of creating and running keylogger I think it's fine.
It's mildly annoying you have to periodically `GRANT SELECT` but now I'm much more careful organizing the schema in an LLM-friendly way. Postgresql can do column-security and I'm forced to use that sometimes but I refactored design to just be table-level.
For SSH, you can either use a specific account created for the AI, and limit it's access to what you want it to do, although that is a bit trickier than DB limits. You can also use something like ForceCommand in SSHD config (or command= in your authorized_keys file) to only grant access to a single command (which could be a wrapper around the commands you want it to be able to access).
This does somewhat limit the flexibility of what the AI can deal with.
My actual suggestion is to change the model you are using to control your servers. Ideally, you shouldn't be SSHing to servers to do things; you should be controlling your servers via some automation system, and you can just have your AI modify the automation system. You can then verify the changes it is making before committing the changes to your control system. Logs should be collected in a place that can be queried without giving access to the system (Claude is great at creating queries in something like ElasticSearch or OpenSearch).
https://github.com/dolthub/dolt
Personally I think the right approach is to treat the llm like a user.
So if we pretend that you would like to grant a user access to your database then a reasonable approach would be to write a parser (parsing > validating) to parse the sql commands.
You should define the parser such that it only uses a subset of sql which you consider to be safe.
Now if your parser is able to parse the command of the llm (and therefore the command is part of the subset of sql which you consider to be safe) then you execute the command.
cat /dev/random > /dev/sda
Uh oh…
This is nothing new; it’s the logical thing for any use case which doesn’t need to write.
If there is data to write, convert it to a script and put it through code review, make sure you have a rollback plan, then either get a human or non-AI automation tooling to run it while under supervision/monitoring.
Again nothing new, it’s a sensible way to do any one-off data modification.
It would be nice to just be able to solve it through instructions to the agent, instead of having to apply all the other things for each application/server/database that I'd like to give it access to
What I imagine is you might instruct an agent to help you set up the restrictions for various systems to reduce the toil. But you should still review what the agent is going to do and make sure nothing stupid is done (like: using regexes to filter out restricted commands).
Can create scripts or use stuff like Nix, Terraform, Ansible or whatever to automate the provisioning of restricted read only accounts for your servers and DBs.
You want to limit access to files (eg: regular user can't read /etc/shadow or write to /bin/doas or /bin/sh) - and maybe limit some commands (/bin/su).
As for queries, you might be able to achieve the same thing with usage of command-line tools if it's a `sqlite` database (I am not sure about other SQL DBs). If you want even more control than the settings.json allows, you can use the claude code SDK.
How would you go about allowing something like `ssh user@server "ls somefolder/"` but disallowing `ssh user@server "rm"`?
Similarly, allow `ssh user@server "mysql \"SELECT...\""`, but block `ssh user@server "mysql \"[UPDATE|DELETE|DROP|TRUNCATE|INSERT]...\""` ?
Ideally in a way that it can provide more autonomy for the agent, so that I need to review fewer commands
I'm not familiar with rbash, but it seems like it can do (at least some of) what you want.
But do not run this on prod servers! You cannot prompt your way into the agent not doing something stupid from time to time.
Also blacklisting commands doesn't work (they'll try different approaches until something works).
https://stackoverflow.com/questions/35830509/sshfs-linux-how...
adduser llm su llm
There you go. Now you can run commands quite safely. Add or remove permissions with chmod chown and chgrp as needed.
If you need more sophisticated controls try extensions like acl or selinux.
In windows use its builtin use, roles and file permission system.
Nothing new here, we have been treating programs as users for decades now.
Also, about those specific commands:
* `cat` can overwrite files. * `SELECT INTO` writes new data.
Use db permissions with read only, and possibly only a set of prepared statements. Give it a useraccount with read-only acces maybe
—-
Yes, easily. This isn’t a problem when using a proxy system with built in safeguards and guardrails.
‘An interface for your agents.’
Or, simply, if you have a list of available tools the agent has access to.
Tool not present? Will never execute.
Tool present? Will reason when to use it based on tool instructions.
It’s exceptionally easy to create an agent with access to limited tools.
Lots of advice in this thread, did we forget that ithe age of AI, anything is possible?
Have you taken a look at tools such as Xano?
Your agent will only execute whichever tool you give it access to. Chain of command is factored in.
This is akin to architecting for the Rule of Two, and similarly is the concept of Domain Trusts (fancy way of saying scopes and permissions).