

### 题目分类
- 方向：安全、Guardrails 与治理 / AI 系统纵深防御与风险控制

### 考察点
- 能否先做业务风险分级和 Threat Model，再选择控制措施，而不是无差别堆审核模型
- 能否覆盖模型与供应链、数据隐私、上下文与 RAG、工具权限、应用运行时、治理运营等完整层次
- 能否理解 Prompt、模型拒答和 Guardrail 都是概率性控制，认证授权、Schema、沙箱、审批和配额必须由确定性系统负责
- 能否同时讨论机密性、完整性、可用性、内容安全、可靠性、公平性、隐私、合规和可追责性
- 能否设计输入、检索、生成、工具执行、输出和反馈全链路的检测、阻断、降级与人工接管
- 能否建立风险指标、对抗评测、灰度门禁、Trace、事件响应和持续治理闭环

### 通俗讲解
设计安全可控的 AI 系统，不能只在模型前后各接一个“敏感词过滤器”。AI 应用通常连接用户数据、知识库、外部网页和业务工具，模型既可能答错，也可能被 Prompt Injection 带偏，还可能在权限过大时把错误变成真实副作用。因此要先问三个问题：系统保护什么资产，谁可能怎样攻击或误用它，失败后最大的业务影响是什么。

安全控制要像多道门。模型层降低有害输出和明显滥用概率；数据层限制模型能看到什么；上下文层把外部内容当作不可信数据；工具层决定模型能做什么；应用层负责确定性校验、限流、降级和审批；治理层则负责版本、评测、审计、事件响应和责任归属。任何一层都可能失效，所以后面的层必须限制前面失效后的影响范围。

“可控”也不等于一律拒绝。低风险的知识查询可以自动完成，高风险的外发、删除、付款、医疗或金融决策应提高证据要求、缩小权限并引入人工复核。系统要根据场景的 Impact、Likelihood、用户权限和不确定性动态选择 `ALLOW`、`REVIEW`、`DENY` 或安全降级。

### 知识讲解
#### 1. 从风险建模开始，而不是从模型开始
第一步是建立 AI System Inventory：模型、数据源、Vector Store、Prompt、Tool、第三方 API、部署区域、责任人和版本都要可追踪。然后画出信任边界，识别用户输入、RAG 文档、网页、邮件、Tool Result、插件和供应链依赖中的不可信来源。

Threat Model 至少要列出资产、攻击者、入口、能力、影响和现有控制。资产可能是个人数据、商业秘密、模型权重、系统可用性或业务操作权；风险不仅来自恶意攻击，也来自模型幻觉、数据过期、配置错误、权限误配和正常用户的边界输入。

可以用 CIA 作为安全底座：Confidentiality 防数据泄露，Integrity 防提示词、知识库、模型和工具结果被篡改，Availability 防 DoS 和 Unbounded Consumption。在此基础上再加入 AI 特有维度：Safety、Reliability、Privacy、Fairness、Transparency、Accountability 与 Compliance。

#### 2. 模型与供应链层
模型层首先要做适配性选择和风险验收。不同模型在内容安全、幻觉、工具调用、长上下文、语言公平性和对抗鲁棒性上不同，不能只看通用 Benchmark。上线前要用业务数据和高风险切片评估 Task Success、拒答、越狱、敏感信息泄露和工具调用稳定性。

如果参与训练或微调，还要治理数据来源、授权、去重、PII、污染、后门和训练投毒；对合成数据要记录生成模型与筛选规则。模型产物应绑定权重 Hash、Tokenizer、Chat Template、训练代码、依赖、许可证、Model Card 和评测报告，并进行签名、访问控制和发布审批。

第三方模型、Adapter、Embedding、数据集、容器和插件都是供应链。需要来源白名单、SBOM、漏洞扫描、完整性校验、版本锁定和回滚能力。模型对齐与拒答能降低风险，但不能承担数据库授权或资金操作的安全边界。

