安全防护
平台护栏四类防护能力（注入防护、敏感信息脱敏、应拒答拦截、访问控制）的触发场景与处置行为、护栏处置在 API 响应中的形态、护栏统计与能力基线读法，以及误拒说明与申诉路径
平台在每一次查询请求的处理链路上内置一道安全护栏，对进入与流出平台的内容施加防护。护栏与智能查询路由聚合处理同链路运行，对每次请求逐次施加防护处置，并将处置结果汇总为可查的统计。本页说明护栏的四类防护能力、每类的触发场景与处置行为、护栏处置在 API 响应中的呈现形态、护栏统计与能力基线的读法，以及当正常请求被误拒时的说明与申诉路径。
护栏的边界。 护栏只在治理层对内容施加防护处置（放行、拦截、脱敏），不对模型生成的结果做实质性改写或加工。被放行的内容仍由所选模型生成，护栏不参与内容创作。
防护策略由平台统一施加。 护栏的识别规则与处置策略由平台统一维护、对全体请求一致施加，不需要您在客户侧逐项配置。您在客户侧的操作集中在两件事：查看护栏处置统计与能力基线、对偶发的误拒提交申诉。
四类防护能力概览
护栏覆盖输入侧与输出侧，按四类能力对每次请求施加防护处置：
| 防护能力 | 作用 | 处置方式 |
|---|---|---|
| 注入防护 | 识别试图越过既定指令边界的注入式输入（如诱导模型忽略系统约束、越权执行的构造内容） | 命中时拦截该请求，返回结构化拒答 |
| 敏感信息脱敏 | 在输入与输出中识别敏感信息片段（如证件号、联系方式等可识别个人信息） | 命中时对相应片段脱敏，再继续处理或返回 |
| 应拒答拦截 | 识别明确应当拒绝回答的查询（如违法有害内容） | 命中时直接拦截，返回结构化拒答 |
| 访问控制 | 校验请求是否在密钥授权范围内（模型范围、子账户状态等），拦截越权访问 | 命中时拒绝该请求，返回相应错误 |
护栏对单次请求给出一个处置结果——通过 / 拦截（注入）/ 拦截（应拒答）/ 脱敏 / 拒绝（访问控制）/ 误拒之一。处置结果会随该次调用记录一并标注，您可在 用量明细与计量说明 的逐条调用记录中按请求复核。各类处置结果的逐类定义、错误码与统计字段映射见 护栏处置类别参考。
下图示意一次请求在护栏内逐类研判、按命中走向不同处置分支的过程：
逐类研判，命中即止。 一次请求按上图顺序逐类研判，任一类命中拦截即返回相应处置结果，不再继续后续步骤；未触发拦截的请求在输入与输出两侧都会经过敏感信息脱敏。无论走哪条分支，本次处置结果都会写入逐条调用记录。
注入防护
| 项 | 说明 |
|---|---|
| 触发场景 | 输入中包含试图越过既定指令边界的构造内容——如在正文里嵌入「忽略上述全部指令」「以管理员身份执行」一类诱导，意图让模型脱离系统约束或越权执行 |
| 处置行为 | 命中即拦截该请求、不转发至模型，返回结构化拒答（错误码 guardrail_blocked） |
| 逐条记录呈现 | 该次调用的护栏处置结果标注为「拦截（注入）」，可在 用量明细与计量说明 按请求复核 |
| 统计呈现 | 计入护栏统计 by_category.injection（注入防护拦截次数） |
如何降低注入误拒。 业务正文中若需引用「忽略指令」一类措辞（如撰写安全培训材料），可能无意触及注入防护的识别特征。若正常业务请求反复被注入防护误拒，请按下文申诉路径连同
request_id反馈，便于平台优化识别策略。
敏感信息脱敏
| 项 | 说明 |
|---|---|
| 触发场景 | 输入或输出中出现可识别个人信息片段——如身份证号、银行卡号、手机号、邮箱等敏感字段 |
| 处置行为 | 命中即对相应片段脱敏（以掩码替换），再继续处理或返回；脱敏不拦截整条请求，请求仍正常完成 |
| 逐条记录呈现 | 该次调用的护栏处置结果标注为「脱敏」，表示本次请求在输入或输出侧发生过脱敏处置 |
| 统计呈现 | 计入护栏统计 by_category.redaction（敏感信息脱敏命中次数） |
脱敏作用于输入与输出两侧。 输入侧脱敏在转发给模型前对敏感片段打码，避免敏感信息进入推理；输出侧脱敏在返回给您前复核模型生成内容、对其中的敏感片段打码。两侧脱敏均不改变其余内容，也不拦截请求。
应拒答拦截
| 项 | 说明 |
|---|---|
| 触发场景 | 查询内容明确属于应当拒绝回答的类别——如违法、有害、明显违反内容政策的请求 |
| 处置行为 | 命中即直接拦截、不转发至模型，返回结构化拒答（错误码 guardrail_blocked） |
| 逐条记录呈现 | 该次调用的护栏处置结果标注为「拦截（应拒答）」 |
| 统计呈现 | 计入护栏统计 by_category.should_refuse（应拒答拦截次数） |
应拒答拦截与注入防护的区别。 应拒答看的是查询意图本身是否应当被拒绝（内容合规视角）；注入防护看的是输入是否在攻击指令边界（指令安全视角）。两类各自计数、互不混算，便于您从统计上区分防护命中主要落在哪一类。
访问控制
| 项 | 说明 |
|---|---|
| 触发场景 | 请求超出所用密钥的授权范围——如调用了未在该密钥模型范围内的模型、使用了已暂停 / 已注销的子账户密钥，或访问了不属于本账户的资源 |
| 处置行为 | 命中即拒绝该请求，返回相应的访问控制错误（如 401 未认证 / 403 无权限 / 404 资源不存在） |
| 逐条记录呈现 | 越权访问被拒绝；这类校验在请求进入治理链路前置环节完成 |
| 统计呈现 | 计入护栏统计 by_category.access_control（访问控制拦截次数） |
访问控制与密钥授权联动。 访问控制的校验范围取决于您为密钥设置的模型范围与密钥状态。缩小某把密钥的可调用模型范围、暂停或注销密钥，都会即时反映在访问控制校验上。密钥授权范围的管理详见 API 密钥管理。
护栏处置在 API 响应中的形态
护栏的拦截类处置在响应中以结构化错误体返回，便于您的应用识别与分支处理。错误体沿用平台统一的结构化错误结构（错误码 + 可读说明 + 请求追踪标识）：
{
"error": {
"code": "guardrail_blocked",
"message": "<面向用户的可读说明>",
"request_id": "<请求追踪标识>"
}
}| 字段 | 用途 |
|---|---|
code | 处置错误码：护栏拦截统一为 guardrail_blocked；访问控制类按 HTTP 语义返回（如 401 / 403 / 404） |
message | 可读的处置说明 |
request_id | 请求追踪标识，申诉时请提供此标识，便于平台定位该次请求 |
不同处置在响应中的呈现形态如下：
| 处置 | 响应形态 |
|---|---|
| 拦截（注入 / 应拒答） | 返回结构化错误体，code 为 guardrail_blocked |
| 脱敏 | 请求正常返回，敏感片段在内容中已替换为掩码；不返回错误体 |
| 拒绝（访问控制） | 按 HTTP 语义返回对应错误码（401 / 403 / 404），错误体结构一致 |
错误体结构与其他错误一致。 护栏处置的错误体与平台其余错误（如额度暂停
429）采用同一套结构化错误结构，您的应用可用统一的错误处理逻辑识别code后分支。guardrail_blocked错误码、各类错误码的 HTTP 语义与退避重试建议，详见 错误码与重试。
护栏统计的读法
控制台「安全防护」页按所选时间范围汇总护栏处置统计：拦截总次数、按分类构成、误拒率。统计可通过控制平面接口拉取：
curl "https://<平台入口地址>/api/v1/security/overview?start=2026-06-01&end=2026-06-25" \
-H "Authorization: Bearer <您的控制台凭证>"返回当期护栏统计聚合（以产品 API 形态示意；具体数值以控制台为准）：
{
"start": "<统计起始日 YYYY-MM-DD>",
"end": "<统计结束日 YYYY-MM-DD>",
"intercept_count": "<当期拦截总次数>",
"by_category": {
"injection": "<注入防护拦截次数>",
"redaction": "<敏感信息脱敏命中次数>",
"should_refuse": "<应拒答拦截次数>",
"access_control": "<访问控制拦截次数>"
},
"false_reject_rate": "<误拒率>"
}各字段的读法：
| 字段 | 读法 |
|---|---|
intercept_count | 当期被护栏拦截或脱敏处置的请求总次数 |
by_category | 按四类防护（注入防护 / 脱敏 / 应拒答拦截 / 访问控制）拆分的命中构成，便于您看清防护命中主要落在哪一类 |
false_reject_rate | 当期被误拒的正常请求占比，越低越好 |
统计与逐条对得上。 护栏统计来自与用量明细同一份底座——按分类汇总的命中次数，可在 用量明细与计量说明 中按护栏处置结果筛选逐条调用记录复核；统计与逐条同源，逐层对得上。
关注误拒率而非仅看拦截量。 拦截次数高不一定是问题——它可能只是说明确实有较多需要防护的输入。真正需要关注的是误拒率：它衡量护栏把正常请求误判为应拦截的比例。误拒率越低，说明防护在「拦得住」与「不误伤」之间平衡得越好。
护栏能力基线
平台定期以公开评测集对护栏能力进行评测，并以一组护栏能力基线指标呈现护栏的防护水平。基线指标可通过接口拉取：
curl "https://<平台入口地址>/api/v1/security/baseline" \
-H "Authorization: Bearer <您的控制台凭证>"护栏能力基线由五项指标构成，成对呈现——拦截/拦阻类指标越高越好，对应的误拒/误拦类指标越低越好，两者需同时落在目标线一侧，才说明该项防护既「拦得住」又「不误伤」：
| 指标 | 方向 | 含义 |
|---|---|---|
| 应拒答类查询拦截率 | 越高越好 | 对应当拒绝的查询，正确拦截的比例 |
| 非应拒答类查询误拒率 | 越低越好 | 对本不应拒绝的查询，被误拒的比例 |
| 输出内容安全合格率 | 越高越好 | 模型输出经护栏后内容安全合格的比例 |
| 对抗性攻击拦阻率 | 越高越好 | 对构造的对抗性攻击输入，成功拦阻的比例 |
| 良性查询误拦率 | 越低越好 | 对良性查询被误拦的比例 |
成对读法。 「应拒答拦截率」与「误拒率」是一对、「对抗拦阻率」与「良性误拦率」是一对：只看拦得多不够，还要看误拒是否压得住。某项拦截/拦阻达到目标线、但配对的误拒/误拦超出目标线时，该项并不算通过。这组配对约束保证基线不会出现「拦得多但误拒爆表」的失衡。
目标线以服务协议为准。 各项基线指标的具体目标线与统计口径以服务协议与控制台为准；护栏能力基线与通用能力的评测维度、目标线对照与评测快照口径，详见 模型评测说明。
误拒说明与申诉路径
护栏在拦得住与不误伤之间求平衡，但任何防护都可能偶发误拒——把本属正常的请求误判为应拦截。平台对误拒有明确的反馈与申诉路径。
误拒在响应当下与正常拦截一致，均以 code 为 guardrail_blocked 的结构化错误体返回——其中的 request_id 是申诉时定位该次请求的关键，请务必留存。申诉与复核流程：
| 步骤 | 说明 |
|---|---|
| 留存追踪标识 | 收到拦截响应时，记录响应中的 request_id；在控制台「安全防护」页与逐条调用记录中也可定位到该次请求 |
| 提交申诉 | 携带 request_id、发生时间与请求场景说明，通过控制台「账户设置」中的支持渠道（或服务协议约定的联系方式）提交误拒申诉 |
| 平台复核 | 平台依据追踪标识定位该次请求，复核护栏处置是否为误拒；确认误拒的，会对防护策略做相应调整以减少同类误判 |
降低误拒的建议。 提交查询时尽量使用清晰、合规的表述，避免无意中触及注入防护的识别特征（如在正文中嵌入「忽略上述指令」一类构造）。若某类正常业务请求反复被误拒，请连同若干
request_id一并申诉，便于平台批量复核并优化策略。
与其他页面的衔接
| 您想做的 | 前往 |
|---|---|
| 查看护栏四类处置结果的逐类参考 | 护栏处置类别参考 |
| 按请求复核某次调用的护栏处置结果 | 用量明细与计量说明 |
| 了解护栏能力基线与通用能力的评测口径 | 模型评测说明 |
| 管理密钥的模型授权范围（关系访问控制） | API 密钥管理 |
| 区分各类错误码、HTTP 语义与重试建议 | 错误码与重试 |
| 查看服务质量指标的月度达成 | 服务质量（SLA）说明 |
本页中的护栏分类、处置结果与基线指标方向为产品功能口径；各项基线的具体目标线、误拒率与申诉时限等数值不在文档中固化，以服务协议与控制台实时口径为准。