明白,目标锁定成:对端拿到的附件里,除了 prompt 和 png/jpg/mp4,全是解不开的密文。方案按这个收紧:
客户端 base_url 指到你的网关(LiteLLM 这类),别做 TLS 中间人。网关里按 MIME + magic bytes 分流:prompt 与图片/视频明文直通,其余附件在网关内加密后替换 part 再转发。
「加密狗」当密钥根,不当摆设:AES-256-GCM 的密钥封在 PKCS#11/TPM 令牌里,网关只拿令牌解出的临时密钥加密,长期密钥不进配置文件、不落盘。拔掉令牌,网关就拒绝生成密文——这才是你要的「确保」。
对端是公共 API(OpenAI/Claude 这类)时,密文附件它读不了,对应功能等于废掉,这正是你说的「收到的都是废物」。要模型还能读,只能在你自己的网关解密后转发。
每个密文外挂一个 manifest(算法/key id/原文件名/类型),否则收方不知道解出来是什么。
每次加密/放行写审计日志:谁、何时、对哪些文件。
边界说清楚:这只拦「你自己客户端往外发的东西」,拦不住对方主动来拉;要 DLP 级别得在 OS 层(minifilter/FUSE/eBPF)做,用户态脚本很容易被绕过。