1. AI应用身份权限安全工程导论
传统应用的身份体系通常围绕“人”展开：员工、管理员、外部用户，配合账号、角色、会话与访问控制列表即可覆盖大部分场景。AI 应用打破了这一前提。一个 AI 应用在运行时，可能同时存在人类用户、代表用户行事的智能体、调用外部工具的自动化流程、访问向量库的检索服务，以及模型本身作为“决策建议者”参与其中。身份不再只是“谁登录了系统”，而是“谁在什么上下文下、以什么授权范围、代表谁、对哪些资源发起了什么动作”。这正是 AI 应用身份权限安全工程要解决的核心问题。
一、AI 应用中的身份主体类型
要建立权限模型，先要识别主体。AI 应用中的身份主体大致可分为五类，它们的行为特征和风险面差异明显。
- 人类用户：发起对话、上传文档、触发任务的自然人。其身份通常由企业 IdP（如 OIDC/SAML）提供，携带部门、角色、租户等属性。风险在于提示注入可能诱导其权限被滥用。
- 智能体（Agent）：具有自主规划与工具调用能力的程序实体。它可能持有自己的服务身份，也可能以“代表用户”的方式运行。关键问题是：它的权限是静态授予的，还是随任务动态收敛的。
- 服务账号与工作负载身份：用于访问数据库、对象存储、消息队列、向量库等后端资源。在 Kubernetes 等环境中常以 ServiceAccount 或 SPIFFE 身份形式存在，需要短时凭证而非长期密钥。
- 工具/插件身份：AI 调用的外部 API、MCP 服务、函数执行环境。它们既是资源，也是代理，可能把 AI 的请求转发到更下游的系统，形成权限链。
- 模型与推理服务身份：模型端点本身也需要身份，用于计量、审计、限流和防止未授权调用。模型不应被视为“无身份的计算函数”。
这五类主体并非孤立存在，而是在一次任务中形成委托链：用户 → 智能体 → 工具 → 后端资源。每一跳都可能放大或收窄权限，因此权限模型必须能表达“委托”和“衰减”。
二、权限模型的特殊性
传统 RBAC 假设权限是静态的、角色是稳定的、资源是明确的。AI 应用则带来四个特殊性。
第一，权限随上下文变化。同一个用户，在“查询公开知识库”和“导出客户合同”两个任务中，所需权限完全不同。若用固定角色覆盖，必然过度授权。更合适的做法是引入任务级、会话级的临时授权，例如基于 OAuth 2.0 的 Token Exchange 或能力令牌（Capability Token），让权限在任务开始时收敛、任务结束时回收。
第二，权限需要可衰减。当智能体把任务委托给子智能体或工具时，下游不应继承上游的全部权限。工程上常用“权限交集”原则：子主体权限 = 父主体权限 ∩ 任务所需权限。例如父智能体拥有读、写、删三种权限，但当前子任务只需读，则子主体只应拿到读权限。
第三，资源边界模糊。向量库中的一段文本可能同时包含多个租户、多个密级的信息。检索结果本身就可能造成越权泄露。因此权限控制不能只停留在“能否访问向量库”，还要延伸到“检索结果是否按调用者权限过滤”，即行级/文档级安全。
第四，行为不可完全预测。模型可能生成未预期的工具调用参数。权限系统必须假设“请求内容不可信”，在工具执行前做参数校验与策略判定，而不是仅依赖模型自觉。
三、安全工程目标
综合上述特殊性，AI 应用身份权限安全工程的目标可以归纳为四条主线。
- 身份可信：每个主体都有可验证的身份，且身份来源可追溯。人类用户走企业 IdP，工作负载走 SPIFFE/Kubernetes 身份，工具走注册制身份，避免匿名调用。
- 权限最小：权限按任务动态授予，默认拒绝，显式允许，且随委托链逐级衰减。长期密钥应尽量替换为短时凭证。
- 行为可审计：每一次身份认证、授权决策、工具调用、数据访问都产生结构化审计事件，能够回答“谁、在何时、以何身份、对何资源、做了什么、结果如何”。
- 风险可阻断：在关键边界（工具调用前、数据返回前、跨租户访问时）设置策略执行点，发现越权或异常时能实时拒绝，而不是事后告警。
这四条主线对应“认证—授权—审计—阻断”的闭环，也是后续各章节展开的技术骨架。
四、课程知识地图
本课程后续内容将围绕上述目标逐层展开：身份体系与凭证管理、授权模型与策略引擎、智能体委托与权限衰减、工具与 MCP 安全、向量库与 RAG 数据权限、审计与可观测性、攻防与红队测试、合规与工程落地。下面的知识地图展示了这些模块之间的依赖关系与数据流方向。
从这张地图可以看出，身份主体层是输入，安全能力层是处理与约束，场景层是验证与反馈。后续章节会沿着“主体识别 → 凭证与授权 → 委托与衰减 → 工具与数据边界 → 审计与阻断”的顺序逐步深入。学习时建议始终带着一个问题：在当前场景中，权限是在哪一跳被放大或收窄的？能回答这个问题，就抓住了 AI 身份权限安全工程的主线。