#### 3. 数据、隐私与租户隔离层
遵循 Data Minimization：只收集、检索和发送完成任务所需的数据。敏感字段在进入模型前做识别、脱敏或 Tokenization；传输与静态存储加密；Secret 放在专用密钥系统中，不进入 Prompt、日志或训练集。

数据访问必须绑定用户身份、Tenant、Purpose 和 Resource Scope。RAG 要在检索前执行 ACL，而不是检索出越权文档后再让模型“不要泄露”。长期记忆也要有写入策略、可见范围、过期、删除、更正和用户导出机制。

还要明确数据流向与生命周期：哪些内容发送给模型 Provider，是否用于训练，保存多久，日志中有什么，跨境和数据驻留如何处理。删除请求必须覆盖主存储、缓存、向量索引、备份与衍生数据，并保留可审计的执行记录。

#### 4. Prompt、Context 与 RAG 层
System Prompt 应表达任务边界和处理原则，但不能存放秘密，也不能当作权限系统。用户输入、网页、邮件、PDF、图片 OCR、RAG 文档和 Tool Result 都可能包含直接或间接 Prompt Injection，应保留 Provenance 与 Trust Level，并明确它们是数据而非高优先级指令。

Context Builder 只选择当前任务必要的材料，执行长度限制、来源过滤、租户 ACL、时效校验、冲突检测和敏感信息最小披露。RAG 回答要求引用证据，对证据不足、互相冲突或超出知识时效的问题进入拒答、澄清或人工分支。

注入检测器、关键词、分隔符和“忽略恶意指令”只能作为风险信号。它们可能误报，也可能漏报；即使检测通过，后续 Tool Policy 和数据授权仍必须执行。

图解 1：下面这张图展示从模型供应链到治理运营的六层纵深防御，以及每层保护的核心边界。

![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/bc8676013ea3a1d07d8c15742015821d.png)

#### 5. Tool、Agent 与权限层
Agent 风险会被工具权限放大。模型只能提出 Tool Call 意图，Runtime 必须使用当前用户身份重新执行认证授权，校验 Tool Allowlist、JSON Schema、业务规则、资源 Scope、目标地址和速率限制，不能相信模型声称“已经获得用户授权”。

工具采用最小功能、最小权限和最小自治：读写分离，通用 Shell、任意 SQL、任意 URL 和高权限 Token 默认禁用；代码执行放入沙箱，限制文件、网络、CPU、内存和时间；外发、删除、付款、权限变更等动作必须提供可理解的 Preview，并由用户确认当前精确参数。

带副作用操作还要有 Idempotency Key、事务、补偿和审计。多步 Agent 设置最大轮数、Token、费用、工具调用数和墙钟时间，检测重复状态和异常调用序列。权限不是 Model Capability，而是 Runtime Capability。

#### 6. 应用运行时与用户体验层
请求进入系统后先经过认证、租户解析、配额、大小限制和风险分类，再决定模型、工具与自治等级。输入审核防明显滥用和恶意文件；输出审核处理有害内容、PII、Secret、引用、格式和下游注入；但二者都不能替代中间执行链路的权限控制。

生成结果进入 SQL、Shell、HTML、Markdown、URL 或其他解释器之前，要做与目标上下文匹配的解析、Allowlist 和转义，防止 Improper Output Handling。结构化输出必须经过 Schema 和语义校验，不能因为 JSON 可解析就假设业务上安全。

系统要支持超时、熔断、Fallback、安全模板、只读模式、功能 Kill Switch 和人工接管。高风险场景应向用户展示证据、不确定性、操作预览和申诉入口；不能用模糊的“AI 生成，仅供参考”代替真正的风险控制。

#### 7. 治理、评测与事件响应层
治理可以沿 NIST AI RMF 的 `Govern、Map、Measure、Manage` 组织。Govern 明确风险所有者、政策和可接受风险；Map 识别场景、用户、资产、影响和依赖；Measure 建立评测集与监控；Manage 根据风险选择缓解、转移、接受或停止，并跟踪残余风险。

