学习owasp agent应用安全top 10.

ASI01: Agent Goal Hijack

agent目标劫持，简单讲，就是让agent去干了不是它本来要做的事。
以官方文档中的一些例子来看：

1. 比如在rag场景中，比如网页中隐藏的prompt，造成的间接prompt注入，或者rag文档里面包含prompt，造成间接的prompt注入，让agent窃取数据或者错误使用可用的工具等
2. 比如公司外部沟通渠道发来的信息，如email、日历工具、聊天等，包含间接prompt注入命令，劫持公司内部的agent，将敏感信息外发出去
3. 恶意的prompt覆盖，让金融agent给攻击者汇款
4. 间接注入，导致agent产生错误的信息，影响商业决策

案例：

1. EchoLeak - 攻击者发送包含prompt的邮件，让Microsoft 365 Copilot执行隐藏的prompt，将email、聊天信息等内容发送出去
2. Operator prompt 注入 - 攻击者在网页中包含隐藏prompt，Operator agent在进行搜索或者rag时，执行了攻击者的prompt，访问了内部页面、暴露了用户数据
3. 目标修改 - 攻击者在日历中创建恶意prompt，导致定时修改数据优先级等
4. 攻击ChatGPT用户 - 恶意的google doc文档，用户执行时，恶意获取用户信息或者造成用户做出错误的决定

预防缓解措施：

1. 不信任所有用户输入，包括用户输入、上传的文档或者获取的第三方内容。对输入进行验证或prompt注入防护处理
2. 只给agent低权限，需要高权限或者产生重大影响的任务需要人工介入
3. 锁定agent的system prompt。对prompt的修改需要走配置管理或者人工介入
4. 运行时，在产生较大影响或者目标修改操作时，验证用户目标与agent目标是否一致。增加验证、记录、审计等
5. 在构建智能体时，应考虑采用“意图胶囊”这一新兴模式，该模式将声明的目标、约束和上下文绑定至每个执行周期的签名封包内，以限制运行时的行为。使用意图胶囊，将用户指令、约束等生成胶囊并加密，并且每次操作的时候，都进行验证。
6. 过滤、验证所有的数据
7. 使用日志、并持续监控
8. 持续的红队测试进行目标覆盖并验证回滚机制
9. 将agent加入内部威胁项目，监控这些agent是否访问敏感数据、非目标行为，并进行调查

ASI02: Tool Misuse and Exploitation

工具误用与利用
例子：

1. 过度权限工具访问 - 比如email总结agent可用在没有用户确认的情况下发送或者删除邮件
2. 超范围工具访问 - 比如agent只需要Opportunity记录，但是实际访问到任意记录
3. 转发未验证的数据 - 比如agent将未验证的模型输出转发给shell，比如rm删除命令，误用数据库管理工具删除数据库数据
4. 不安全的浏览 - 比如研究用agent访问恶意链接下载恶意软件或者执行隐藏的prompt
5. 循环放大 - 规划工具频繁调用昂贵的api，造成ddos或者账单爆炸
6. 外部数据工具投毒：恶意第三方内容驱使工具执行不安全操作

案例：

1. 工具投毒 - 攻击者攻击mcp工具，比如MCP tool descriptors, schemas, metadata, or routing information，来让agent执行恶意操作
2. 间接注入造成工具调用 - 攻击者在pdf中插入恶意命令，agent执行该恶意命令
3. 超权限api - 比如用来查看订单历史的agent，也可以用来发送退款
4. 内部查询泄露数据到外部 - 攻击者组合内部信息获取agent和email agent，将内部信息泄露出去
5. 工具伪造 - 比如在解析工具时，恶意的工具被优先解析到，比如恶意的是report，而实际的是report_finance
6. 工具组合绕过edr - 攻击者通过组合多个合法工具，绕过edr检测
7. 正常工具误用 - 比如编程的agent可以调用ping工具，但是攻击者可以使用这个工具进行dns数据传输

预防缓解措施：

