我们已经知道什么，也清楚还不知道什么
用当前证据状态直接限定管理层可做的决策。
现在足以批准控制架构和证据契约，不足以做产品排名或生产就绪认证。
50条证据、9个Claim、9类威胁、17条平台能力断言；独立产品级佐证仍为0。
evidence_system_v3data/evidence_coverage.json“官方已实现”只证明存在能力面，不等于独立验证有效。
批准Reference控制架构；冻结跨平台排名和采购推荐。
Report Outline v9Evidence-backed narrativeUpstream of v9 deck
AI Security 主汇报大纲：用证据回答决策问题
不再重复“核心证据 / 边界 / 下一动作”模板。每页围绕一个具体判断组织证据、反证边界、管理动作和专属画面。
安全对象不是一次回答，而是跨时间的执行权
重新定义Agent安全的控制对象。
状态、身份、委托、工具、数据流和副作用共同组成持续权限。
CLM-001、CLM-005、CLM-007共同表明风险可跨步骤、会话和工具传播。
CLM-001CLM-005CLM-007这是系统边界判断，不代表所有低风险助手都需要最高控制强度。
所有高影响Agent先做Authority Timeline建模。
公开攻击证据已经穿透到工具和凭据层
用真实研究替代抽象威胁描述。
不可信上下文可以改变工具选择、参数和授权使用，形成真实业务副作用。
GitHub VS Code安全研究、AgentDojo和MCP客户端工具投毒研究形成相互印证。
EV-GITHUB-VSCODE-PIEV-AGENTDOJOEV-MCP-CLIENT-POISONING研究证明可行性，不证明生产发生率，也不能永久代表后续版本。
将间接注入和工具投毒纳入高风险Agent准入测试。
Memory 是延迟生效的权限通道
把Memory从功能组件提升为安全控制对象。
一次不可信写入，可以在未来会话被当成可信上下文，并触发工具行为。
CLM-005、THR-003和memory_control_contract将风险拆成写入、持久化、检索、行动使用。
CLM-005THR-003data/memory_control_contract.json当前直接实证仍少于提示注入；需要版本化和跨会话测试。
高风险Memory必须具备写授权、来源、TTL、检索过滤和可清除能力。
Agent身份与工作负载身份解决不同问题
避免把业务责任和运行实例证明混为一谈。
Agent身份回答“谁负责”，工作负载证明回答“谁在运行”。
Entra Agent ID提供Sponsor/Actor/禁用能力；SPIFFE/SPIRE提供工作负载ID和证明。
EV-ENTRA-AGENT-IDEV-ENTRA-ACTOR-CHAINEV-ENTRA-REVOCATIONEV-SPIFFEEV-SPIREEntra是厂商能力证据；SPIFFE是标准基线，二者尚无统一效果比较。
Reference中同时定义业务Agent主体和运行实例主体。
委托链必须保留“用户主体 + Agent Actor”
明确跨跳调用中的责任和权限收缩。
身份、代表关系、受众、Scope和TTL必须在每一跳显式绑定。
RFC 8693、MCP受众绑定与禁止Token透传、Entra OBO和AgentCore出站授权形成完整语义链。
EV-OAUTH-RFC8693EV-MCP-AUTHEV-ENTRA-ACTOR-CHAINEV-AWS-AGENTCORE-OUTBOUNDActor链正确不代表Scope、Purpose或业务意图正确。
所有下游Token必须绑定Actor、Audience、资源和短时效。
通过认证，不等于有权执行这个参数
将授权从连接层推进到动作、资源和参数层。
有效主体仍可能请求错误工具、错误资源或危险参数。
OPA/Envoy和AgentCore Cedar证明参数感知策略可实现；CLM-006强调策略表达不等于策略正确。
EV-OPA-ENVOYEV-AWS-AGENTCORE-POLICYCLM-002CLM-006当前参数级控制主要是官方实现面，独立绕过验证仍不足。
高风险工具策略至少绑定Principal、Actor、Action、Resource、Arguments和Context。
Tool描述用于发现，不能用于授予权限
切断工具元数据与执行权限之间的隐式通道。
工具描述、Prompt和Schema均属于不可信发现输入；权限必须来自Grant和Policy。
多工具投毒研究和CLM-007表明，隔离审查单个工具元数据不足以阻断协同攻击。
CLM-007EV-MCP-CLIENT-POISONINGTHR-006签名或可信来源只能确认来源，不能证明描述语义安全。
工具注册、发现、授权三阶段分离；描述变更触发重新审查。
两个分别允许的工具，可以组合成一次未授权外泄
说明工具授权与数据流授权不是同一件事。
允许读取A和写入B，不代表允许A→B的数据流。
THR-009与INV-06要求策略同时绑定来源、目的地、数据分类和业务Purpose。
THR-009INV-06data/execution_invariants.json数据分类和语义Purpose仍可能错误，需要运行时证据和人工升级。
对读写组合建立Source→Destination显式Grant。
Decision Receipt 不是一堆日志，而是一条可审计决定
定义授权决策的最小证据单元。
Receipt必须能回答谁、代表谁、调用什么、针对什么、基于哪版策略、由哪些规则决定。
decision_receipt_contract绑定Principal、Actor、Tool、Resource、Argument Digest、Policy Revision、Rules、Decision、Trace和Redaction。
CLM-006data/decision_receipt_contract.jsonEV-OTEL-GENAIReceipt包含敏感信息；完整性、最小化和隐私必须同时设计。
Reference Gateway输出统一Decision Receipt并做完整性保护。
可追责依赖跨系统证据关联，而不是单点日志
建立调查和责任认定所需的证据链。
身份事件、策略决定、工具Trace和目标系统日志必须通过稳定关联ID连接。
CLM-009、THR-007和OpenTelemetry字段共同支持跨系统Correlation。
CLM-009THR-007EV-OTEL-GENAIsources/primary_source_pack_10_audit_attribution.md外部系统可能丢失关联ID；缺失链路必须被显式标记。
统一Trace ID、Decision ID、Tool Call ID和Target Receipt引用。
签名证明“它是谁”，不能证明“它会不会作恶”
准确限定供应链签名、证明和扫描的价值。
Provenance是准入必要条件，但真实行为仍需策略和运行时控制。
CLM-008、artifact_admission_contract和供应链来源包支持签名、Attestation、扫描与门禁。
CLM-008data/artifact_admission_contract.jsonsources/primary_source_pack_09_supply_chain_provenance.md真实签名的工具仍可能存在漏洞、隐蔽行为或协同投毒。
制品准入采用“来源+完整性+扫描+策略+运行观测”五道门。
恢复策略必须在动作发生前按可逆性分级
把恢复从事故后流程前移到授权前控制。
直接回滚、业务补偿、仅可遏制和不可逆动作需要不同的前置审批。
CLM-004、Saga/Compensation模式和side_effect_reversibility形成四级恢复模型。
CLM-004EV-AWS-SAGAEV-AZURE-COMPENSATIONdata/side_effect_reversibility.json撤销身份只能停止未来权限；补偿可能不完整、延迟或失败。
高影响工具Grant必须包含Reversibility Class和Recovery Owner。
控制强度应随业务影响分级，而不是一刀切
将六控制面变成可执行的风险分级Profile。
低风险助手可简化控制；高影响Agent必须闭合身份、委托、参数、数据流、Receipt和恢复。
execution_invariants和decision_maturity_matrix支持风险分级，而非普遍最大化。
data/execution_invariants.jsondata/decision_maturity_matrix.json风险等级本身需要业务Owner确认，不能只由模型或平台自动决定。
建立L1/L2/L3 Agent准入Profile和必选控制清单。
市场能力正在增加，但产品级独立证据仍为空
把平台矩阵用于能力定位，而不是形成榜单。
Entra和AgentCore已公开身份、委托、策略、日志和撤权能力面；独立产品级佐证仍为0。
17条平台断言中，官方实现面逐步丰富，但尚不足以比较真实防护效果。
data/platform_capabilities.jsonevidence_system_v3Not found不等于不支持；Implemented不等于独立有效。
仅选择可接入候选进入定向验证，不发布Top榜。
下一步不是“大测一遍”，而是验证会改变决策的缺口
把有限实验资源投向证据冲突和关键未知。
优先验证Memory跨会话投毒、参数策略绕过、数据流组合、Receipt完整性和补偿成功率。
这些缺口直接影响高风险Agent是否准入，以及选择何种控制Profile。
data/evidence_coverage.jsonsources/insight_synthesis_v2.md公开Benchmark仍只提供下限；必须使用企业工具和真实副作用模型。
建立五个定向测试包，保留正常任务基线和原始Receipt。
Reference方案：身份链 + Gateway策略 + Receipt + 恢复
将证据结论收敛成最小可实施控制架构。
Gateway是集中执行点，但身份、目标系统日志和业务补偿仍需端到端协同。
SPIFFE/Entra、RFC8693/MCP、OPA/Cedar、OpenTelemetry和Saga模式分别锚定关键组件。
EV-SPIFFEEV-OAUTH-RFC8693EV-MCP-AUTHEV-OPA-ENVOYEV-OTEL-GENAIEV-AWS-SAGA这是验证架构，不是唯一技术选型，也不是生产上线认证。
用一个高风险业务Agent实现Reference，并输出端到端证据包。
本轮建议：批准控制建设，拒绝过早结论
明确管理层当前可批准和应暂缓的事项。
现在应把证据转化为Reference控制能力，而不是转化为产品排名。
9个Claim已形成相对稳定的控制判断，但0条独立产品断言仍阻止采购和生产认证。
data/claims.jsondata/evidence_coverage.jsondata/decision_maturity_matrix.json无独立验证、原始日志、正常基线、Decision Receipt和恢复记录，不做效果结论。
批准Reference架构、风险分级Profile、证据契约和五项定向测试。