Comment by SillyUsername | Hacker News Reader

Comment by SillyUsername | Hacker News Reader

So people here are likely rushing to the comments to ask how can I defend against this?

Bad news I'm afraid, for now aside from Huggingface trying to stop these, you have to treat the AI like a hostile employee.

- Don't give your AI secrets access, scope it's fs access as a limited user.

- Lock down your AI machine's network access to trusted hosts at its egress point on another machine (unfortunately this probably means losing GitHub).

- Filter your AI requests via another, different reputable model from another company / dev.

- Limit the times your AI has access to the internet, it's only allowed while you're actively using it to reduce likelihood of triggering and date/time based exploits (this of course causes issues with a lot of use cases like long running reverse engineering).

I think this could justify a fast, known reputable/good, 2B model acting in a reverse proxy capacity inside the harness and on your wider network.

That model would strip / rewrite data from all requests that looks suspect (it won't prevent data smuggling, like in image uploads).

It would also block domains BAU for a proxy using an allowlist.

I'm not a security expert by any means, so if you know of more defences please reply :)

I would figure that in an enterprise setting (where the stakes are highest) having an AI gateway sit in the middle of the prompt to the LLM and its response would mitigate a lot of the concerns over using untrusted models (all of them).

This is one of the insane things about the popularity of LLMs that continues to astound me. It is SO EASY for an LLM provider to collect vast amounts of PII or misdirect their customers in extremely subtle ways without noticing. It's already known that most LLM users don't fully read its (verbose by default, possibly on purpose) output and it's also known that LLM providers train on chats.

One annoying thing having a guard model is ensuring its FP rate is low enough to not be a headache, and its FN rate low enough to be worthwhile to use. Likely also means you’ll need to either use a frontier-close model, further increasing costs as well as round-trip time.

Or maybe some system 1 model?

For my setup, i have claude code in its own VM, whose VLAN is heavily restricted outside of the internet, my forgejo instance, infisical for secrets, and one way SSH from my machine to the VM.

All secrets are shared via infisical secrets store, so the actual secrets are never shown to the agent. Dev mode can be used for running the system locally during development, and those secrets may be seen in some cases. The foregjo user the agent has access to can only create issues and PRs. Manual merge required, after which a CI pipeline handles the packaging and “production” deployment of the app to my app server VM.

I think a setup like that (or discouraging these agents access to the same computer people keep their finances/health data etc) should be discussed/championed more.

My work encourages just running the harness on their system (which I get for practical reasons among others), to which I then put my work laptop on its own VLAN.

Overkill, for sure. But to me the risk of personal data exfiltration is far too high with these vibe coded harnesses and models which are more and more opaque.

Reply on news.ycombinator.com