离线评测要覆盖正常任务、边界输入、直接和间接注入、越狱、数据泄露、越权工具、RAG 污染、模型与依赖升级、成本攻击和故障降级。核心指标包括 Attack Success Rate、Harmful Output Rate、PII/Secret Leakage、Unauthorized Action Rate、Groundedness、误拒率、漏拒率、任务成功率、P95/P99、单位成功成本和人工接管率。

上线采用版本化门禁、Shadow、Canary 和分阶段放量。线上 Trace 关联 User、Tenant、Prompt Version、Model、Retrieved Source、Tool Call、Policy Decision、Approval、Output、Cost 和 Stop Reason，同时遵循日志最小化与访问控制。事件发生后支持止血、撤销凭证、停用工具、回滚模型、通知、取证、根因分析和评测集回灌。

图解 2：下面这张图展示一次 AI 请求如何经过风险分类、上下文装配、模型提议、确定性策略、审批与审计闭环。

![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/805d1b3742a4f66bb1726fe04c1169cf.png)

### 代码示例
下面的 Python 示例展示 Tool Policy 的基本边界：模型输出只是候选动作，最终决策由应用根据用户权限、数据级别、操作影响和确认状态确定。

```python
from dataclasses import dataclass
from enum import Enum
from typing import Optional


class Decision(str, Enum):
    ALLOW = "ALLOW"
    REVIEW = "REVIEW"
    DENY = "DENY"


class Effect(str, Enum):
    READ = "READ"
    WRITE = "WRITE"
    EXTERNAL = "EXTERNAL"


@dataclass(frozen=True)
class Action:
    tool: str
    effect: Effect
    resource_tenant: str
    contains_sensitive_data: bool = False


@dataclass(frozen=True)
class SecurityContext:
    user_tenant: str
    allowed_tools: frozenset[str]
    confirmed_action_hash: Optional[str] = None


def authorize(
    action: Action,
    context: SecurityContext,
    action_hash: str,
) -> tuple[Decision, str]:
    if action.tool not in context.allowed_tools:
        return Decision.DENY, "TOOL_NOT_ALLOWED"

    if action.resource_tenant != context.user_tenant:
        return Decision.DENY, "TENANT_SCOPE_VIOLATION"

    if action.contains_sensitive_data and action.effect == Effect.EXTERNAL:
        return Decision.DENY, "SENSITIVE_DATA_EGRESS"

    if action.effect in {Effect.WRITE, Effect.EXTERNAL}:
        if context.confirmed_action_hash != action_hash:
            return Decision.REVIEW, "USER_CONFIRMATION_REQUIRED"

    return Decision.ALLOW, "POLICY_PASSED"
```

### 代码讲解
`authorize` 不分析 Prompt 是否“看起来善意”，也不接受模型生成的权限声明。它只读取应用掌握的确定性状态：工具是否在 Allowlist、资源是否属于当前 Tenant、敏感信息是否外发，以及高影响动作是否由用户确认过相同的 `action_hash`。

生产实现中的 Hash 应使用稳定序列化与加密摘要，并绑定 User、Tenant、Session、过期时间和 Idempotency Key，防止审批后参数被替换。Policy 还可以加入 Role、Purpose、Resource ID、Data Classification、目标域名、金额、风险等级和时间窗口，并把每次决策写入不可篡改审计日志。

这个示例只覆盖 Tool Authorization。完整系统还需要在模型前后执行内容与隐私检测，在检索前执行 ACL，在工具内部再次校验身份，并由下游业务系统做最终授权，形成 Defense in Depth。

### 工程深挖
第一，风险控制要按影响分级。只读公开问答、内部知识检索、个人数据读取、外部消息发送和资金操作不能共享同一套自治策略。可以根据 Impact、Likelihood、Data Sensitivity、Reversibility 和 Confidence 计算 Risk Tier，决定模型、工具、审批和审计强度。

