AI Agent 数据隐私新防线：用 Gate 自动脱敏 PII 信息，无需修改任何 Prompt
当 AI Agent 开始查询数据库、调用内部 API 时，一个隐形问题悄然浮现——Agent 的输出中可能包含用户邮箱、手机号、身份证号等敏感信息。这些数据一旦进入 LLM 的上下文窗口，就无法追溯、无法审计、无法撤回。
本文介绍 Gate——一个轻量级、确定性的 PII 脱敏工具，通过在 Agent 工具调用链中插入一层拦截，自动识别并遮蔽敏感字段，且无需修改任何 Prompt 或工具代码。
问题：AI Agent 查询数据时，敏感信息怎么保护？
假设你的 Claude Code 连接了 PostgreSQL 数据库，让 Agent 执行 SELECT * FROM users LIMIT 5。结果是：
[
{ "id": 1, "name": "张三", "email": "zhangsan@gmail.com", "phone": "13800138000", "card_no": "6222021234567890" },
{ "id": 2, "name": "李四", "email": "lisi@company.com", "phone": "13912345678", "card_no": "6222039876543210" }
]
这些完整数据被写入 LLM 的 Token 上下文中——在模型推理、记忆写入、日志记录的过程中，每个环节都可能成为泄露点。传统方案要么依赖同义的提示词约束（”不要泄露 PII”），要么依赖数据库层面的列级脱敏（DDM），但两者都有明显缺口：Prompt 约束可以被绕过，DDM 无法覆盖 MCP 工具和外部数据库。
Gate 是什么？
Gate（62⭐, MIT, Rust）是一个确定性的隐私边界工具。它在 AI Agent 的工具调用链中插入一个拦截层——无论是通过 Bash 命令查询数据库，还是通过 MCP 协议调用工具，Gate 都能在数据到达 LLM 之前自动检测并遮蔽 PII 字段。
核心特性：
| 特性 | Gate | 基于 LLM 的脱敏 |
|---|---|---|
| 决策方式 | 正则 + 列名启发式 + Luhn 校验 | 模型推理 |
| 确定性 | ✅ 相同输入始终相同输出 | ❌ 每次运行可能不同 |
| 数据本地 | ✅ 永不离开本机 | ❌ 需发送到模型 API |
| 延迟 | ✅ <10ms 开销 | ❌ 额外 API 往返 |
| 可审计 | ✅ 每条决策可追溯至明确的规则 | ❌ 模型推理不透明 |
快速上手
安装
brew tap GaaraZhu/gate && brew install gate cargo binstall gate
初始化配置
gate config # 打开编辑器创建 ~/.config/gate/config.yaml
扫描数据库 Schema 中的 PII 风险
连接数据库之前，先用 gate scan 评估 Schema 暴露了多少敏感列：
psql -U myuser -h localhost -d mydb \ -c "SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'public'" \ | gate scan
Gate 会按严重级别输出每张表的风险报告——Critical（政府 ID、金融信息）、Elevated（联系方式、姓名）、Standard（地址等），并返回 exit code 1 作为 CI 门禁信号。
注册 Hook
将 Gate 挂接到你的 Agent 工具流程中：
gate init gate init --harness opencode gate init --harness cursor gate init --harness codex gate init --harness copilot-cli gate init --harness gemini
之后每次 Agent 发起数据库查询时，Gate 会自动拦截输出、检测 PII 字段、执行遮蔽。
同时保护 MCP 通道
如果 AGent 通过 MCP 协议的 tools/call 访问数据，可以额外注册 MCP 代理：
gate init --wrap-mcp --yes gate init --harness opencode --wrap-mcp --yes
实战场景：脱敏用户表查询
配置完成后，当你的 Agent 执行以下查询时：
Agent: SELECT email, phone, card_no FROM users LIMIT 3
Gate 会自动拦截输出并执行两面检测——先通过列名启发式判断哪些列可能包含 PII，再对列中的具体值做正则 + Luhn 校验。Agent 最终看到的数据是：
[
{ "email": "z****@gmail.com", "phone": "138****8000", "card_no": "6222********7890" },
{ "email": "l***@company.com", "phone": "139****5678", "card_no": "6222********3210" }
]
所有决策都被写入审计日志，每条记录都指向触发遮蔽的规则：
{
"column": "card_no",
"rule": "luhn_check | bank_card_number",
"action": "partial_mask",
"confidence": 0.95
}
与现有方案的对比
Gate 不是要替代数据库层面的 DDM，而是填补 DDM 无法覆盖的盲区：
| 场景 | DDM | Gate |
|---|---|---|
| 需要 DBA 权限 | ✅ 是 | ❌ 否 |
| 支持外部/供应商数据库 | ❌ 不能 | ✅ 可以（SQL、MCP 均可） |
| 覆盖 MCP 工具调用 | ❌ 不行 | ✅ 通过 stdio 代理 |
| 生产数据实时性 | ❌ 静态副本滞后 | ✅ 实时处理 |
| Agent 绕过防护 | ❌ 聚合函数和 CASE 可绕过 | ✅ Hook 层面强制拦截 |
局限性
Gate 的权衡在于：规则引擎无法识别非结构化文本中的 PII。如果一个评论字段包含”我的电话是 13800138000″，列名本身（comment）不是 PII 指示，但其中包含电话号码——Gate 2 版本通过值级扫描部分解决了此问题，但纯自由文本场景仍需要额外的检测手段。
总结
Gate 用不到 10ms 的延迟代价，为 AI Agent 的数据查询流程建立了一道确定性的隐私防线。它不做”可能正确”的模型推断，而是用可审计、可重现的规则确保每一次脱敏决策都有据可查。对于任何允许 AI Agent 访问数据库或内部 API 的团队来说，这是一个值得用上的安全网。
项目地址：github.com/GaaraZhu/gate（62⭐, MIT, Rust）