zlacker

I imagine your best bet are exactly the same tools for a potentially-malicious human user: Separate user account, file permissions, database user permissions, etc.

>>Terr_+(OP)
This is probably the safest thing to do, also the most time consuming

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

>>nico+dh
That would be nice. If only the agent had the ability to limit itself to your instructions.

>>nico+dh
Yeah but this is like exposing `sudo eval $input` as a web service and asking the clients to please, please, not do anything bad.

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.

>>nico+dh
The restrictions have to be enforced by the non-LLM deterministic control logics (in the OS/database/software, or the agent's control plane). It cannot be just verbal instructions and you expect the LLM not to generate certain sequences of tokens.

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).

>>nico+dh
That's equivalent to client-side security.

>>nico+dh
Shouldn't you already be using low privilege accounts for stuff like gathering information about prod?

Overprivileged accounts is a huge anti-pattern for humans too. People make mistakes. Insider threats happen. Part of ops is making it so users don't have privileges to do damage without appropriate authorization.