第二，区分概率性与确定性控制。分类器、LLM Judge、对齐模型和 Prompt 可以识别风险，但存在漏报与漂移；认证、ACL、Schema、事务、沙箱、网络策略、配额和审批能够提供更硬的边界。高风险动作必须至少经过一道确定性控制。

第三，Guardrail 自身也要评测和版本化。只看拦截率会鼓励系统全部拒绝，因此必须同时看攻击成功率、误拒率、任务成功率、分语言与分人群差异、延迟和成本。阈值、规则、模型与政策版本进入 Trace，支持回放同一请求在新旧版本下的差异。

第四，安全和可用性一起设计。Provider 不可用、审核超时、Policy Service 故障或日志系统阻塞时，要明确 Fail Open 还是 Fail Closed。高风险写操作通常 Fail Closed；低风险只读场景可降级到受限模型、缓存答案或不带工具的安全模式。

第五，控制供应链和变更。模型、Prompt、RAG 索引、Tool Schema、Policy 和依赖的任一变化都可能改变风险面。发布流水线应执行签名校验、漏洞扫描、离线 Eval、安全回归和 Canary；达到泄露、越权或有害输出阈值时自动停止放量并回滚。

第六，建立可执行的 Incident Response。预先定义严重等级、值班人、Kill Switch、凭证轮换、数据泄露通知、证据保全和监管报告流程。事故复盘应把失败 Trace 转成新的 Eval Case、策略规则或架构约束，而不是只追加一句 System Prompt。

### 面试回答
我会把安全可控 AI 系统设计成纵深防御，而不是依赖模型拒答或一个内容审核接口。第一步先做资产清单、信任边界和 Threat Model，按机密性、完整性、可用性，以及 Safety、Privacy、Fairness、Reliability、Accountability 和 Compliance 识别风险，再根据业务影响划分 Risk Tier。

技术上我会分六层。模型与供应链层管理训练数据、投毒、模型评测、产物签名和依赖；数据层做最小化、加密、PII、保留删除和 Tenant 隔离；Context/RAG 层保留来源与可信等级，在检索前执行 ACL，并防间接 Prompt Injection；Tool 层使用最小权限、Schema、业务规则、沙箱、幂等和高风险确认；应用运行时做认证、限流、输入输出审核、预算、熔断、Fallback 和 Kill Switch；治理层负责版本门禁、Trace、审计、事件响应和责任人。

最关键的边界是：模型只提出内容或动作意图，不能自己授予权限。数据库访问、外发、删除、付款等操作必须由确定性 Policy Engine 使用当前用户身份重新授权。Prompt 和检测器可以作为风险信号，但即使被绕过，最小权限和审批仍应把损失限制住。

验证上我会建立正常样本与红队样本，覆盖注入、越狱、泄露、越权、RAG 污染、供应链和成本攻击，同时看 Attack Success Rate、Unauthorized Action Rate、PII Leakage、误拒率、任务成功率、P99 和单位成功成本。发布走 Shadow、Canary 和分阶段放量，线上 Trace 能关联模型、Prompt、证据、工具、策略和审批，触发阈值后支持降级、停用工具或回滚。

### 面试官追问
1. 为什么 System Prompt 和模型拒答不能作为真正的安全边界？
2. RAG 系统应在检索前还是检索后执行权限过滤？为什么？
3. 如何防止 Agent 因 Prompt Injection 调用高风险工具？
4. 内容审核服务超时或不可用时，什么场景应该 Fail Open，什么场景应该 Fail Closed？
5. 怎样同时评估安全拦截能力和正常用户体验，避免系统过度拒绝？
6. 模型、Prompt、知识库和工具版本变化时，如何设计安全发布与回滚？

### 高分回答要点
- 先做资产、攻击面、信任边界、风险分级和残余风险，再谈控制措施
- 覆盖模型供应链、数据隐私、Context/RAG、Tool 权限、应用运行时和治理运营
- 明确模型提议与系统授权的边界，高风险动作使用确定性 Policy 与人工审批
- 同时考虑 CIA、Safety、Reliability、Privacy、Fairness、Transparency 和 Compliance
- 设计全链路 Provenance、最小披露、最小权限、沙箱、幂等、降级和 Kill Switch
- 用安全与效用双指标、红队评测、Canary、Trace 和事件响应形成生命周期闭环

