终端用户身份应怎样经过 Agent、MCP Client 和工具服务安全传递，避免使用共享高权服务账户？
终端用户身份应沿调用链传递：Agent 把用户身份（含 scope）传播给 MCP Client，再随 token exchange 传递到工具服务，工具服务用用户身份做资源级授权。避免使用共享高权服务账户（它是权限放大与追踪困难之源）。实践：用 OAuth 令牌链（token exchange）、JWT 携带用户主体与限制 scope、服务间用身份上下文延续身份，工具服务按最小权限执行并以用户身份审计。
身份传递保证"谁发起、谁担责"。共享账户失去可审计性与最小权限，必须用身份链传递用户主体。
租户、行列和资源级授权如何在 RAG 检索、工具执行和缓存命中前强制执行？
授权必须在"数据真正被使用"之前强制执行：RAG 检索前用租户/行级过滤约束检索范围，确保只返回授权数据；工具执行前做资源级授权（操作权限 + 资源范围），拒绝越权调用；缓存命中前校验缓存条目与当前用户的租户/权限是否匹配，防止跨租户缓存泄露。授权逻辑独立于检索与缓存，作为强制前置条件。
关键在"授权先于执行"。RAG、工具、缓存每个访问点都要校验，防止授权被绕过，尤其缓存易被忽略。
审批令牌如何绑定具体动作、参数和有效期，防止重放或被另一个 Agent 任务复用？
审批令牌应绑定具体上下文：编码允许的动作、参数范围、资源与有效期，并绑定发起者与任务 ID；执行时校验令牌与当前请求的动作/参数/身份是否一致，防止重放（同一令牌重复使用）或跨任务复用（另一个 Agent 用作它途）。一次性令牌（使用后失效）与有效期结合，进一步防重放；令牌失效按需支持。
审批令牌是"授权执行凭据"。绑定动作、参数、有效期与一次性性，可防止令牌被重放或跨任务滥用。
第三方许可证和生成代码来源不明确时，Code Review 与发布门禁应如何处理？
对第三方许可证与生成代码，Code Review 应核验许可证类型与合规性（GPL/AGPL 等传染性许可需评估）、生成代码的来源与许可声明；发布门禁应要求：未明确来源与许可证的代码不得引入，需通过许可证扫描（SPDX）、SBOM 生成与合规审批后才能发布。对生成代码做人工审查与来源记录，防止引入违规或未知代码。
来源不明=合规与供应链风险。门禁强制"来源可溯、许可证合规"，前置审查与 SBOM 记录。
C2PA Content Credentials 能证明内容来源链的哪些信息？为什么不能单独证明内容事实真伪？
C2PA Content Credentials 通过签名元数据证明内容来源链：谁创作/编辑了内容、使用了什么工具、何时生成、是否经过 AI 处理等，可追踪内容处置历史。但它不能证明内容事实真伪，因为来源可信不等于内容真实（创作者也可能错误或被操纵），且 C2PA 不评估内容本身的事实正确性。事实真伪需独立的事实核查、来源比对与内容验证。
C2PA 证明"from where/how"，不证明"what is true"。两者是不同维度，需区分来源可追溯与事实准确性。
JWT/OAuth 令牌在多 Agent 跨服务调用中应如何逐层收缩权限（token exchange）？
多 Agent 跨服务调用用 token exchange 进行权限收缩：每一步调用用现有令牌换取一个 scope 更窄、仅限后续动作的新令牌，使下游服务只获得所需权限，而非原始高权限。通过声明新的 audience、scope、action 限制令牌的应用范围，实现"逐层降权"。同时保留可追溯的身份链（actor 声明），便于审计。
token exchange 是"权限随调用深度收缩"的关键。每层只给所需权限，降低权限放大与横向移动风险。
审计日志本身如何防篡改、控制访问、设置保留期并支持事件检索？
审计日志防篡改：写入后不可变（append-only）、用哈希链或签名校验完整性、存到 WORM 存储或受控日志系统；访问控制：严格限制谁能读/写/删日志，最小权限 + 审计对审计的访问；保留期：按合规要求设置（如法定年限），到期归档或删除；事件检索：结构化字段（时间、用户、动作、资源、结果、trace ID）支持按需检索与查询，配合索引与查询权限。
审计日志是"可信证据"，需防篡改、可控、可保留与可检索。防篡改是合法性与可追溯性的基础。
为什么不能假设"系统 Prompt 不泄露"？审计日志应如何记录模型实际接收的完整 Prompt？
系统 Prompt 可能被注入、提取或泄露，因此不能假设其保密。审计日志应记录模型实际接收的完整 Prompt（含系统提示 + 用户输入 + 检索上下文 + 工具结果），以便事件回溯、定位问题与取证。但完整 Prompt 含敏感内容，需在存储时加密、脱敏或受限访问，并按保留期管理，平衡"可审计"与"隐私合规"。
完整 Prompt 是 AI 事件溯源的"原始证据"。记录它才能还原"模型看到什么"，但需要脱敏与访问控制。
MCP 接入的 OAuth 授权：资源服务器授权、PKCE 与令牌作用域如何落地？相比 API Key 直连解决了哪些信任问题？
MCP 接入用 OAuth 授权：资源所有者授权后，客户端用授权码（配合 PKCE 防拦截）换取令牌，令牌携带受限作用域（scope）限制可访问的资源与操作。相比 API Key 直连：OAuth 支持用户级授权（可区分用户、可撤销、可审计）、作用域受限（最小权限）、令牌短期可刷新，解决了 API Key 共享、不可撤销、权限过大的信任问题。PKCE 防止授权码被窃取，作用域限制访问范围。
OAuth 把"共享密钥"升级为"用户授权 + 作用域 + 可撤销"。PKCE 与 scope 是安全落地的关键。
授权决策缓存：在 PDP/PEP 分离下，权限变更后的缓存失效策略如何设计，如何平衡撤销即时性与性能？
在 PDP（策略决策点）/PEP（策略执行点）分离下，PEP 缓存 PDP 的授权决策以提升性能，但权限变更后需失效缓存。策略：设置短 TTL（如秒级）让缓存自动过期；对敏感操作/高风险权限采用实时校验（不缓存或长短 TTL）；变更时主动失效（事件通知/版本号）；关键操作做强制实时评估。平衡：一般操作走缓存保性能，高风险操作实时校验保即时性。
缓存提升性能但牺牲撤销即时性。用"分级 TTL + 主动失效 + 高风险实时"实现平衡。
第三方组件（开源模型、MCP Server）的依赖升级应在多久内完成评估与跟进？
第三方组件升级应建立评估流程：对安全补丁/高危漏洞尽快评估（如 7 天内评估、关键漏洞即时跟进），对常规版本按发布节奏评估；升级前做兼容性、安全性与回归测试，评估变更影响（行为变化、供应链风险）。依赖升级应纳入版本管理与 SBOM 跟踪，高危漏洞自动通知并限时处理。
及时性取决于风险等级。关键符号：高危漏洞快速评估跟进，常规版本计划性升级，并配合 SBOM 与 CVE 监控。
为什么不能将 RBAC 简化为"角色越多越安全"？过度角色为何增加管理成本与误配？
RBAC 的"安全"取决于角色是否与职责匹配、最小权限是否落实，而非角色数量。过度拆分角色会增加管理成本（角色维护、指派、审计），且角色间边界模糊易误配（用户被授予意外权限），反而降低安全。应基于职责与最小权限设计适度角色，配合定期角色复审与权限审计，避免角色膨胀。
角色设计的核心是"职责驱动 + 最小权限 + 可维护"。角色越多≠越安全，需平衡与复审。
审计与告警应如何在异常操作（如凌晨批量删除）中触发即时人工干预？
通过审计日志与规则引擎检测异常操作（如非工作时间批量删除、超量删除、异动权限、高并发敏感操作），触发告警；告警按严重度分级，高风险操作即时通知值班人员并暂停/挂起操作；人工介入复核后决定放行/回滚/阻断。异常检测基于基线（正常行为模式）与规则（时间、量级、频次），并配合止损机制。
异常检测 + 即时告警 + 人工干预 + 回滚，构成对异常操作的响应闭环。关键在"检测到即冻结"。
ABAC 在多 Agent 跨域调用时如何表达 tenant、resource、action 三元关系？
ABAC 用属性（subject、resource、action、environment）表达授权。多 Agent 跨域调用时，把 tenant、resource、action 作为策略条件：策略定义"主体（含租户、角色）对某租户内某资源执行某动作"的允许规则，如"subject.tenant == resource.tenant && action in allowedActions"。跨域时通过上下文属性（调用链身份、目标资源）动态评估，实现细粒度、可扩展的授权。
ABAC 用属性组合表达复杂授权，比角色更灵活。三元关系（tenant/resource/action）作为策略条件实现跨域细粒度控制。
后台异步任务的身份保留：用户触发、服务端执行时如何延续并降权原身份，防止长任务越权？
后台异步任务由用户触发，服务端执行时应延续原用户身份（保留 actor 与权限上下文），但执行期间降权到任务所需的最小权限，避免长任务期间权限扩大或凭证过期导致越权。实践：用受限 token 承载身份与降权 scope，任务执行时重新校验权限与资源范围，对敏感操作实时鉴权；任务凭证短期化并随任务上下文传递，防止被复用。
长任务风险是"执行时间超过权限有效期/权限漂移"。身份延伸 + 降权 + 执行时实时鉴权可防越权。
敏感操作审计应记录谁、何时、对什么、参数摘要、授权依据、结果和关联 Trace 的哪些字段？
敏感操作审计应记录：主体（谁，含用户与身份链）、时间（何时）、对象（对什么资源/操作）、参数摘要（脱敏后的请求参数）、授权依据（校验通过的策略/权限声明）、结果（成功/失败及错误码）、关联 Trace（请求 ID、trace ID、会话 ID）等字段。这些字段使审计证据可追溯、可定责、可复现，并支持跨服务关联。
审计字段的完整性决定"可追责性"。参数摘要（脱敏）与 Trace 关联保证可复盘与联动排查。
模型、SDK、MCP Server、容器和生成代码的供应链如何使用固定版本、签名、SBOM 与 SCA 治理？
供应链治理：固定版本（锁定模型、SDK、MCP Server、容器镜像的版本，阻止漂移）；签名校验（验证来源与完整性，防篡改）；SBOM（生成软件物料清单，记录各组件的版本与依赖）；SCA（静态成分分析扫描已知漏洞与许可证）。对生成代码做来源记录与人工审查。统一纳入准入、审批与定期复审，形成可追溯的供应链管理。
固定版本与签名管"是什么、从哪来"，SBOM 管"包含什么"，SCA 管"有无漏洞"。四者组合成供应链治理闭环。
企业级 AI 应用的细粒度授权：工具、资源与数据三者的 ABAC 策略应如何建模？规则变更如何灰度生效？
ABAC 建模把工具（可执行的操作）、资源（操作对象）、数据（数据范围）作为属性与策略条件：策略定义"主体对某工具，在满足资源与数据条件时允许执行"，如"subject.dept == resource.dept && data.level <= subject.clearance"。规则变更灰度：用策略版本化、用灰度开关（按租户/用户比例）逐步生效，先观察/审计再全量，配合回滚与告警，降低变更风险。
工具/资源/数据三元建模是细粒度授权的基础。灰度生效保证策略变更"可观测、可回滚、低风险"。
审计日志的保留期与数据主权：在跨地域合规要求下，日志分域存储、导出与删除如何设计？
跨地域场景下，审计日志按数据主权设计：日志分域存储（每个地区的数据留在对应区域，满足数据驻留）；按各地区法规设置保留期（TTL/法定年限）；导出需合规评估并脱敏（跨境传输需审批）；删除需支持按用户/按区域发起删除并传播到各副本与备份。通过数据目录与区域策略管理各域日志的存储、导出与删除。
数据主权要求"分域存储、合规保留、受控导出、可删除"。区域策略与数据目录是落地的关键。
