第一层：文件隔离
最基础但最有效的一招——把敏感数据和普通数据物理分开。
建一个 vault 目录专门存敏感文件，权限设成 700，只有本用户能访问。Agent 的工作目录和 vault 彻底分开，规则里写死：禁止读取 vault 路径。
普通数据放 data 目录，只存脱敏后的摘要。比如健康数据只存「本周平均睡眠 7 小时」，不存具体几点睡几点起。这个思路其实很简单，但真正做到的人不多。
第二层：Prompt 层面的硬限制
系统提示词里直接写死两类规则：
禁止访问的路径：
vault/、memory/- 任何包含
credentials的路径 .env、config.json
禁止输出的内容：
- API Key、Token、密钥
- IP 地址、端口、用户名
- 个人配置、cron 任务设置
- 任何「我的配置」「我在用的」这类第一人称经验描述
说实话，光靠 Prompt 限制不是百分百可靠，但它是成本最低的一道防线，不写白不写。
第三层：输出过滤
发送前用正则扫一遍，匹配常见的敏感模式：
- 手机号、银行卡号、身份证号
- API Key（长字符串、特定前缀比如
sk-） - IP 地址
匹配到就替换成占位符，或者直接拦截不发。这一层是纯代码逻辑，不依赖 LLM 的「自觉性」，比 Prompt 限制靠谱得多。
第四层：内容来源审核
要发到公开平台的内容，加一条硬规则：只能用公开来源的信息。
可以用的： 官方文档、GitHub 公开仓库、公开新闻。
不能用的： 本地配置、私有数据库、个人聊天记录。
这条规则看起来简单，但在实际写 Agent 逻辑的时候特别容易忽略。Agent 有权限读本地文件，它不会自己区分哪些能公开哪些不能，你得替它划线。
第五层：发布前人工确认
高风险场景，先存草稿，人工确认后再发。或者开个测试模式，内容不真正发出去，先打印到终端检查一轮。
我自己的做法是先跑一段时间测试模式，确认没问题了再切到正式发布。没想到这个步骤拦下来不少问题。
落到代码里才算数
光写文档没用，要在脚本里硬编码这些检查：
- 启动时检查当前目录，如果在敏感目录下直接退出
- 读文件前检查路径白名单
- 发送前扫描敏感模式，匹配就拦截
- 日志记录每次发送内容的摘要，方便事后审计
兜底方案也得有
万一真发出去了，要能快速删。保留每条内容的 ID，发现问题立即调删除接口。定期回顾已发布内容，人工抽查有没有漏网的。
隔离、限制、过滤、审核、兜底，五层叠起来，单独一层都不完美，但组合在一起风险就压得很低了。搭 Agent 自动化的时候，功能跑通只是第一步，防住不该发的东西才是真正能长期跑下去的关键。