Stealing Reasoning Traces from Proprietary LLM APIs 是安全研究领域的一个典型题目但对企业级 LLM 应用开发来说它更像是一条需要反复确认的底线闭源大模型 API 返回的响应里那些隐藏的内部推理过程到底有没有可能被无意间暴露到前端、日志、监控平台或第三方错误上报系统里。这里说的推理痕迹reasoning traces并不是产品设计中开放给用户的思考过程展示而是模型在生成最终答案之前产生的内部中间状态通常表现为长串的自然语言推理文本、步骤规划、工具调用决策和分步结论。出于知识产权、模型蒸馏防护和输出稳定性考虑闭源 API 会尽量避免把这些痕迹返回给普通调用方。但在工程实现层避免返回和物理上不存在是两回事。大量的字段透传、异常透传、日志透传都会让这些内部推理文本以非预期的方式出现在应用系统的各个角落。这篇文章选择站在防护者一侧而不是攻击者一侧。我们会在本地模拟一个 OpenAI 兼容的 LLM API搭建一个极小的代理服务复现推理痕迹从响应对象到日志、异常、前端调试面板的完整泄露链路再给出检测清单和加固方案。读完以后你可以直接拿这套方法去审计自己负责的 LLM 应用也能在代码评审时准确指出哪些位置不应该透传完整响应对象。1. 推理痕迹在闭源 LLM API 中是什么为什么会被隐藏1.1 推理痕迹和思维链的关系大语言模型在生成最终回答前往往会先产生一段内部的思维链Chain-of-ThoughtCoT。这段思维链不是正式答案而是模型为了推导答案写下的中间步骤。比较典型的形态是用户想了解 A 方案的可行性需要先拆解需求然后对比 B 和 C 两个关键技术点再结合预算和团队规模给出结论。在模型内部这些中间推理文本会影响最终输出质量。很多场景下推理痕迹越充分最终答案越稳定。这也是为什么 OpenAI、Anthropic、DeepSeek 等模型在 API 层会提供可见的思考能力例如 Anthropic 的 extended thinkingDeepSeek 响应里的 reasoning_content 字段。它们把一部分推理过程开放给调用方让开发者可以做更复杂的任务拆解。但要注意开放的推理痕迹和未经文档说明的推理痕迹是两回事。前者是官方能力有明确的参数约束和响应结构后者是模型内部机制在 API 工程实现上的副产物可能出现在非文档字段、日志上下文、错误对象和 SDK 返回值中。安全研究里谈论的 Stealing Reasoning Traces通常针对后者或者针对厂商想隐藏但实际未彻底隐藏的那部分内部文本。1.2 闭源 API 隐藏推理痕迹的三个主要原因第一个原因是防止模型蒸馏。如果每次调用都能拿到完整的高质量推理过程攻击者可以用大量请求构造蒸馏数据集训练出一个行为非常接近原模型的开源替代品这会严重损害闭源模型的商业价值。第二个原因是保护提示词和系统行为。模型的推理过程往往会把系统提示中的策略、工具定义、判断条件复述出来内部推理文本一旦泄露相当于把模型的底牌交出去了。第三个原因是控制生成成本和输出稳定性。开启完整思维链后单次请求的 completion token 数可能翻倍推理延迟也会明显上升。不向普通调用方暴露完整推理痕迹能降低 API 成本和异常概率。1.3 隐藏不彻底的工程原因在很多情况下隐藏推理痕迹不是模型层能做到的而是取决于 API 网关、SDK、代理服务和应用层的字段过滤是否到位。常见的泄露原因包括响应体原样透传服务端拿到模型返回的完整 JSON没有做字段白名单直接通过 HTTP 接口返回给浏览器。SDK 返回完整对象OpenAI 兼容 SDK 会把未知字段保留在 message 或 choice 对象中.model_dump()之后全部出现在字典里。日志打印整个对象开发阶段为了调试打印response.model_dump()操作日志会永久保留在日志平台。异常对象包含响应体当 API 返回 400 或 429 时SDK 抛出的异常里可能包含服务端响应正文正文里可能带着本次请求的上下文。统一错误处理未过滤字段后端在捕获异常后直接把异常字符串返回给前端或者把完整请求体拼进错误日志。下表是常见的字段形态字段名常见归属文档化状态泄露风险reasoning_contentDeepSeek 等兼容接口部分文档化高直接包含推理文本thinking/thinking_blocksAnthropic 风格接口文档化但有参数限制高需要按需提取reasoning部分 OpenAI 兼容测试字段未文档化高signature某些推理模型的响应尾部未文档化中可能用于内容追踪internal嵌套对象网关内部扩展字段未文档化高可能包含完整链路上下文这里要强调一个判断标准如果一个字段不在 API 官方文档的响应示例里但实际返回了并且内容看起来像是一段连续的自然语言推理文本就应该按潜在推理痕迹泄露处理。不要因为当前前端没有渲染它就忽略它的存在。2. 推理痕迹可能从哪几条链路泄露出去2.1 响应体字段透传最直接的泄露链路是后端把模型 API 的完整响应体返回给前端。现在不少团队使用 FastAPI、Spring Boot 或云函数做 LLM 代理层为了让前端能拿到 usage 或 finish_reason直接返回resp.model_dump()。用户打开浏览器开发者工具在网络面板里就能看到reasoning_content或其他内部字段。即使前端代码里根本没有渲染这个字段它也已经到达客户端进入了用户可读取的范围内。这类泄露在纯文本聊天场景里影响相对可控但在 Agent、RAG 和自动运维场景里会非常危险。内部推理文本可能包含检索到的文档片段、工具调用参数、数据库表名、甚至 API Key 的拼写。当这些内容被透传到浏览器时等于把系统内部加工过程全部暴露出去。2.2 异常信息与服务端错误对象调用闭源 API 时网络超时、限流、参数校验失败都很常见。例如在配置 thinking 相关参数时某些服务端会返回api error: 400 the thinking_budget parameter must be a positive integer...这类错误文本来自服务端参数校验通常不会包含推理文本。但真正的问题在于 SDK 抛出异常时异常对象往往携带完整的服务端响应正文。如果应用捕获异常后直接执行return Response(contentstr(e))调用方就能看到本次请求的上下文包括 message 列表、参数配置、甚至部分截断的响应。更隐蔽的是日志链路。很多团队在except分支里记录日志时使用logger.error(fcall llm failed: {e})这里的e被转换成字符串时可能包含不完整的响应片段。如果这次请求恰好因为上下文超长被中断异常信息里的响应片段可能停留在推理过程中的某个位置推理痕迹就被写进了日志。2.3 应用日志与第三方监控平台日志是推理痕迹泄露的重灾区。开发阶段最常见的写法是logger.info(LLM response: %s, response.model_dump())这条日志在功能调试时很有用但一旦进入生产环境就会把每一次模型的内部推理文本都写入日志系统。日志系统通常有固定的保留周期可能是 30 天、90 天甚至更久并且会同步到集中式日志平台供算法团队、运维团队、审计团队查询。权限一旦稍微放宽任何能访问日志平台的人都能读取全部用户的推理过程。在 RAG 场景里问题会更加明显。推理文本可能包含从知识库中检索到以下相关片段将用户问题转换为 SQL调用订单系统查询参数等中间内容。这些内容对业务是敏感的但对日志系统来说只是普通字符串。如果不在日志输出前做过滤推理痕迹就会从一个 API 响应字段变成一份长期有效的数据资产。2.4 前端调试面板和错误上报前端业务代码有时会把完整的 API 响应对象传给错误上报平台例如 Sentry、Fundebug。当用户触发某个前端异常时错误上报会把上下文作为附加信息发送到监控服务try { const result await fetch(/proxy/chat, options).then(res res.json()); render(result); } catch (e) { Sentry.captureException(e, { extra: { context: result } }); }如果result是后端透传的完整响应对象那么reasoning_content会被写入错误上报平台。而且错误上报平台通常部署在第三方数据链路更长一旦响应体里包含推理痕迹数据所有者就从业务方扩展到了监控服务商。另一个常见位置是浏览器的 LocalStorage 或 IndexedDB。一些聊天前端会缓存历史消息如果组件把整个 message 对象包括内部字段直接写入持久化存储下次会话读取时推理痕迹仍然留在用户本地。用户只要打开 DevTools 的 Application 面板就能看到这些内容。3. 搭建一个最小代理服务观察推理痕迹在哪里出现3.1 准备本地模拟环境为了不在公网环境制造真实数据泄露我们使用本地 Mock Server 模拟一个 OpenAI 兼容的 LLM API。这个模拟接口会故意返回带reasoning_content字段的响应用来复现真实 API 中可能出现的非文档字段。先准备 Python 3.10 以上的环境安装依赖python -m venv .venv source .venv/bin/activate pip install fastapi uvicorn openai httpx创建 mock_llm_api.py运行在 9100 端口模拟一个带内部推理字段的聊天补全接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): model: str messages: list app.post(/chat/completions) def chat_completions(req: ChatRequest): user_message req.messages[-1].get(content, ) return { id: chatcmpl-mock-0001, object: chat.completion, created: 1710000000, model: req.model, choices: [ { index: 0, message: { role: assistant, content: f这是针对「{user_message}」的最终回答。, reasoning_content: 先把用户问题拆成关键词再检索知识库 发现与网络超时相关最后给出排查建议。 }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 30, total_tokens: 42 } }启动uvicorn mock_llm_api:app --host 127.0.0.1 --port 9100这个模拟接口的唯一作用就是返回一个包含内部字段的 OpenAI 兼容响应。真实 API 的字段可能叫reasoning也可能在choices[0].message下嵌套更多对象但检测思路是一致的。3.2 搭建一个直接透传的代理服务创建 proxy_app.py运行在 9200 端口。这里的写法是故意演示危险透传禁止直接复制到生产环境from fastapi import FastAPI from openai import OpenAI app FastAPI() client OpenAI( base_urlhttp://127.0.0.1:9100/v1, api_keytest-key ) app.post(/proxy/chat) def proxy_chat(prompt: str): resp client.chat.completions.create( modelmock-model, messages[{role: user, content: prompt}] ) # 危险写法把模型返回的完整对象直接返回给调用方 return resp.model_dump()启动uvicorn proxy_app:app --host 127.0.0.1 --port 9200接着用 curl 调一次接口看看响应里出现什么curl -X POST http://127.0.0.1:9200/proxy/chat \ -H Content-Type: application/x-www-form-urlencoded \ -d promptAPI调用超时如何排查正常结果里能看到content字段同时也能看到reasoning_content。这说明在完全合规的代码路径里只要模型或 Mock 服务返回了内部字段代理层就会把它原样传给调用方。3.3 在三个审计点检查异常上下文中是否携带推理痕迹除了响应字段还要检查异常上下文。修改 proxy_app.py加入一个会触发参数错误的路径并故意打印异常对象from fastapi import FastAPI from openai import OpenAI import logging logging.basicConfig(levellogging.DEBUG) app FastAPI() client OpenAI(base_urlhttp://127.0.0.1:9100/v1, api_keytest-key) app.post(/proxy/chat) def proxy_chat(prompt: str, thinking_budget: int 0): try: resp client.chat.completions.create( modelmock-model, messages[{role: user, content: prompt}], extra_body{thinking_budget: thinking_budget} ) return resp.model_dump() except Exception as e: # 审计点1确认异常对象字符串是否包含请求上下文 logging.error(llm call failed, e%s, e) # 审计点2确认异常响应体是否包含完整响应 if hasattr(e, response) and e.response is not None: logging.error(response body%s, e.response.text) # 审计点3确认返回给前端的错误信息是否过度暴露 return {error: str(e)}如果在真实 API 中设置非法的 thinking_budget服务端会返回 400。SDK 抛出的异常对象里可能附带服务端响应正文。这里的审计点 1 到 3 是在回答三个问题日志里有没有出现用户 prompt异常响应体里有没有出现模型返回的中间字段最终返回给前端的错误信息里有没有透传服务端细节真实发生异常时错误信息通常不会直接带完整推理文本但可能带请求参数、消息列表、usage 信息。这些内容同样属于敏感上下文应该避免写入日志或返回给调用方。3.4 观察完成后先恢复最小响应实验完成后不要把直接透传的接口留下。恢复最小响应模式只返回业务真正需要的字段def safe_chat_response(resp): return { reply: resp.choices[0].message.content, finish_reason: resp.choices[0].finish_reason, model: resp.model, usage: { prompt_tokens: resp.usage.prompt_tokens, completion_tokens: resp.usage.completion_tokens, total_tokens: resp.usage.total_tokens, } }这里显式提取content等白名单字段而不是返回整个 model_dump。这是一个最基础但最有效的防线。上面的实验只是为了让你直观看到泄露点生产代码必须走白名单路径。4. 建立一份推理痕迹泄露检查清单4.1 从 API 响应体角度检查审查所有调用 LLM API 的代码路径找到返回给前端或下游服务的响应对象结构。需要重点检查的字段如下字段名或位置检查方式泄露风险处理方式choices[].message中的额外字段打印model_dump()与文档比对高白名单提取删除未知字段usage对象确认是否包含reasoning_tokens等字段中只返回业务需要的 usage 项logprobs/top_logprobs看是否为 Debug 参数中默认关闭不返回给前端tool_calls参数中的输入输出Agent 场景必须检查高按角色脱敏只返回标题或摘要流式输出中的 delta 字段SSE 事件里是否携带额外字段高只保留content字段异常响应正文在 catch 分支打印e.response.text高统一错误中间层处理4.2 从日志和监控角度检查在日志平台或本地搜索以下关键词能快速定位疑似泄露点搜索关键词可能来源风险等级reasoning_contentSDK 完整对象被打印高thinking_budget请求参数被日志记录中chain of thought模型推理文本出现在响应体高model_dump开发代码把完整对象打印中response.text异常处理中打印响应体中messages日志框架打印 request body高如果日志平台支持脱敏插件把reasoning_content、thinking、thinking_blocks作为敏感关键词加入脱敏规则防止后续日志写入时被持久化。4.3 从异常处理角度检查异常类型常见现象可能泄露内容处理建议400 bad request参数校验失败SDK 抛出异常请求体、参数配置只返回错误码和通用描述401 unauthorizedAPI Key 无效Authorization 头可能被记录日志中过滤 token429 rate limit请求被限流trace_id、请求来源返回重试时间不回显上下文529 overloaded服务端过载可能包含部分响应文本返回通用提示重试策略交给客户端连接中断流式响应中途断开可能包含已生成的推理片段客户端丢弃不完整数据不落库这条清单可以直接做成团队内部的安全检测卡。每次新增 LLM 调用项目时对照三个维度检查响应字段、日志规则、异常处理。5. 加固方案从第一行代码开始阻断泄露5.1 使用安全响应提取器替代完整透传最有效的方法不是事后清理日志而是在代码层明确只保留业务需要的字段。以 OpenAI Python SDK 返回的ChatCompletion对象为例推荐使用一个统一的提取函数from typing import Any ALLOWED_MESSAGE_FIELDS {role, content, tool_calls} ALLOWED_USAGE_FIELDS {prompt_tokens, completion_tokens, total_tokens} def extract_safe_response(resp: Any LLM推理痕迹泄露防护：从响应透传到日志审计的加固指南
Stealing Reasoning Traces from Proprietary LLM APIs 是安全研究领域的一个典型题目但对企业级 LLM 应用开发来说它更像是一条需要反复确认的底线闭源大模型 API 返回的响应里那些隐藏的内部推理过程到底有没有可能被无意间暴露到前端、日志、监控平台或第三方错误上报系统里。这里说的推理痕迹reasoning traces并不是产品设计中开放给用户的思考过程展示而是模型在生成最终答案之前产生的内部中间状态通常表现为长串的自然语言推理文本、步骤规划、工具调用决策和分步结论。出于知识产权、模型蒸馏防护和输出稳定性考虑闭源 API 会尽量避免把这些痕迹返回给普通调用方。但在工程实现层避免返回和物理上不存在是两回事。大量的字段透传、异常透传、日志透传都会让这些内部推理文本以非预期的方式出现在应用系统的各个角落。这篇文章选择站在防护者一侧而不是攻击者一侧。我们会在本地模拟一个 OpenAI 兼容的 LLM API搭建一个极小的代理服务复现推理痕迹从响应对象到日志、异常、前端调试面板的完整泄露链路再给出检测清单和加固方案。读完以后你可以直接拿这套方法去审计自己负责的 LLM 应用也能在代码评审时准确指出哪些位置不应该透传完整响应对象。1. 推理痕迹在闭源 LLM API 中是什么为什么会被隐藏1.1 推理痕迹和思维链的关系大语言模型在生成最终回答前往往会先产生一段内部的思维链Chain-of-ThoughtCoT。这段思维链不是正式答案而是模型为了推导答案写下的中间步骤。比较典型的形态是用户想了解 A 方案的可行性需要先拆解需求然后对比 B 和 C 两个关键技术点再结合预算和团队规模给出结论。在模型内部这些中间推理文本会影响最终输出质量。很多场景下推理痕迹越充分最终答案越稳定。这也是为什么 OpenAI、Anthropic、DeepSeek 等模型在 API 层会提供可见的思考能力例如 Anthropic 的 extended thinkingDeepSeek 响应里的 reasoning_content 字段。它们把一部分推理过程开放给调用方让开发者可以做更复杂的任务拆解。但要注意开放的推理痕迹和未经文档说明的推理痕迹是两回事。前者是官方能力有明确的参数约束和响应结构后者是模型内部机制在 API 工程实现上的副产物可能出现在非文档字段、日志上下文、错误对象和 SDK 返回值中。安全研究里谈论的 Stealing Reasoning Traces通常针对后者或者针对厂商想隐藏但实际未彻底隐藏的那部分内部文本。1.2 闭源 API 隐藏推理痕迹的三个主要原因第一个原因是防止模型蒸馏。如果每次调用都能拿到完整的高质量推理过程攻击者可以用大量请求构造蒸馏数据集训练出一个行为非常接近原模型的开源替代品这会严重损害闭源模型的商业价值。第二个原因是保护提示词和系统行为。模型的推理过程往往会把系统提示中的策略、工具定义、判断条件复述出来内部推理文本一旦泄露相当于把模型的底牌交出去了。第三个原因是控制生成成本和输出稳定性。开启完整思维链后单次请求的 completion token 数可能翻倍推理延迟也会明显上升。不向普通调用方暴露完整推理痕迹能降低 API 成本和异常概率。1.3 隐藏不彻底的工程原因在很多情况下隐藏推理痕迹不是模型层能做到的而是取决于 API 网关、SDK、代理服务和应用层的字段过滤是否到位。常见的泄露原因包括响应体原样透传服务端拿到模型返回的完整 JSON没有做字段白名单直接通过 HTTP 接口返回给浏览器。SDK 返回完整对象OpenAI 兼容 SDK 会把未知字段保留在 message 或 choice 对象中.model_dump()之后全部出现在字典里。日志打印整个对象开发阶段为了调试打印response.model_dump()操作日志会永久保留在日志平台。异常对象包含响应体当 API 返回 400 或 429 时SDK 抛出的异常里可能包含服务端响应正文正文里可能带着本次请求的上下文。统一错误处理未过滤字段后端在捕获异常后直接把异常字符串返回给前端或者把完整请求体拼进错误日志。下表是常见的字段形态字段名常见归属文档化状态泄露风险reasoning_contentDeepSeek 等兼容接口部分文档化高直接包含推理文本thinking/thinking_blocksAnthropic 风格接口文档化但有参数限制高需要按需提取reasoning部分 OpenAI 兼容测试字段未文档化高signature某些推理模型的响应尾部未文档化中可能用于内容追踪internal嵌套对象网关内部扩展字段未文档化高可能包含完整链路上下文这里要强调一个判断标准如果一个字段不在 API 官方文档的响应示例里但实际返回了并且内容看起来像是一段连续的自然语言推理文本就应该按潜在推理痕迹泄露处理。不要因为当前前端没有渲染它就忽略它的存在。2. 推理痕迹可能从哪几条链路泄露出去2.1 响应体字段透传最直接的泄露链路是后端把模型 API 的完整响应体返回给前端。现在不少团队使用 FastAPI、Spring Boot 或云函数做 LLM 代理层为了让前端能拿到 usage 或 finish_reason直接返回resp.model_dump()。用户打开浏览器开发者工具在网络面板里就能看到reasoning_content或其他内部字段。即使前端代码里根本没有渲染这个字段它也已经到达客户端进入了用户可读取的范围内。这类泄露在纯文本聊天场景里影响相对可控但在 Agent、RAG 和自动运维场景里会非常危险。内部推理文本可能包含检索到的文档片段、工具调用参数、数据库表名、甚至 API Key 的拼写。当这些内容被透传到浏览器时等于把系统内部加工过程全部暴露出去。2.2 异常信息与服务端错误对象调用闭源 API 时网络超时、限流、参数校验失败都很常见。例如在配置 thinking 相关参数时某些服务端会返回api error: 400 the thinking_budget parameter must be a positive integer...这类错误文本来自服务端参数校验通常不会包含推理文本。但真正的问题在于 SDK 抛出异常时异常对象往往携带完整的服务端响应正文。如果应用捕获异常后直接执行return Response(contentstr(e))调用方就能看到本次请求的上下文包括 message 列表、参数配置、甚至部分截断的响应。更隐蔽的是日志链路。很多团队在except分支里记录日志时使用logger.error(fcall llm failed: {e})这里的e被转换成字符串时可能包含不完整的响应片段。如果这次请求恰好因为上下文超长被中断异常信息里的响应片段可能停留在推理过程中的某个位置推理痕迹就被写进了日志。2.3 应用日志与第三方监控平台日志是推理痕迹泄露的重灾区。开发阶段最常见的写法是logger.info(LLM response: %s, response.model_dump())这条日志在功能调试时很有用但一旦进入生产环境就会把每一次模型的内部推理文本都写入日志系统。日志系统通常有固定的保留周期可能是 30 天、90 天甚至更久并且会同步到集中式日志平台供算法团队、运维团队、审计团队查询。权限一旦稍微放宽任何能访问日志平台的人都能读取全部用户的推理过程。在 RAG 场景里问题会更加明显。推理文本可能包含从知识库中检索到以下相关片段将用户问题转换为 SQL调用订单系统查询参数等中间内容。这些内容对业务是敏感的但对日志系统来说只是普通字符串。如果不在日志输出前做过滤推理痕迹就会从一个 API 响应字段变成一份长期有效的数据资产。2.4 前端调试面板和错误上报前端业务代码有时会把完整的 API 响应对象传给错误上报平台例如 Sentry、Fundebug。当用户触发某个前端异常时错误上报会把上下文作为附加信息发送到监控服务try { const result await fetch(/proxy/chat, options).then(res res.json()); render(result); } catch (e) { Sentry.captureException(e, { extra: { context: result } }); }如果result是后端透传的完整响应对象那么reasoning_content会被写入错误上报平台。而且错误上报平台通常部署在第三方数据链路更长一旦响应体里包含推理痕迹数据所有者就从业务方扩展到了监控服务商。另一个常见位置是浏览器的 LocalStorage 或 IndexedDB。一些聊天前端会缓存历史消息如果组件把整个 message 对象包括内部字段直接写入持久化存储下次会话读取时推理痕迹仍然留在用户本地。用户只要打开 DevTools 的 Application 面板就能看到这些内容。3. 搭建一个最小代理服务观察推理痕迹在哪里出现3.1 准备本地模拟环境为了不在公网环境制造真实数据泄露我们使用本地 Mock Server 模拟一个 OpenAI 兼容的 LLM API。这个模拟接口会故意返回带reasoning_content字段的响应用来复现真实 API 中可能出现的非文档字段。先准备 Python 3.10 以上的环境安装依赖python -m venv .venv source .venv/bin/activate pip install fastapi uvicorn openai httpx创建 mock_llm_api.py运行在 9100 端口模拟一个带内部推理字段的聊天补全接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): model: str messages: list app.post(/chat/completions) def chat_completions(req: ChatRequest): user_message req.messages[-1].get(content, ) return { id: chatcmpl-mock-0001, object: chat.completion, created: 1710000000, model: req.model, choices: [ { index: 0, message: { role: assistant, content: f这是针对「{user_message}」的最终回答。, reasoning_content: 先把用户问题拆成关键词再检索知识库 发现与网络超时相关最后给出排查建议。 }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 30, total_tokens: 42 } }启动uvicorn mock_llm_api:app --host 127.0.0.1 --port 9100这个模拟接口的唯一作用就是返回一个包含内部字段的 OpenAI 兼容响应。真实 API 的字段可能叫reasoning也可能在choices[0].message下嵌套更多对象但检测思路是一致的。3.2 搭建一个直接透传的代理服务创建 proxy_app.py运行在 9200 端口。这里的写法是故意演示危险透传禁止直接复制到生产环境from fastapi import FastAPI from openai import OpenAI app FastAPI() client OpenAI( base_urlhttp://127.0.0.1:9100/v1, api_keytest-key ) app.post(/proxy/chat) def proxy_chat(prompt: str): resp client.chat.completions.create( modelmock-model, messages[{role: user, content: prompt}] ) # 危险写法把模型返回的完整对象直接返回给调用方 return resp.model_dump()启动uvicorn proxy_app:app --host 127.0.0.1 --port 9200接着用 curl 调一次接口看看响应里出现什么curl -X POST http://127.0.0.1:9200/proxy/chat \ -H Content-Type: application/x-www-form-urlencoded \ -d promptAPI调用超时如何排查正常结果里能看到content字段同时也能看到reasoning_content。这说明在完全合规的代码路径里只要模型或 Mock 服务返回了内部字段代理层就会把它原样传给调用方。3.3 在三个审计点检查异常上下文中是否携带推理痕迹除了响应字段还要检查异常上下文。修改 proxy_app.py加入一个会触发参数错误的路径并故意打印异常对象from fastapi import FastAPI from openai import OpenAI import logging logging.basicConfig(levellogging.DEBUG) app FastAPI() client OpenAI(base_urlhttp://127.0.0.1:9100/v1, api_keytest-key) app.post(/proxy/chat) def proxy_chat(prompt: str, thinking_budget: int 0): try: resp client.chat.completions.create( modelmock-model, messages[{role: user, content: prompt}], extra_body{thinking_budget: thinking_budget} ) return resp.model_dump() except Exception as e: # 审计点1确认异常对象字符串是否包含请求上下文 logging.error(llm call failed, e%s, e) # 审计点2确认异常响应体是否包含完整响应 if hasattr(e, response) and e.response is not None: logging.error(response body%s, e.response.text) # 审计点3确认返回给前端的错误信息是否过度暴露 return {error: str(e)}如果在真实 API 中设置非法的 thinking_budget服务端会返回 400。SDK 抛出的异常对象里可能附带服务端响应正文。这里的审计点 1 到 3 是在回答三个问题日志里有没有出现用户 prompt异常响应体里有没有出现模型返回的中间字段最终返回给前端的错误信息里有没有透传服务端细节真实发生异常时错误信息通常不会直接带完整推理文本但可能带请求参数、消息列表、usage 信息。这些内容同样属于敏感上下文应该避免写入日志或返回给调用方。3.4 观察完成后先恢复最小响应实验完成后不要把直接透传的接口留下。恢复最小响应模式只返回业务真正需要的字段def safe_chat_response(resp): return { reply: resp.choices[0].message.content, finish_reason: resp.choices[0].finish_reason, model: resp.model, usage: { prompt_tokens: resp.usage.prompt_tokens, completion_tokens: resp.usage.completion_tokens, total_tokens: resp.usage.total_tokens, } }这里显式提取content等白名单字段而不是返回整个 model_dump。这是一个最基础但最有效的防线。上面的实验只是为了让你直观看到泄露点生产代码必须走白名单路径。4. 建立一份推理痕迹泄露检查清单4.1 从 API 响应体角度检查审查所有调用 LLM API 的代码路径找到返回给前端或下游服务的响应对象结构。需要重点检查的字段如下字段名或位置检查方式泄露风险处理方式choices[].message中的额外字段打印model_dump()与文档比对高白名单提取删除未知字段usage对象确认是否包含reasoning_tokens等字段中只返回业务需要的 usage 项logprobs/top_logprobs看是否为 Debug 参数中默认关闭不返回给前端tool_calls参数中的输入输出Agent 场景必须检查高按角色脱敏只返回标题或摘要流式输出中的 delta 字段SSE 事件里是否携带额外字段高只保留content字段异常响应正文在 catch 分支打印e.response.text高统一错误中间层处理4.2 从日志和监控角度检查在日志平台或本地搜索以下关键词能快速定位疑似泄露点搜索关键词可能来源风险等级reasoning_contentSDK 完整对象被打印高thinking_budget请求参数被日志记录中chain of thought模型推理文本出现在响应体高model_dump开发代码把完整对象打印中response.text异常处理中打印响应体中messages日志框架打印 request body高如果日志平台支持脱敏插件把reasoning_content、thinking、thinking_blocks作为敏感关键词加入脱敏规则防止后续日志写入时被持久化。4.3 从异常处理角度检查异常类型常见现象可能泄露内容处理建议400 bad request参数校验失败SDK 抛出异常请求体、参数配置只返回错误码和通用描述401 unauthorizedAPI Key 无效Authorization 头可能被记录日志中过滤 token429 rate limit请求被限流trace_id、请求来源返回重试时间不回显上下文529 overloaded服务端过载可能包含部分响应文本返回通用提示重试策略交给客户端连接中断流式响应中途断开可能包含已生成的推理片段客户端丢弃不完整数据不落库这条清单可以直接做成团队内部的安全检测卡。每次新增 LLM 调用项目时对照三个维度检查响应字段、日志规则、异常处理。5. 加固方案从第一行代码开始阻断泄露5.1 使用安全响应提取器替代完整透传最有效的方法不是事后清理日志而是在代码层明确只保留业务需要的字段。以 OpenAI Python SDK 返回的ChatCompletion对象为例推荐使用一个统一的提取函数from typing import Any ALLOWED_MESSAGE_FIELDS {role, content, tool_calls} ALLOWED_USAGE_FIELDS {prompt_tokens, completion_tokens, total_tokens} def extract_safe_response(resp: Any