来源笔记
Proxies, Sandboxes and Agent Security
摘要
这篇文章描述了一种实用的安全设计，用来让 AI SRE 管理家庭实验室，同时不把真实服务凭据暴露给代理。它使用凭据注入 HTTP 代理，并考虑用 gVisor 沙箱做更严格的网络控制。
问题
- SRE 代理需要访问 GitHub、Kubernetes、Grafana、Todoist、Matrix 和其他工具，这会带来凭据暴露风险。
- 通过网页或文档进行提示注入，可能让代理读取密钥，并通过正常网络请求把它们发出去。
- 在这个设置里，破坏性命令的风险更低，因为代理运行在无 root 容器中，作者也把重要状态保存在 git 里。
方法
- 在代理容器里放入假凭据，例如
fake-todoist-token，并把 HTTP 和 HTTPS 流量转到凭据代理。 - 配置代理在特定主机和标头上，把假 token 替换成真实 token，例如
api.todoist.com的Authorization和api.parallel.ai的x-api-key。 - 把代理的 CA 证书加入容器信任存储，这样代理可以检查并改写 HTTPS 请求。
- 在基于 gVisor 的沙箱里使用允许或拒绝域名规则，在应用代理层之下拦截外发请求。
结果
- 文章没有给出定量基准结果、数据集或准确率指标。
- 文中没有声称有突破性结果；最强的说法是基于代理的 token 注入可以把真实凭据排除在代理容器之外。
- 这套代理设计至少处理了 3 个示例服务的凭据注入：Todoist、Parallel 和 Matrix。
- 作者发现了 2 个具体的代理集成故障：带 Playwright 的 Chrome 没有使用代理 CA，Matrix 客户端路径因为库行为没有遵守
HTTP_PROXY。 - 关于 gVisor 沙箱的说法很具体，但没有测量：即使应用忽略
HTTP_PROXY，它的 Go 网络栈也可以拦截外发请求。