Comment by arjie
5 days ago
For the database, I use a read-only user. I also give it full R/W to a staging DB and the local dev DB. Even if it egresses that, nothing can happen.
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.
Are you comfortable giving LLM read access to fields that have PII? Anything related to authentication? Is it allow-list of access or a deny-list?
I am comfortable with that in dev/staging DB (it's my own PII which I don't mind). I use separate secrets for staging vs. prod so I don't mind giving full bore access to staging.
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.