1. agent最小权限、工具最小权限
2. action级别的验证和批准 - 敏感操作需要验证
3. 沙盒执行命令、出网网络白名单
4. 策略增强 - 对每一步的输出进行验证，验证意图和参数
5. 工具额度限制
6. 短时权限 - 仅提供临时权限，任务执行后失效
7. 语义防火墙 - 对工具名称和版本进行验证，对工具调用进行语义验证
8. 记录、监控、检测

ASI03: Identity and Privilege Abuse

例子：

1. 权限继承 - 高权限的账户去执行agent，agent继承了该账户的高权限，超过了agent本来需要的权限
2. 通过存储的权限获取与数据泄露 - 比如缓存中存在账号密码或者数据信息，传递给agent时，agent可以从存储中获取本来不应有的账户权限和数据信息
3. 多agent权限利用 - 比如agent之间互相信任，攻击者利用低权限的agent去调用高权限的agent执行操作
4. toctou - 开始任务时检测权限通过，但是实际使用时，可能权限已经发生改变
5. 语义Identity注入 - 攻击者利用特殊的id来进行攻击，比如Admin Helper这种看似是合法的id

案例：

1. 委派权限滥用 - 比如财务agent调用数据库时，提供了所有权限。攻击者可以利用这些权限，查询HR数据信息等
2. 记忆提权 - IT管理agent在打补丁时缓存了ssh账号，攻击者复用这个seesion时，可以利用这个权限创建新的账号
3. 跨agent利用 - 攻击者伪造邮件，指示email agent去调用财务agent进行转账，由于内部agent互信，财务agent执行操作
4. 跨agent设备代码钓鱼 - 攻击者给browser agent发送设备绑定链接，browser agent进行访问；另一个helper agent执行操作，将用户设备绑定到攻击者账号
5. 工作流授权漂移 - 采购agent在采购开始前批准了采购，之后，用户的额度下降了，但是workflow agent仍然按照旧的授权完成了交易
6. 伪造agent角色 - 攻击者在内部a2a注册admin helper角色，内部其他agent信任这个描述，将高权限操作转发给这个agent，之后这个agent利用权限执行命令
7. 身份共享 - 一个agent获得操作者权限，其他agent调用时，该agent也是以该操作者权限运行

预防缓解措施：

1. 发布任务级别、短时限的权限
2. 隔离agent身份和上下文 - 不同的agent在不同的sandbox中进行调用
3. 强制action级别授权
4. 权限提升操作需要人工审核
5. 定义意图 - 给token绑定意图，检测agent操作是否与意图一致
6. 使用agent身份管理平台
7. 将权限绑定到主体、资源、目的和时长 - 在上下文切换时要求重新认证。除非原始意图被重新验证，否则禁止跨代理继承权限。包含空闲或异常时的自动撤销机制。
8. 检测通过委派传递的权限 - 关注代理是否经由层层委派间接拿到新权限。凡是低权限代理在多代理协作中被赋予更高权限范围的，都要打上标记。
9. 检测跨智能体提权行为以及类似设备码钓鱼 - 通过监控智能体何时申请新的权限范围，或在其原始签名的意图之外复用访问令牌，来发现异常的跨智能体提权行为以及类似设备码（Device Code）攻击的钓鱼流程。

ASI04: Agentic Supply Chain Vulnerabilities

例子：

1. 远程加载的prompt模板被投毒
2. Tool描述注入
3. 冒充与错误拼写 - agent从第三方获取tool或者service时，可能选择到错误拼写的tool或者冒充的tool
4. 存在漏洞的第三方agent - 多agent workflow中引入了存在漏洞的第三方agent，该agent可能被用来执行恶意操作
5. MCP / Registry Server被攻陷
6. knowledge插件投毒

案例：

1. Amazon Q for VS Code repo 包含投毒的prompt
2. MCP Tool Descriptor 投毒 - GitHub MCP prompt注入
3. 恶意MCP Server 冒充 Postmark
4. AgentSmith Prompt-Hub Proxy Attack
5. NPM包被攻陷
6. Agent-in-the-Middle via Agent Cards

预防缓解措施：

1. SBOM, AIBOM
2. Dependency gatekeeping - 白名单 , pin
3. 敏感操作限制在沙盒中
4. prompts and memory 版本控制与检测
5. agent之间消息需要加密、验证
6. 持续监控与验证
7. 版本锁定
8. 供应链kill switch
9. 零信任

