第三方网络安全评测能够帮助发现模型在攻击分析、漏洞研究和防御建议方面的能力边界，但评测过程本身也可能引入新的安全风险。OpenAI 对近期涉及其模型的第三方网络安全评测事件进行了说明，并提出新的防护措施，以加强模型测试与评估的安全性、可追溯性和治理能力。
评测对象不只是模型
网络安全评测通常需要构造攻击样本、分析漏洞利用链，甚至让模型处理具有真实攻击特征的输入。风险因此不只来自模型输出，还来自完整的评测链路：
- 测试数据可能包含真实凭据、内部地址或未公开漏洞信息。
- 评测人员可能误用模型输出，把研究环境中的建议带入生产系统。
- 自动化测试可能扩大高风险请求的规模和影响范围。
- 第三方工具、插件或代理服务可能改变模型请求和响应的安全边界。
- 评测结果如果缺少日志和版本信息，就很难复现，也难以判断问题来自模型、提示词还是外围系统。
因此，安全评测需要同时管理模型能力和评测基础设施。一个“能发现问题”的测试，如果没有访问控制、数据隔离和审计机制，可能把测试活动本身变成新的攻击面。
新防护措施应覆盖哪些环节
从工程实践看，第三方评测至少需要建立四层控制。
明确授权范围
评测开始前应记录允许测试的模型、接口、时间窗口、请求规模和禁止行为。对于涉及真实系统、真实用户数据或未公开漏洞的测试，还需要单独审批，而不是仅凭一份通用授权推进。
限制高风险能力
可以为评测账号设置速率限制、预算限制和模型能力边界。高风险请求应进入人工复核或隔离环境，不能因为评测任务需要较高自由度，就默认关闭所有安全控制。
保留完整证据
每次评测至少要保存模型版本、系统提示词版本、评测者身份、请求时间、输入摘要、输出摘要、工具调用和人工处置结果。敏感内容可以脱敏或加密，但不能让关键事件只存在于个人终端的临时日志中。
建立事件响应路径
当第三方评测触发异常输出、越权访问或数据暴露时，应立即暂停相关测试，冻结证据，通知责任人，并根据影响范围决定是否扩大调查。评测协议中应提前写明联系人、停测条件和报告时限。
一个可改造的最小评测闸门
下面的 Python 示例是一个本地评测闸门。它不连接任何真实模型或生产系统，重点展示如何在发送请求前检查授权、数据和风险等级。实际接入模型 API 时，可以把 invoke_model 替换成经过组织批准的客户端调用。
运行前无需安装第三方依赖：
from dataclasses import dataclass
import hashlib
import json
from datetime import datetime, timezone
@dataclass
class EvaluationRequest:
evaluator: str
model: str
prompt: str
risk: str
approved_models: set[str]
max_prompt_chars: int = 4000
def contains_secret(text: str) -> bool:
markers = ("-----BEGIN", "api_key=", "password=", "Authorization: Bearer")
return any(marker.lower() in text.lower() for marker in markers)
def audit_event(request: EvaluationRequest, decision: str, reason: str) -> None:
prompt_hash = hashlib.sha256(request.prompt.encode("utf-8")).hexdigest()
event = {
"time": datetime.now(timezone.utc).isoformat(),
"evaluator": request.evaluator,
"model": request.model,
"prompt_sha256": prompt_hash,
"decision": decision,
"reason": reason,
}
print(json.dumps(event, ensure_ascii=False))
def invoke_model(prompt: str, model: str) -> str:
# 实践中替换为组织批准的模型客户端；不要直接连接生产系统。
return f"[sandbox:{model}] evaluation response for {len(prompt)} chars"
def run_evaluation(request: EvaluationRequest) -> str:
if request.model not in request.approved_models:
audit_event(request, "blocked", "model is not approved")
raise PermissionError("model is not approved for this evaluation")
if len(request.prompt) > request.max_prompt_chars:
audit_event(request, "blocked", "prompt is too large")
raise ValueError("prompt exceeds the evaluation limit")
if contains_secret(request.prompt):
audit_event(request, "blocked", "possible secret detected")
raise ValueError("remove secrets before evaluation")
if request.risk == "high":
audit_event(request, "review", "manual approval required")
raise PermissionError("high-risk evaluation requires manual approval")
audit_event(request, "allowed", "sandbox evaluation")
return invoke_model(request.prompt, request.model)
if __name__ == "__main__":
request = EvaluationRequest(
evaluator="researcher-001",
model="approved-model",
prompt="Classify this synthetic phishing example and explain defensive signals.",
risk="medium",
approved_models={"approved-model"},
)
print(run_evaluation(request))
这段代码只提供最小控制面，不能替代组织级安全方案。真实系统还应加入身份认证、网络隔离、请求速率限制、密钥管理、输出审查和不可篡改的审计存储。对于网络安全研究，尤其要使用合成数据或经过批准的脱敏数据，并把模型输出限制在隔离的实验环境中。
如何判断评测方案是否成熟
可以在启动第三方评测前检查以下问题：
- 是否有明确、可验证的书面授权？
- 是否为模型、工具和数据分别定义了允许范围？
- 是否可以随时暂停评测并保留完整证据？
- 是否隔离了生产凭据、真实用户数据和外部网络访问？
- 是否记录了模型版本、提示词版本和评测代码版本？
- 是否规定了高风险结果的人工复核、报告和修复流程？
- 是否能区分模型问题、评测设计问题和外围系统问题？
第三方评测的价值在于提供独立视角，但独立并不意味着可以脱离治理。更可靠的做法，是把每次评测当成一项受控的安全变更：先限定范围，再执行测试；先隔离数据和工具，再观察模型能力；发现异常后，确保有人能够快速停测、调查并修复。这样才能让评测真正增强模型安全，而不是扩大测试活动自身的风险。