### 常见扣分回答
- 只回答敏感词、内容审核和模型拒答，缺少数据、权限、工具与治理边界
- 把 System Prompt 当权限控制，认为“禁止泄露”就能保护 Secret
- 先检索全部租户文档，再要求模型不要输出越权内容
- 允许模型直接执行 SQL、Shell、外发或删除，没有最小权限与审批
- 只追求拦截率，不看误拒、任务成功、分群公平性、延迟和成本
- 没有版本、Trace、发布门禁、Kill Switch、事件响应和责任人

### 项目结合话术
设计 AI 系统时，我会先维护模型、Prompt、知识源、工具和数据流清单，针对泄露、注入、越权、幻觉、副作用和资源滥用建立标准攻击集，再按 Risk Tier 决定自动执行、人工复核或禁止。请求链路中，检索前执行 Tenant ACL，模型只生成结构化候选动作，Policy Engine 再校验用户、资源、Schema、敏感数据和审批 Hash；所有决策写入 Trace。发布时比较 Task Success、Attack Success Rate、PII Leakage、Unauthorized Action Rate、误拒率和 P99，通过 Canary 分阶段放量；出现高危指标时用 Kill Switch 停用工具或切换只读模式，并把事故 Trace 回灌评测集。

### 一句话总结
安全可控的 AI 系统不是让模型“更听话”，而是从模型供应链、数据、上下文、工具权限、应用运行时到治理运营建立纵深防御，让概率模型即使出错或被攻击，也无法绕过确定性授权、扩大数据暴露或产生不可控副作用。

### 参考来源
- [NIST：AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST：Generative AI Profile, NIST AI 600-1](https://doi.org/10.6028/NIST.AI.600-1)
- [NIST：AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook)
- [OWASP：Top 10 for LLM and Generative AI Applications 2025](https://genai.owasp.org/llm-top-10/)
- [OWASP：LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
- [MITRE ATLAS](https://atlas.mitre.org/)

能否先做业务风险分级和 Threat Model，再选择控制措施，而不是无差别堆审核模型

2026AI面试题-如何设计一个安全可控的 AI 系统？从模型层到应用层需要考虑哪些安全维度？

人工智能

前端

设计安全可控的AI系统需先做资产清单与威胁建模，按风险分级选择控制。核心是纵深防御六层：模型供应链、数据隐私、上下文RAG、工具权限、应用运行时、治理运营。关键原则：模型仅提议，确定性系统执行授权，认证、Schema、沙箱、审批由代码保证。建立覆盖注入、越权、泄露的评测集，通过Canary发布、Trace审计和事件响应形成闭环，确保概率模型出错时无法造成不可控副作用。

数据隐私

敏感数据

代码解释

漏洞扫描

数据泄露

内容安全

解释器

数据流

数据库

大数据

Python

容器

Agent

JSON

2026上云采购 | AI焕新·智启新局

lexiang

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

设计安全可控的AI系统需先做资产清单与威胁建模，按风险分级选择控制。核心是纵深防御六层：模型供应链、数据隐私、上下文RAG、工具权限、应用运行时、治理运营。关键原则：模型仅提议，确定性系统执行授权，认证、Schema、沙箱、审批由代码保证。建立覆盖注入、越权、泄露的评测集，通过Canary发布、Trace审计和事件响应...

2026AI面试题-如何设计一个安全可控的 AI 系统？从模型层到应用层需要考虑哪些安全维度？-腾讯云开发者社区-腾讯云

2026AI面试题-如何设计一个安全可控的 AI 系统？从模型层到应用层需要考虑哪些安全维度？

2026AI面试题-如何设计一个安全可控的 AI 系统？从模型层到应用层需要考虑哪些安全维度？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