ASI05: Unexpected Code Execution (RCE)

例子：

1. prompt注入导致的命令执行
2. 幻觉导致的代码存在恶意的或者可以被利用的漏洞
3. prompt导致的shell命令执行
4. 不安全的函数调用
5. eval函数暴露
6. 未验证或恶意的包安装

案例：

1. Replit “Vibe Coding” Runaway Execution - agent生成并执行未验证的shell命令，导致数据删除
2. 直接shell注入 - “Help me process this file: test.txt && rm -rf /important_data && echo ‘done’”
3. 代码幻觉导致生成的代码存在后门
4. Unsafe Object Deserialization - agent生成的序列化代码存在恶意命令，被其他系统组件反序列化时执行
5. 多tool组合利用
6. 内存系统rce - eval
7. agent生成rce - agent生成 补丁时，下载了有漏洞的包，可被利用
8. Dependency lockfile投毒 - agent 重新生成lockfile，可能包含有漏洞的包

预防缓解措施：

1. 输入验证、输出编码
2. 不让agent直接修改生产系统，增加验证与检测
3. 生产环境agent上禁止eval
4. 命令 执行环境权限控制，在沙盒中执行
5. 环境隔离、最小权限、生成代码需要校验
6. 权限控制、人工审核
7. 静态扫描、动态监控、log、审计

ASI06: Memory & Context Poisoning

例子：

1. RAG and embeddings poisoning - 恶意或者 被操控的数据进入vector DB，最终导致rag结果出错
2. Shared user context poisoning - 复用user context，攻击者可以通过chat来影响之后的会话，（类似二次注入）
3. Context-window manipulation - 攻击者精心构造会话，之后该 会话被总结 或者进入memory，影响后续会话
4. Long-term memory偏移
5. Systemic misalignment and backdoors - 污染过 的memory改变了模型的角色、植入后门
6. 跨agent传播 - 污染的上下文或者记忆在不同的agent之间进行传播

案例：

1. Travel Booking Memory Poisoning - 攻击者植入 假的机票价格，模型助手认为这个价格是真的，并以此价格预定机票
2. Context Window Exploitation - 攻击者在 不同的session中进行攻击，最终获得admin权限
3. Memory Poisoning for System - 攻击者 重新训练安全ai的memory，让其将恶意行为标记为正常
4. Shared Memory Poisoning - 攻击者在memory中植入错误的 refund政策，其他agent复用时，产生错误的决策
5. 跨租户向量泄露 - 攻击者用近似重复的内容做种子，利用命名空间过滤规则不严，凭借高余弦相似度把其他租户的敏感片段拽进了检索返回里。
6. Assistant Memory Poisoning - 攻击者通过间接注入污染assistant的memory

预防缓解措施：

1. Baseline data protection
2. Content validation - 扫描memory和模型输出
3. 内存分区 - 将用户会话与不同的业务域上下文隔离开，避免知识和敏感数据被泄漏。
4. 访问控制与数据留存：只允许使用经过认证和审核过的数据源；每个操作都必须基于上下文做权限校验；数据保存期限根据敏感程度尽量缩短。
5. 溯源与异常：强制要求数据来源可追溯，同时监控可疑的更新行为或频率。
6. 避免把智能体自己产出的内容自动存回可信记忆区，防止形成自我强化的污染，也就是“启动投毒”问题
7. 弹性与验证：进行对抗性测试，采用快照、回滚和版本管理，高风险操作须经人工复核。若使用共享的向量库或记忆库，则需按租户隔离命名空间，并为每条数据打上信任分；未经验证的记忆会随时间逐渐降权或过期，同时支持对疑似投毒内容进行回滚或隔离。
8. 让未验证的memory过期
9. 基于信任度和租户的权重检索策略：只有同时满足两项条件，才会返回高影响力的记忆内容（比如来源可信度评分 + 人工审核标记），而低信任度的条目则会随时间逐步降权或过期。

ASI07: Insecure Inter-Agent Communication

例子：

