Hacker News Reader

Comment by veganmosfet | Hacker News Reader

The reseller could use an intermediate proxy and modify the traffic like in [1], to get control of the client machine - depending on the harness permissions.

TLS terminates at the proxy (say, https://reselltokens.ai), end to end integrity is not enforced. LLM traffic contains tool calls like "bash ...", which are executed on the client machine, they can be manipulated. Secret exfil is also possible.

[1] https://arxiv.org/html/2604.08407v1

View on HN

You can place your own CLIProxyAPI instance in front of the reseller proxy and block prompts/responses that look harmful.

There are community plugins like this: https://github.com/rheodev/cpa-plugin-privacyfilter

I haven't tried the plugin system myself yet.

I swear every time I think I have a unique tweak for an OSS tool, it turns out someone else did it. I forked CLIProxyAPI myself to add something similar, though my implementation is closer to a provider-egress DLP layer and it's intended for API keys and the like, not PII. It uses gitleaks but also supports reversible redaction so a secret that's flagged can be replaced with a placeholder before CLIProxyAPI sends the request to the provider and then any instances of that placeholder can be rehydrated in the response to the caller.

Since it modifies logic across the full request/response lifecycle, I unfortunately couldn't implement it cleanly with the existing plugin API.

Nice, he can help fix my Linux Bluetooth audio issues.

they have no reason to do that to harm their reputation if their goal is profit, in which in this case it is.

sure, but malicious actors could act as resellers and exploit the situation.

Reply on news.ycombinator.com