DontFeedTheAI 是一款面向 AI 辅助渗透测试的透明匿名化代理：它在你与 Claude、OpenAI、OpenRouter 等大模型之间拦截请求，先把 IP、凭据、主机名和公司名等敏感信息替换为假值，再把响应还原后返回。它的核心之一就是本地的Ollama 上下文检测层，专门负责在自由文本中识别那些正则规则抓不到的主机名与公司名。

为什么正则规则不够用

DontFeedTheAI 采用双层检测架构：

问题在于：10.20.0.5或AKIA...这类字符串有固定格式，正则一击即中；但像DC01、Acme Corp、stelear-tech-app-01这样的词，在文本里就是普通单词——没有前缀、没有固定格式，只有结合上下文（"nmap 扫描 DC01 发现 445 端口开放"）才能判断它是敏感信息。这正是上下文检测层存在的意义。

Ollama 上下文检测层是如何工作的

检测逻辑位于 src/llm_detector.py，整体流程如下：

1. 分块：长文本按LLM_CHUNK_SIZE（默认 1500 字符）切块，相邻块保留 150 字符重叠，避免实体被拦腰截断；
2. 并发推理：各块最多 2 路并发，调用本机 Ollama 的/api/chat，默认模型qwen3:1.7b，temperature=0保证输出稳定；
3. 结构化输出：要求模型只返回 JSON 实体列表，每项包含text（必须是输入中的原文子串）和type（HOSTNAME、ORGANIZATION、CREDENTIAL 等）；
4. 去重汇总：按出现顺序合并各块的检测结果。

几个关键设计值得新手注意：

• 幻觉防护：解析时校验text in chunk_text——模型"编造"出来的、文本里根本不存在的实体会被直接丢弃；
• 分块 LRU 缓存：相同内容的块（比如反复粘贴的同一段工具输出）按 MD5 命中缓存，最多保留 500 条；
• 硬失败策略：Ollama 不可达或超时时会抛出OllamaUnavailableError，代理拒绝转发请求，而不是带着没脱敏的数据放行——宁可报错也不漏数据；
• 系统提示词热更新：若存在data/system_prompt.txt，它会覆盖内置提示词，且最多每 60 秒重新读取一次磁盘，无需重启服务即可让优化后的提示词生效。

主机名与公司名是怎么被识别的

裸主机名：靠"上下文长相"判断

系统提示词中的 HOSTNAME 规则要求模型识别不带 FQDN 的唯一机器名，例如DC01、WEBSERVER01、FILESERVER-PRD、FORTUNA-CA。判断依据不是格式而是语境——它必须"看起来像一个具体的机器名"，而不是泛泛的server、host这类普通词。识别后，DC01会被替换为类似dc-0042的假主机名，规则实现在 src/surrogates.py。

公司名：要求"原样返回"

ORGANIZATION 规则覆盖公司名称、品牌、项目代号，并明确要求模型按原始大小写和空格精确返回（返回Acme Corp而不是acme.corp）。它还覆盖了一些容易漏掉的场景：全大写的 Windows 域/工作组名、WiFi SSID 值、带公司前缀的云资源名（存储桶、K8s 命名空间、GCP 项目 ID）等。

严格的不标记清单：避免误杀

识别敏感信息最大的坑是误报。提示词中列了一张详细的"DO NOT FLAG"清单：渗透工具名（nmap、mimikatz、bloodhound）、协议名（Kerberos、NTLM）、技术产品与版本（IIS 10、Apache 2.4.49）、CVE 编号、AD 内置账户（krbtgt、Domain Admins）等一概不标记。代理层还叠加了一层硬编码白名单（src/anonymizer.py 中的_NEVER_ANONYMIZE），即使模型误判也不会动这些词。

背后的原则一句话：描述"技术是什么"的保留，描述"它是谁的/在哪的"才替换——否则模型连你面对的是 IIS 10 还是 Apache 都判断不了，分析结果毫无价值。

识别之后：一致的假值映射

每识别出一个实体，代理会在按ENGAGEMENT_ID隔离的本地 SQLite 保险库中建立"原文 ↔ 假值"映射（src/vault.py），同一任务内相同原文始终映射到相同假值，保证 AI 推理时上下文连贯：

云端 LLM 只能看到假值；响应返回时代理再按映射还原，整个过程敏感数据不离开本机。

如何验证与调优检测效果

• 可视化审计：运行python3 wizard.py tunnel --audit，打开上图所示的面板，可按实体类型（DOMAIN、CREDENTIAL、HOSTNAME…）过滤每条ORIGINAL → SURROGATE映射，一眼发现漏网之鱼；
• 全链路测试：python3 wizard.py test --integration让全部 fixture 走完 LLM + 正则完整管线并断言零泄露；
• 反馈闭环：scripts/dev/feedback_loop.py 会把验证器发现的漏报案例回灌，用于持续改进系统提示词。

更多支持的上游客户端与配置项，可查阅 docs/providers.md；完整的两层管线技术拆解见 docs/architecture.md。

小结

对于需要在 AI 辅助下分析渗透报告、生产日志又担心客户信息外泄的安全从业者来说，这套"本地上下文检测 + 正则兜底"的分层方案，是一个值得参考的务实架构。