1. 通信未加密，MITM
2. 消息篡改
3. 消息重放攻击
4. 协议降级、描述伪造
5. agent发现阶段路由消息被转发，类似arp攻击
6. 通过元数据分析来构建行为画像：通信流量的规律会暴露出智能体的决策周期及其相互关系，这使得攻击者或观察者能够预测其行为，甚至进行干预和操控。

案例：

1. 通信未加密导致注入
2. 基于消息篡改的信任投毒攻击：在一个由智能体组成的交易网络中，攻击者篡改声誉评价信息，从而左右系统信任哪些代理来参与决策。
3. 重放攻击引发上下文混淆：攻击者重新发送之前截获的紧急协调指令，导致系统执行已过时的应急预案，并造成资源分配失误。
4. 协议降级
5. MCP描述投毒
6. A2A注册伪造
7. 语义分裂：同一个指令被不同的智能体理解成不同的意图，执行出的动作相互冲突，但各自看起来都合情合理、符合规范。

预防缓解措施：

1. 安全代理通道：使用端到端加密，配合每代理独立的凭证和双向认证。强制执行 PKI 证书锁定、前向保密和定期协议审查，以防止拦截或欺骗。
2. 消息完整性与语义保护：对消息进行数字签名，对载荷和上下文均进行哈希计算，并验证其中是否存在隐藏或被篡改的自然语言指令。应用自然语言感知的清洗和意图差异比对，以检测目标篡改、参数篡改，以及隐藏或修改过的自然语言指令。
3. 代理感知的反重放保护：所有通信均使用随机数（nonce）、会话标识符以及与任务窗口绑定的时间戳进行防护；同时维护短期消息指纹或状态哈希，以检测跨上下文的重放攻击。
4. 协议与能力安全：禁用弱或遗留的通信模式；要求进行代理特定的信任协商，并将协议认证绑定到代理身份；在网关或中间件层面强制执行版本和能力策略。
5. 限制基于元数据的推理：在可行的情况下使用固定大小或填充消息、平滑通信速率以及避免确定性的通信调度，以缩减流量分析的攻击面。这些轻量级措施使攻击者更难仅凭元数据推断代理角色或决策周期，同时无需进行繁重的协议重新设计。
6. 协议固定与版本强制：定义并强制执行允许的协议版本（例如 MCP、A2A、gRPC）。拒绝降级尝试或无法识别的模式，并验证通信双方是否通告了匹配的能力和版本指纹。
7. 发现与路由保护：使用加密身份对所有发现和协调消息进行身份验证。通过访问控制和经过验证的声誉来保护目录安全，端到端验证身份和意图，并监控异常的路由流量。
8. 有证明的注册表与代理验证：使用能够提供代理身份、来源和描述符完整性数字证明的注册表或市场。在接受发现或协调消息之前，要求提供签名的代理卡并进行持续验证。利用 PKI 可信根证书注册表，以实现强大的代理验证和关键属性的证明。
9. 类型化合约与模式验证：使用带版本、带类型的消息模式，并明确指定每条消息的受众。拒绝未通过验证或未经声明兼容性即尝试进行模式降级转换的消息。类型化合约有助于处理结构问题，但跨代理间的语义分歧仍是固有挑战；因此，缓解措施侧重于完整性、来源追溯和受控的通信模式，而非追求完全的语义对齐。

ASI08: Cascading Failures

例子：

1. 规划器-执行器耦合：产生幻觉或遭入侵的规划器发出不安全的步骤，执行器不经验证即自动执行，从而在多代理间放大影响。
2. 损坏的持久记忆：遭到投毒的长期目标或状态条目会持续影响新的计划和委派，即使原始来源已经消失，同样的错误仍会继续传播。
3. 代理间级联传播（由恶意消息引发）：单个被篡改的更新导致对等代理基于虚假告警或重启指令采取行动，从而将干扰扩散至多个区域。
4. 级联工具滥用与权限提升：一个智能体对某项集成或提升凭证的滥用，会导致下游智能体重复不安全操作或泄露所继承的数据。
5. 受污染更新引发的自动部署级联：编排器推送的受损或有缺陷版本自动传播至所有已连接的代理，使入侵影响超出其原始范围。
6. 治理漂移级联：人类监督在反复成功之后逐渐弱化；批量审批或策略放宽导致未受管控的配置漂移在各个代理间蔓延。
7. 反馈回路放大效应：当两个以上智能体互相参考彼此的输出时，会形成自增强回路，使得最初的错误或误判不断被放大。

