I recommend everyone to move your plantext secrets from ~/.kube/config, ~/.ssh etc into a password-manager. You can tell Claude to adjust the config files to get the secrets from 1Password when they are needed with TouchID requirements etc.
These days I’m getting so many 1Password prompts for agents pulling env variables out of it and with very little context of what is being accessed by who (The dialog 1Password shows is pretty bad) that it would be very easy for something to slip in there.
> I’m getting so many 1Password prompts for agents pulling env variables out of it and with very little context of what is being accessed by who
This is a one-sentence horror story. I almost can't believe someone would let this happen, unless the 1Password account is not important (highly unlikely).
I know it sounds bad, but it’s the reality for most people, just like permission prompts at every corner and after each macOS / app update (“Your screenshot app is watching your screen”, no shit, that’s why I installed it).
The dirty little secret of our industry is that everyone runs agents with full disk access on their machines as there's no good way to sandbox it. This also precisely why Apple posted a newsroom article a few days ago about this topic: https://developer.apple.com/news/?id=p6zjojqw
Blaming this on the user is a bit like blaming someone for doing their banking on their regular day to day computer instead of an air gapped machine.
Yeah, I don’t know about that. We use VDI and dedicated agent accounts. Sort of like I’ve got my super user account for production server access via a different VDI, now I’ve got my -agent account for the agent VDI.
The nice thing is that using the private key requires physical touch. That means that AI itself (or a remote attacker, for that matter) can't do things unless I confirm.
> The nice thing is that using the private key requires physical touch.
Yeah (not talking about crypto): yubikeys (or similar) are really sweet for that. I've use them for ssh / pushing / fetching from Git etc. I use them for 2FA to various services etc.
There are also similar devices where you enter a PIN and the PIN to register to a service the first time and then the PIN to auth are different. So you can't be tricked by mistake to register to a new service when you just want to auth (you could still be tricked to register to a service which ain't the one you think while registering, but never while auth'ing).
And yup I use that with AI all the time: my agents go inside a container or inside a VM (or both), and the damage it can do is very limited.
It's also possible to do passthrough of devices (GPU, USB, ...) to VMs: good stuff.
It's not protected by the index finger at all. There is no fingerprint reader in a Yubikey. The only protection is that it requires physical access and can't be triggered from software.
It does help in that the secrets are not in plain-text, readable for any script you run. With 1Password, a process asks for the password and it gets transferred not through the filesystem but through IPC. 1Password shows a dialog: "Do you want iTerm to get your SSH key ABC123?"
In my thinking, this is more secure than plaintext in filesystem
If your system is compromised, it doesn't matter what you are using: the attacker will get the password for whatever secure thing you store your secrets in.
Maybe. Maybe not. It depends on the sophistication of the malware. Generally my impression is that these install-script type attacks cast a wide net. I would hazard a guess that they would not know how to even ask my 1Password for the keys. They are in an account they dont know, in a vault they dont know, and have a name they dont know
They don't need to ask 1Password for the keys, right? They can just take the kubectl auth once 1Password provided the key. But I would also bet any halfway competent script kiddy can vibecode credential stealing for the top 3 password managers these days. Heck, even open source red team stuff like this have it: https://github.com/efchatz/pandora
Not necessarily. defense in depth can help. At least forces an attacker to have to chain exploits, which although not impossible it makes it harder. Having root on a system doesn’t necessarily give you access to things that require touchid/yubikey/presence.
as for ssh keys, you can generate your keypair in secure enclave and reuiqre touchId for every new ssh session. The private key never leaves the secure enclave.
we have thought about it, but its a name we came up ourselves, fits the bill and we have the domain for it. Can't ask for much more. its pretty rare for google to be our inbound and when we get to that point we would probably overtake that in SEO anyway
I have a small ChatGPT subscription and a skill i run pre-commit post-Claude that goes through every file and rewrites all english sentences, removes comments and replaces dense terms in variable and function names. It usually reduces comments by ~80%
The pattern of piping an arbitrary script to your shell? This should be an ordinary app bundle to drop into /Applications, or be distributed as an installer.
The readme even says so itself:
> A bad curl | sh, a sketchy npm install, or one of the AI agents now running in your editor with your full permissions.
And then, two paragraphs down, it suggests to do just that to install…
It's not piped to a shell, but to the tar program with specific parameters to directly unpack the tar.
You're still installing the program directly from github of course, instead of a source where hopefully a third party has also looked at it (like a package repository). But this is a lot better than the curl | sh pattern.
You're not downloading from github, but from dl.jitpass.com.
And an executable can do exactly the same as a shell script. The point is that whatever you're executing isn't verified, whether it's a shell script or a binary.
Is there McAfee for Mac? There's no real difference. You're trusting someone not to root your shit. Whether it's via curl, dmg, or apt, we have no idea who anybody really is, so it's all on an assumption that people aren't evil. Unfortunately it turns out that there are evil people out there, but doing it via curl | bash or downloading a dmg or though some app store, there's still evil that's gonna get you if you end up trusting in the wrong people.
But it’s not piping a script into the shell. It’s curl downloading a compressed archive and piping it to tar to decompress the program binary from the archive. Then moving the extracted binary into /usr/local/bin.
It mostly hurts people in countries with weak purchasing power. DS was the main game in down for them.
Personally, I don't think we've seen the total end of dirt cheap LLMs, it's just a frontier lab doesn't want to be in business of serving half the world.
Thank you for bringing that up, such a rarity for this place to remember the other 80% of the world.
As someone from just such a country, DeepSeek 0731 was the first time I seriously started using an LLM for coding. All previous attempts were useless or ridiculously expensive.
Can't say the old prices felt "free", but it was affordable if you're careful with your cache hit rate.
The new pricing probably pushed it into the unaffordable territory for tasks where you can do without it. Probably will try opencode go if they don't also follow suite, or will have to go back to wetware.
There's a lot more competition over smaller models. Ferraris are frontier labs' main differentiating point when Hondas are increasingly open source and commoditized.
Package management provides cryptographic attestation over the entire process, including the scripts run. Nothing is arbitrary nor mutable in the default state. The files touched will be in a predictable place and the scope of privilege escalation is clearly defined.
It's more about installation location for me. For these types of projects, I don't even install it. I just clone, build and run from there. I have no idea where the bash script is going to put things.
I mean it's probably not, I just haven't got used to it yet. It's about the same level of security as installing a windows app on win2000 25 years ago and blindly downloading a .exe off the internet and running it to get into the install wizard. But indeed I also kind of blindly trust that whatever I'm getting from the debian trixie officially gpg-signed packages isn't backdoored.
One thing I do not do as a matter of practice is install things with a ridiculous number of recursive npm dependencies.
I do not blindly trust anything, and come to the conclusion that downloading binaries from Debian trixie is a lot more safe. There is a world of difference between "curl | sh" and downloading from a curated package repository maintained by a respected community with well-defined processes.
Im working on an extensible and flexible agentic connectivity platform (MCP, OpenAPI/Swagger, FaaS) with niceties like built-in CodeMode, compression, SIEM integration, access token forwarding, SCIM 2.0, on-demand agentic sandboxes (e.g. LangChains "Deep Agents").
For private use not that useful tbh (although i found the OpenAPI -> MCP mapper useful), but found sales success with organizations with more complex agentic setups.
I agree with parent. OpenRouter might be cheaper list-price, but i have been using 10$ on DS platform since April/May, still have 2$ left. Using OpenRouter i depleted the same dollar-amount in a 1-2 weeks with same usage pattern. No idea why.
Not used it but from perusing forums, consensus is OpenRouter has terrible/broken caching for Deepseek wildly inflating token use. The cache metrics are visible so you can verify for yourself (apparently, it's what others have done).
I started doing it, but I would also try to make it more generic, so you can deploy it as an app in your cluster so you don't need necessary a terminal.
But I'll consider the idea. Thanks a lot for the feedback
reply