0o_MrPatrick_o0's comments

Thank you for the pointers!!

Some notes on using SSH-AGENT to protect your private keys from AI Agents while allowing them ssh access using those keys.

because you're trusting Claude's implementation of hooks, which may be disastrous if they have a defect.

Amazing tip! Thank you!

Hey man- sorry for the lack of recognition. Timing is a bit of luck. Good writeup!

w/r/t .git being mounted read write- yeah, there's risk here. It's a tradeoff. I want my agents to be able to commit code- which means they need to be able to write to the dir.

Thanks for the --new-session parameter suggestion. Great add!

Heya- The reason I add this directory is because Claude needs read/write permissions for getting new auth tokens.

Without this, you'll have to re-login to Claude every time. Breaks the speed of development.

I'm going to do some experimenting to see if I can make this bind more precise.

Using IaC tools gives you the following advantages:

1. IaC gives you Idempotent solutions- which is advantageous over an agent. What if the agent crashes half way through deployment procedures? How will you reliably resume an interrupted install?

2. IaC gives you reproducible builds

3. IaC gives you ability to install tools in a way that can be tested for compliance with any deployment standards you have

W/r/t frontier models:

Just tell them to go install stuff. They already have so much in their training corpus that you literally do not need to create this.

7b-14b parameter self hosted models may get some benefit from your approach. I find self hosted is less reliable for tasteful approaches. Micromanagement yields better results.

Author should explore Ansible/Puppet/Chef.

I’m not sure this solution is needed with frontier models.

You’ve got my intent correct!

Where I’m at with #2 is the agent builds a prototype with its own private session credentials.

I have orchestration created that can replicate the prototyping session.

From there I can keep final build keys secret from the agent.

My build loop is meant to build an experiment first, and then an enduring build based on what it figures out.

Great question! You might enjoy this writeup, which in one section explores avoiding the use of shell variables that are not exported as a method of mitigating this risk.

https://linus.schreibt.jetzt/posts/shell-secrets.html

If your prompt is complex enough, doesn’t seem to get triggered.

I use a lot of ansible to manage infra, and before I learned about ansible-vault, I was moving some keys around unprotected in my lab. Bad hygiene- and no prompt intervening.

Kinda bums me out that there may be circumstances where the model just rejects this even if you for some reason you needed it.

Hi!

Yes that is correct. However, I think embedding bubblewrap in the binary is risky design for the end user.

They are giving users a convenience function for restricting the Claude instance’s access rights from within a session.

Thats helpful if you trust the client, but what if there is a bug in how the client invokes the bubblewrap container? You wouldn’t have this risk if they drove you to invoke Claude with bubblewrap.

Additionally, the pattern using bubblewrap in front of Claude can be exactly duplicated and applied to other coding agents- so you get consistency in access controls for all agents.

I hope the desirability of this having consistent access controls across all agents is shared by others. You don’t get that property if you use Claude’s embedded control. There will always be an asterisk about whether your opinion and theirs will be similar with respect to implementation of controls.

Wonderful insight! Thank you!

Man- I am noticing so many people are writing and ruminating on the defense of the .env file right now!

I can't tell if the project name ("memevault") implies that this is a real tool or a jab at us ruminating weirdos X'D