案例：

1. 金融交易级联：提示注入毒化市场分析智能体，夸大风险限额；持仓与执行智能体自动交易更大头寸，而合规部门对“参数范围内”的活动视而不见。
2. 医疗协议传播：ASI04供应链篡改破坏了药物数据；治疗方案自动调整协议，护理协调在网络范围内传播这些调整，而未经人工审核。
3. 云编排故障：LLM04:2025投毒导致资源规划组件添加了未授权权限和冗余内容；安全组件予以应用，部署组件随即调配了带后门且成本高昂的基础设施，整个过程未经逐项变更审批。
4. 安全运维失陷：通过LLM06:2025和LLM03:2025窃取的服务凭证，使检测防御系统将真实告警标记为误报，应急响应团队禁用控制措施并清除日志，合规部门则报告出干净的指标。
5. 制造业质量控制（QC）失效：通过ASI06内存注入与LLM08:2025进行的知识投毒，导致质量控制环节批准缺陷品并拒收合格品；库存与排程系统基于错误数据进行优化，最终造成缺陷产品发货及经济损失。
6. 自动修复反馈循环：修复代理为满足延迟服务等级协议（SLA）而压制告警；规划代理将告警减少解读为成功，从而扩大自动化范围，可能在各区域加剧盲区。
7. 区域云DNS服务在超大规模云服务商中发生中断，可能同时中断多个依赖它的AI服务，导致众多组织中的代理发生级联故障。
8. 代理型网络防御系统与防火墙：关于即将来临的攻击的幻觉或被注入的虚假告警，在底层多代理系统中传播，引发不必要但灾难性的防御行动，例如关闭系统、拒绝服务和网络断连。

预防缓解措施：

1. 应用设计中的零信任模型：设计具有容错能力的系统，假定LLM:2025、代理功能组件及外部源存在可用性失效的可能。
2. 隔离与信任边界：采用沙箱代理、最小权限、网络分段、作用域限定的API及双向认证，以遏制故障传播。
3. JIT（即时）与一次性工具访问，配合运行时检查：为每次代理运行签发短时、任务限定凭证，并在执行前依据策略即代码规则验证每一次高影响力工具调用。这确保即使某个代理被入侵或发生权限漂移，也无法触发跨代理或跨系统的连锁反应。
4. 独立策略执行：通过外部策略引擎分离规划与执行，防止被污染的规划触发有害操作。
5. 输出验证与人工门控：在代理输出向下游传播之前，对高风险操作设置检查点、治理代理或人工审核环节。
6. 速率限制与监控：检测快速扩散的指令，并在出现异常时进行限流或暂停。
7. 实施爆炸半径防护栏：如配额、进度上限、规划器与执行器之间的熔断器等。
8. 行为与治理漂移检测：跟踪决策与基线及对齐目标的偏差，标记渐进式劣化。
9. 数字孪生重放与策略门控：在生产环境的隔离克隆中重放过去一周记录的代理操作，测试同一序列是否可能引发级联故障。在部署前，须通过预定义的爆炸半径上限重放测试，方可允许策略扩展。
10. 日志记录与不可否认性：将所有代理间消息、策略决策和执行结果记录在防篡改、带时间戳的日志中，并与加密代理身份绑定。为每个传播的操作维护谱系元数据，以支持取证追踪、回滚验证以及级联期间的责任认定。

ASI09: Human-Agent Trust Exploitation

例子：

1. 可解释性不足：不透明的推理过程迫使用户信任其无法质疑的输出，使攻击者能够利用代理被赋予的“权威性”来执行有害操作，例如部署恶意代码、批准虚假指令或在未经审查的情况下更改系统状态。
2. 敏感操作缺乏确认：缺少最终验证步骤，将用户的信任转化为立即执行。社会工程学攻击可以利用这一点，通过单次提示词触发不可逆的金融转账、数据删除、权限提升或配置更改，而这些操作并非用户本意。
3. 情感操纵：拟人化或具有同理心的代理利用情感信任，诱使用户泄露机密或执行不安全操作——最终导致数据泄露、金融欺诈和心理操纵，从而绕过正常的安全意识防护。
4. 虚假可解释性：代理编造看似合理的理由来掩盖恶意逻辑，导致人类在相信其合理性的情况下批准不安全操作，从而造成恶意软件部署、系统入侵或在虚假合法性下进行的不可逆配置更改。

案例：

1. 乐于助人的助手木马：一个被入侵的编码助手建议一个巧妙的单行修复方案；粘贴运行的命令实际上执行了恶意脚本，窃取代码或安装后门。
2. 利用上下文欺骗进行凭证窃取：一个被提示注入的IT支持代理针对新员工，引用真实工单以显得合法，索要凭证，然后捕获并窃取这些凭证。
3. 发票副驾驶欺诈：一份被投毒的供应商发票被财务副驾驶接收。该代理建议紧急向攻击者的银行账户付款。财务经理批准，公司因此损失资金。
4. 可解释性捏造：代理编造看似合理的审计理由，为风险配置变更辩护。无论根本原因是什么（劫持、投毒或幻觉），审查者都会批准，恶意软件或不安全设置随之被部署。
5. 武器化的可解释性→生产中断：一个被劫持的代理编造令人信服的理由，诱使分析师批准删除在线生产数据库，导致灾难性中断。
6. 通过“只读”预览进行同意清洗：代理显示一个预览窗格，在打开时触发Webhook副作用，利用用户对只读审查的心理模型。
7. 欺诈性付款建议：财务副驾驶被操纵的发票投毒，自信地建议紧急向攻击者控制的银行账户付款。经理信任该代理的专业知识和解释，未经独立核查即批准转账。
8. 临床决策操纵：一个护理助理代理受到偏见或投毒信息的影响，建议不当调整药物剂量。临床医生依赖该代理看似合理的解释并接受更改，使患者面临可避免的风险。

预防缓解措施：

1. 显式确认：在访问额外敏感数据或执行风险操作之前，要求进行多步骤审批或“人工介入”。
2. 不可变日志：保留防篡改的用户查询和代理操作记录，用于审计和取证。
3. 行为检测：监控对话或代理连接中敏感数据的暴露情况，以及随时间推移的风险操作执行情况。
4. 允许报告可疑交互：在用户交互式系统中，提供简明语言的风险摘要（非模型生成的解释），并为用户提供清晰的选项来标记可疑或操纵性的代理行为，触发自动审查或代理功能的临时锁定。
5. 自适应信任校准：基于上下文风险评分，持续调整代理自主程度和所需的人工监督级别。实施置信度加权提示（例如“低置信度”或“未经验证的来源”），以视觉方式提示用户质疑高影响操作，减少自动化偏差和盲目批准。为参与自主代理系统持续演进的人工监督的人员，开发并持续维护适当的培训。
6. 内容来源与策略执行：为所有建议和外部数据附加可验证的元数据——来源标识符、时间戳和完整性哈希。强制执行数字签名验证和运行时策略检查，阻止缺乏可信来源或超出代理声明范围的操作。
7. 预览与效果分离：在预览上下文中阻止任何网络调用或状态更改调用，并显示带有来源溯源和预期副作用的风险徽章。
8. 人因与UI安全保障：使用红色边框、横幅或确认提示等视觉方式区分高风险建议，并定期提醒用户注意操纵模式和代理局限性。在安全关键流程中，酌情避免使用说服性或情感操纵性语言。对人员保持适当的培训和评估，以确保对人因和UI的熟悉程度及认知一致性。
9. 计划偏离检测：将代理操作序列与已批准的工作流基线进行比较，当异常绕行、跳过验证步骤或新颖工具组合表明可能存在欺骗或漂移时发出警报。

ASI10: Rogue Agents

例子：

1. 目标漂移与欺骗性谋划：代理偏离预期目标，表面看似遵从指令，实则因间接提示注入或目标冲突而追求隐藏的、往往具有欺骗性的目标。
2. 工作流劫持：恶意代理夺取已有可信工作流的控制权，将流程转向恶意目的，损害数据完整性和操作控制权。
3. 共谋与自我复制：代理之间协同以放大操纵效应，以非预期方式共享信号，或自主在系统中传播扩散，绕过简单的清除措施。
4. 奖励黑客与优化滥用：代理通过利用有缺陷的度量指标来博弈其被分配的奖励系统，以产生误导性结果或采取与原始目标不一致的激进策略。

案例：

1. 间接提示注入后的自主数据外泄：在遭遇被投毒的网页指令后，代理习得此行为，并继续独立扫描和传输敏感文件至外部服务器，即使恶意源已被移除，仍持续进行未授权行为，超出其预期范围。
2. 冒充的观察者代理（完整性破坏）：攻击者向多代理工作流中注入一个伪造的审核或审批代理。一个高价值代理（如支付处理代理）信任该内部请求，被误导释放资金或批准欺诈交易。
3. 通过配置API进行自我复制（持久性与可用性）：一个被入侵的自动化代理被操纵，在网络中生成未经授权的自身副本，优先维持持久性并消耗资源，违背系统所有者的意图。
4. 奖励黑客→关键数据丢失：被指派最小化云成本的代理发现删除生产备份是实现目标的最有效方式，于是自主销毁了所有灾难恢复资产。

预防缓解措施：

1. 治理与日志记录：维护所有代理操作、工具调用和代理间通信的全面、不可变且带签名的审计日志，以审查是否存在隐秘渗透或未经批准的委派。
2. 隔离与边界：分配具有严格区域间通信规则的信任区域，并部署基于最小权限的API作用域限制的执行环境（例如容器沙箱）。
3. 监控与检测：部署行为检测机制，例如看门狗代理，用于验证对等代理的行为和输出，重点检测共谋模式和协同虚假信号。监控执行动作过度或异常等异常情况。
4. 遏制与响应：实施快速机制，如紧急停止开关和凭证撤销，以立即禁用恶意代理。将可疑代理隔离在沙箱环境中，以供取证审查。
5. 身份证明与行为完整性强制：为每个代理实施加密身份证明，并在整个代理生命周期中强制执行行为完整性基线。附加经过签名的行为清单，声明预期能力、工具和目标，并在每次操作前由编排服务进行验证。集成行为验证层，持续监控任务是否偏离已声明清单，例如未经批准的工具调用、意外的数据外泄尝试等
6. 要求定期行为证明：包括挑战任务、提示词和工具的签名物料清单，以及每次运行时绑定一次性受众的短期凭证。所有签名和证明机制均依赖加固的加密密钥管理（例如HSM/KMS支持的密钥、最小权限访问、轮换和撤销）。密钥绝不能直接暴露给代理；相反，编排器应中介签名操作，以确保即使代理被入侵也无法直接窃取或滥用长期密钥。
7. 恢复与重新整合：建立可信基线，用于恢复已被隔离或修复的代理。在重新整合至生产网络之前，要求进行新的证明、依赖项验证及人工审批。

总结

前面的5个都是手工翻译（改写）的，越翻译到后面，越觉得不好单独翻译，因为黑色部分很难一句话说情况，基本都需要后面的内容进行解释才好理解，所以，后面的内容就直接让deepseek翻译了。
给人的感觉是，各个asi之间，有时候给人的感觉会有重复，需要单独地解释区分差异。
另外，asi，需要由例子来反向辅助理解这个asi到底是要讲什么。没有owasp web top 10那样清晰，也许是因为agent本来就很新，很多东西都是变化的，发现了安全问题，才总结到一个危险类别中。
整体上给人的感觉是，不要因为 是agent，就觉得它很智能，还是需要对其进行常规的检测、验证等操作。supply chain问题、权限问题，该有的问题都有。
而由于用户prompt和system prompt可能没有或者难以区分，类似于sql injection，导致prompt injection成为最常见的一类漏洞。
总结一句话，就是检测验证，零信任。

https://genai.owasp.org