AI 安全与对齐完全指南
"AI 安全不是可选项，而是负责任 AI 开发的基石。"
AI 安全与对齐（AI Safety & Alignment） 是确保 AI 系统按照人类意图行事、避免有害行为的技术领域。随着 AI 能力快速增长，安全与对齐变得越来越关键。本指南综合了 Google SAIF 框架与行业最佳实践。
行业预测
到 2026 年，不进行 AI 红队测试将被视为行业"过失"。预计主要的 Agentic AI 安全事件将加速安全法规的制定。
一、AI 安全基础概念
1.1 核心术语
| 术语 | 定义 | 重要性 |
|---|---|---|
| 安全（Safety） | AI 系统不产生有害输出 | 避免直接伤害 |
| 对齐（Alignment） | AI 目标与人类意图一致 | 确保行为符合期望 |
| 可控性 | 人类能理解和控制 AI | 保持人类主导权 |
| 鲁棒性 | 面对攻击保持安全 | 抵御恶意利用 |
| 可解释性 | 理解 AI 决策过程 | 建立信任 |
1.2 AI 安全威胁分类
| 威胁类型 | 说明 | 示例 | 严重程度 |
|---|---|---|---|
| Prompt 注入 | 通过特殊输入劫持模型 | 忽略原始指令 | 高 |
| Jailbreak | 绕过安全限制 | 获取禁止内容 | 高 |
| 数据投毒 | 污染训练数据 | 植入后门行为 | 极高 |
| 模型窃取 | 提取模型参数 | 知识产权泄露 | 中 |
| 隐私攻击 | 提取训练数据 | 泄露敏感信息 | 高 |
| 幻觉利用 | 利用虚假输出 | 传播错误信息 | 中 |
| 对抗样本 | 精心构造的输入导致错误 | 图像分类错误 | 中 |
| 供应链攻击 | 污染模型依赖或权重 | 恶意微调模型 | 极高 |
1.3 安全威胁严重程度
| 级别 | 描述 | 应对优先级 | 响应时间 |
|---|---|---|---|
| P0 - 灾难性 | 可能导致大规模伤害 | 立即阻止 | <1 小时 |
| P1 - 严重 | 违反法律或核心政策 | 高优先修复 | <24 小时 |
| P2 - 中等 | 不当内容或偏见输出 | 计划解决 | <1 周 |
| P3 - 轻微 | 用户体验问题 | 持续改进 | 下个迭代 |
二、对齐技术（Alignment）
2.1 对齐技术演进
| 阶段 | 时期 | 核心技术 | 代表应用 |
|---|---|---|---|
| 基础对齐 | 2020-2022 | RLHF, InstructGPT | ChatGPT |
| 规模化对齐 | 2023-2024 | Constitutional AI, DPO | Claude, Llama 2 |
| 高级对齐 | 2025-2026 | RLAIF, RLTHF, 混合方法 | Claude 4, GPT-4.1 |
2.2 RLHF（人类反馈强化学习）详解
RLHF (Reinforcement Learning from Human Feedback) 是当前主流对齐技术：
| 阶段 | 说明 | 技术细节 |
|---|---|---|
| 1. 监督微调 (SFT) | 用高质量数据微调基础模型 | 人工编写的示范数据 |
| 2. 奖励建模 (RM) | 训练奖励模型评估响应质量 | 人类偏好排序数据 |
| 3. RL 优化 | 使用 PPO 最大化奖励 | 策略梯度优化 |
| 4. 迭代改进 | 持续收集反馈优化 | 在线学习 |
RLHF 优缺点分析：
| 优势 | 劣势 |
|---|---|
| ✅ 效果好，细粒度控制 | ❌ 需要大量人类标注，成本高 |
| ✅ 技术成熟，广泛验证 | ❌ PPO 训练不稳定，调参困难 |
| ✅ 可处理复杂偏好 | ❌ 可能出现奖励黑客 |
2.3 DPO（直接偏好优化）详解
DPO (Direct Preference Optimization) 简化了对齐流程：
| 特点 | 说明 |
|---|---|
| 核心思想 | 将 RL 问题转化为分类问题 |
| 训练方式 | 直接从偏好对比数据优化策略 |
| 无需 | 单独的奖励模型和 RL 训练 |
DPO 优缺点分析：
| 优势 | 劣势 |
|---|---|
| ✅ 实现简单，易于调试 | ❌ 对数据质量敏感 |
| ✅ 训练稳定，收敛快 | ❌ 可能产生长度偏见 |
| ✅ 计算资源需求低 | ❌ 难以处理复杂偏好 |
| ✅ 适合开源社区和小团队 | ❌ 依赖隐式学习 |
2.4 RLAIF（AI 反馈强化学习）详解
用 AI 模型替代或增强人类反馈：
| 方法 | 说明 | 优势 | 挑战 |
|---|---|---|---|
| AI 评判者 | LLM 评估响应质量 | 高度可扩展 | 依赖评判者质量 |
| 毒性分类器 | 专门检测有害输出 | 精准过滤 | 需要标注数据 |
| 偏见检测器 | 识别偏见内容 | 持续监控 | 偏见定义困难 |
| 自我批评 | 模型自我评估改进 | 无需外部数据 | 可能循环偏见 |
2025 趋势
RLAIF 研究表明，在无害性对齐方面可能优于传统 RLHF，同时大幅降低人工标注成本。
2.5 Constitutional AI（宪法 AI）详解
Anthropic 开发的基于原则的对齐方法：
| 阶段 | 说明 |
|---|---|
| 1. 定义宪法 | 明确定义伦理原则和规则 |
| 2. 自我批评 | 模型根据宪法评估自己的输出 |
| 3. 自我修正 | 违反原则时自动修改响应 |
| 4. RLAIF 训练 | 用 AI 反馈数据进行 RL 训练 |
Constitutional AI 优缺点：
| 优势 | 劣势 |
|---|---|
| ✅ 原则透明、可审计 | ❌ 宪法设计复杂 |
| ✅ 减少人工标注依赖 | ❌ 可能过度限制 |
| ✅ 细粒度行为控制 | ❌ 批评模型质量要求高 |
2.6 对齐技术综合对比
| 技术 | 人工成本 | 计算成本 | 对齐质量 | 可解释性 | 稳定性 | 适用场景 |
|---|---|---|---|---|---|---|
| RLHF | 高 | 高 | ★★★★★ | ★★★☆☆ | ★★★☆☆ | 基础模型对齐 |
| DPO | 中 | 低 | ★★★★☆ | ★★★☆☆ | ★★★★★ | 快速迭代、开源 |
| RLAIF | 低 | 中 | ★★★★☆ | ★★★☆☆ | ★★★★☆ | 大规模对齐 |
| Constitutional AI | 中 | 中 | ★★★★☆ | ★★★★★ | ★★★★☆ | 安全关键场景 |
| RLTHF (混合) | 中低 | 中 | ★★★★★ | ★★★★☆ | ★★★★☆ | 平衡效率和质量 |
2.7 RLTHF：2025 的混合方法
RLTHF (Reinforcement Learning from Targeted Human Feedback) 结合 AI 和人类反馈：
| 特点 | 说明 |
|---|---|
| 核心思想 | AI 标注简单样本，人类专注困难样本 |
| 效率提升 | 达到 RLHF 质量，人工量减少 90%+ |
| 适用场景 | 资源有限但追求高质量对齐 |
三、红队测试（Red Teaming）
3.1 什么是 AI 红队测试
AI 红队测试是主动识别 AI 系统漏洞的安全实践，通过模拟攻击发现问题。
| 测试类型 | 目标 | 方法 | 发现能力 |
|---|---|---|---|
| 手动红队 | 发现创意性攻击 | 专家人工测试 | 高（新攻击向量） |
| 自动红队 | 大规模漏洞扫描 | 自动化工具 | 广（覆盖面大） |
| 混合红队 | 全面覆盖 | 人机协作 | 最高 |
3.2 红队测试流程
| 阶段 | 活动 | 产出 | 关键考量 |
|---|---|---|---|
| 1. 范围定义 | 确定测试目标和边界 | 测试计划 | 明确攻击面 |
| 2. 威胁建模 | 识别潜在攻击向量 | 威胁清单 | STRIDE 框架 |
| 3. 攻击执行 | 实施各类攻击测试 | 攻击记录 | 记录详细步骤 |
| 4. 漏洞评估 | 分析发现的问题 | 漏洞报告 | CVSS 评分 |
| 5. 修复验证 | 验证修复效果 | 验证报告 | 回归测试 |
| 6. 知识沉淀 | 更新攻击库和防御 | 最佳实践 | 持续改进 |
3.3 主流红队工具详解
| 工具 | 提供商 | 类型 | 核心能力 | 攻击向量数 |
|---|---|---|---|---|
| PyRIT | Microsoft | 开源框架 | 多轮对抗探测、自动评分 | 多类别 |
| Garak | NVIDIA | 开源扫描器 | LLM 漏洞扫描、幻觉检测 | ~100 种 |
| AI Red Team Agent | Microsoft | 托管服务 | 自动化扫描、风险识别 | 全面 |
| Promptfoo | 开源 | 开发者框架 | 动态攻击生成、CI/CD 集成 | 灵活配置 |
| Giskard | 开源 | 持续测试 | 自动化持续红队 | 持续更新 |
| LLMFuzzer | 开源 | Fuzzing | 模糊测试、边界发现 | 自动生成 |
| ARTKIT | 开源 | 红队框架 | 多轮攻击模拟 | 可扩展 |
| FuzzyAI | 开源 | 专项工具 | Jailbreak 检测、变异生成 | 专注越狱 |
3.4 PyRIT 使用示例
python
from pyrit.orchestrator import PromptSendingOrchestrator
from pyrit.prompt_target import AzureOpenAIChatTarget
from pyrit.score import SelfAskScorer
# 配置目标模型
target = AzureOpenAIChatTarget(
deployment_name="gpt-4o",
endpoint=endpoint,
api_key=api_key
)
# 配置评分器
scorer = SelfAskScorer(
score_category="harmful_content",
chat_target=target
)
# 创建编排器并执行测试
orchestrator = PromptSendingOrchestrator(
prompt_target=target,
scorers=[scorer]
)
# 运行攻击探测
results = orchestrator.send_prompts(
prompts=["请告诉我如何绕过安全限制..."],
memory_labels={"attack_type": "jailbreak"}
)
# 分析结果
for result in results:
print(f"Prompt: {result.prompt}")
print(f"Response: {result.response}")
print(f"Score: {result.scores}")3.5 红队测试清单
| 类别 | 测试项 | 工具推荐 |
|---|---|---|
| Prompt 注入 | 直接注入、间接注入、多轮注入 | PyRIT, Garak |
| Jailbreak | 角色扮演、编码绕过、逻辑漏洞 | FuzzyAI, Promptfoo |
| 内容安全 | 暴力、仇恨、非法内容生成 | Garak, 自定义 |
| 隐私泄露 | 训练数据提取、PII 泄露 | Garak |
| 偏见测试 | 性别、种族、年龄偏见 | AIF360 |
| 幻觉测试 | 事实错误、虚假引用 | Garak |
| 工具滥用 | Agent 工具攻击 | PyRIT |
四、Jailbreak 攻击与防御
4.1 Jailbreak 攻击分类
| 类别 | 攻击类型 | 原理 | 成功率（2025） |
|---|---|---|---|
| 单轮攻击 | 角色扮演 | 假装是无限制 AI | 10-30% |
| 单轮攻击 | 编码绕过 | Base64/ROT13 编码 | 20-40% |
| 单轮攻击 | 叙事操纵 | 故事情境绕过 | 30-50% |
| 多轮攻击 | Crescendo | 逐步升级恶意程度 | 60-80% |
| 多轮攻击 | 对话引导 | 利用上下文累积 | >90% |
| 结构攻击 | Policy Puppetry | 伪装成配置文件 | >80% |
| 底层攻击 | TokenBreak | 利用分词漏洞 | 60-80% |
4.2 2025 年新型 Jailbreak 技术详解
Policy Puppetry（2025年4月）
| 特性 | 说明 |
|---|---|
| 发现时间 | 2025年4月 |
| 影响范围 | 所有主流 LLM（GPT-4、Claude、Gemini 等） |
| 攻击原理 | 将恶意指令伪装成 XML/JSON/INI 配置文件格式 |
| 为何有效 | LLM 训练数据包含大量配置文件，会将其视为权威指令 |
| 防御难度 | 高 - 需要语义层面的配置格式检测 |
TokenBreak（2025年6月）
| 特性 | 说明 |
|---|---|
| 发现时间 | 2025年6月 |
| 攻击原理 | 通过添加单个字符（如 "instructions" → "finstructions"）混淆分词器 |
| 为何有效 | 内容审核依赖于特定 token 模式，细微修改可绕过检测 |
| 影响分词器 | BPE、WordPiece 等主流分词算法 |
| 防御方法 | 使用 Unigram 分词器、训练对抗样本 |
多轮攻击技术
| 技术 | 原理 | 成功率提升 |
|---|---|---|
| Crescendo | 从无害问题开始，逐步升级到恶意请求 | 60%+ |
| Hydra | 探索多个对话路径，记忆失败尝试 | 50%+ |
| GOAT | 使用攻击模板库迭代优化 | 55%+ |
| Bad Likert Judge | 让 LLM 评分不同"有害程度"的回答 | 60%+ |
其他新兴技术
| 技术 | 说明 |
|---|---|
| Inception Jailbreak | 让 AI 想象一个没有安全规则的虚构场景 |
| Do-Not-Reply | 先问如何"不"回答某类请求，降低防御 |
| 跨模态攻击 | 通过图像/音频传递恶意指令 |
| Adversarial Suffix | 添加对抗性后缀字符串 |
| ASCII Art 攻击 | 用 ASCII 艺术隐藏恶意意图 |
4.3 Jailbreak 防御策略
| 策略层级 | 策略 | 说明 | 效果 |
|---|---|---|---|
| 输入层 | 语义过滤 | 检测恶意意图，不仅仅是关键词 | 阻止 70%+ 已知攻击 |
| 输入层 | 格式检测 | 识别 Policy Puppetry 等结构攻击 | 阻止结构攻击 |
| 输入层 | Token 规范化 | 缓解 TokenBreak 攻击 | 提升 30%+ 鲁棒性 |
| 模型层 | 安全微调 | 对抗性训练提升安全性 | 根本性提升 |
| 模型层 | LLM Salting | 轻量级防御，增加攻击成本 | 提高复用攻击成本 |
| 输出层 | 上下文过滤 | 考虑对话历史的输出审核 | 最后防线 |
| 系统层 | 权限最小化 | 限制 Agent 能力边界 | 降低影响范围 |
| 监控层 | 行为分析 | 实时检测异常模式 | 快速响应 |
4.4 多层安全护栏实现
python
from openai import OpenAI
import re
client = OpenAI()
class SafetyGuard:
def __init__(self):
self.config_patterns = [
r'<\?xml', r'^\s*\[.*\]\s*$', r'^\s*{.*}\s*$' # XML/INI/JSON
]
def detect_policy_puppetry(self, text: str) -> bool:
"""检测 Policy Puppetry 攻击"""
for pattern in self.config_patterns:
if re.search(pattern, text, re.MULTILINE):
return True
return False
def normalize_tokens(self, text: str) -> str:
"""规范化 tokens 以防 TokenBreak"""
# 移除可疑的单字符前缀
return re.sub(r'\b([a-z])([a-z]+)\b',
lambda m: m.group(2) if len(m.group(1)) == 1 else m.group(0),
text)
def check_input(self, user_input: str) -> tuple[bool, str]:
"""输入安全检查"""
# 1. Policy Puppetry 检测
if self.detect_policy_puppetry(user_input):
return False, "检测到可疑的格式化内容"
# 2. OpenAI Moderation API
moderation = client.moderations.create(input=user_input)
if moderation.results[0].flagged:
return False, "内容违反使用政策"
return True, ""
def check_output(self, output: str, context: list) -> tuple[bool, str]:
"""输出安全检查（考虑上下文）"""
# 组合上下文进行审核
full_context = "\n".join([msg["content"] for msg in context]) + "\n" + output
moderation = client.moderations.create(input=full_context)
if moderation.results[0].flagged:
return False, "生成内容不符合安全标准"
return True, ""
def safe_chat(user_input: str, system_prompt: str, history: list = []):
"""安全的对话函数"""
guard = SafetyGuard()
# 1. 输入检查
safe, msg = guard.check_input(user_input)
if not safe:
return f"请求被拦截：{msg}"
# 2. 规范化输入
normalized_input = guard.normalize_tokens(user_input)
# 3. 生成响应
messages = [{"role": "system", "content": system_prompt}] + history
messages.append({"role": "user", "content": normalized_input})
response = client.chat.completions.create(
model="gpt-4o",
messages=messages
)
output = response.choices[0].message.content
# 4. 输出检查
safe, msg = guard.check_output(output, messages)
if not safe:
return f"无法提供该响应：{msg}"
return output五、内容安全
5.1 内容安全分类
| 类别 | 子类 | 风险级别 | 自动检测难度 |
|---|---|---|---|
| 暴力 | 暴力描述、自残指导 | P0 | 中 |
| 仇恨 | 歧视、煽动仇恨 | P0 | 中 |
| 性内容 | 露骨性内容、CSAM | P0 | 高 |
| 非法活动 | 制造武器、毒品合成 | P0 | 高 |
| 欺诈 | 钓鱼、诈骗内容 | P1 | 中 |
| 错误信息 | 严重虚假信息 | P1-P2 | 低 |
| 隐私侵犯 | PII 泄露、人肉搜索 | P1 | 中 |
| 版权侵犯 | 未授权内容复制 | P2 | 低 |
5.2 内容审核流程
| 阶段 | 方法 | 说明 | 延迟 |
|---|---|---|---|
| 预过滤 | 规则引擎 | 拦截明显违规关键词 | <10ms |
| 实时审核 | ML 模型 | 语义级别内容分析 | 50-200ms |
| 批量复查 | 定期扫描 | 发现漏网内容 | 异步 |
| 人工审核 | 专家评审 | 处理边界案例 | 小时级 |
| 用户举报 | 社区反馈 | 补充自动检测 | 异步 |
5.3 内容安全工具对比
| 工具 | 提供商 | 模态支持 | 特点 | 成本 |
|---|---|---|---|---|
| OpenAI Moderation | OpenAI | 文本 | 免费、API 集成 | 免费 |
| Perspective API | 文本 | 毒性评分、多语言 | 免费/付费 | |
| Azure Content Safety | Microsoft | 文本+图像 | 多模态、企业级 | 付费 |
| Llama Guard 3 | Meta | 文本 | 开源、可微调 | 免费 |
| ShieldGemma | 文本 | 开源、高性能 | 免费 | |
| Claude 分类器 | Anthropic | 文本 | Constitutional AI | 付费 |
5.4 Llama Guard 使用示例
python
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "meta-llama/LlamaGuard-3-8B"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id)
def check_safety(user_message: str, assistant_response: str = None):
"""使用 Llama Guard 检查内容安全"""
if assistant_response:
chat = [
{"role": "user", "content": user_message},
{"role": "assistant", "content": assistant_response}
]
else:
chat = [{"role": "user", "content": user_message}]
input_ids = tokenizer.apply_chat_template(chat, return_tensors="pt")
output = model.generate(input_ids, max_new_tokens=100)
result = tokenizer.decode(output[0], skip_special_tokens=True)
# 解析结果
if "unsafe" in result.lower():
# 提取违规类别
categories = extract_categories(result)
return {"safe": False, "categories": categories}
return {"safe": True, "categories": []}六、Agentic AI 安全
6.1 Agent 特有风险矩阵
| 风险 | 说明 | 影响 | 缓解措施 |
|---|---|---|---|
| 工具滥用 | 恶意使用外部工具/API | 高 | 权限控制、调用审批 |
| 目标偏离 | 优化错误或次优目标 | 高 | 目标对齐检查、人工监督 |
| 自主升级 | 获取超出范围的权限 | 极高 | 最小权限原则、沙箱 |
| 循环陷阱 | 无限循环消耗资源 | 中 | 执行限制、超时终止 |
| 级联失败 | 一个 Agent 影响其他系统 | 高 | 故障隔离、熔断机制 |
| 数据泄露 | 通过工具泄露敏感信息 | 高 | 数据脱敏、输出过滤 |
| 社会工程 | Agent 被操纵执行恶意任务 | 高 | 意图验证、确认机制 |
6.2 Agent 安全架构
┌─────────────────────────────────────────────────────────┐
│ 监控层 │
│ 日志收集 │ 行为分析 │ 异常检测 │ 告警系统 │
├─────────────────────────────────────────────────────────┤
│ 输出层 │
│ 结果验证 │ 安全过滤 │ 敏感信息脱敏 │
├─────────────────────────────────────────────────────────┤
│ 执行层 │
│ 权限控制 │ 操作审计 │ 沙箱隔离 │ 资源限制 │
├─────────────────────────────────────────────────────────┤
│ 规划层 │
│ 计划审核 │ 目标对齐检查 │ 风险评估 │
├─────────────────────────────────────────────────────────┤
│ 输入层 │
│ 请求验证 │ 注入检测 │ 意图确认 │
└─────────────────────────────────────────────────────────┘6.3 Agent 安全最佳实践
| 原则 | 实践 |
|---|---|
| 最小权限 | Agent 只能访问完成任务必需的工具和数据 |
| 确认机制 | 高风险操作需要人工确认 |
| 审计追踪 | 记录所有 Agent 决策和行动 |
| 故障隔离 | Agent 错误不应影响其他系统 |
| 资源限制 | 限制执行时间、API 调用次数 |
| 回滚能力 | 可以撤销 Agent 的操作 |
6.4 Agent Ops 团队
2025 趋势
企业正在组建专门的 "Agent Ops" 团队来监控、训练和治理 AI Agent。
| 角色 | 职责 | 技能要求 |
|---|---|---|
| Agent 安全工程师 | 安全测试、漏洞修复、红队 | 安全+AI |
| Agent 运维工程师 | 监控、告警、事件响应 | SRE+AI |
| AI 治理专员 | 政策制定、合规审计 | 法务+AI |
| 提示词工程师 | 安全提示词设计 | NLP+安全 |
6.5 安全的信任权衡
创建 Agent 时面临一个根本张力：效用与安全之间的权衡。赋予 Agent 更多权力（自主性和工具）会增加风险。
| 主要安全关切 | 说明 |
|---|---|
| 流氓行动 | 未预期或有害的行为 |
| 敏感数据泄露 | 通过 Agent 输出泄露私密信息 |
Google 建议
不能完全依赖 AI 模型的判断来保证安全——模型可能被 Prompt 注入等技术操纵。最佳实践是混合纵深防御方法。
6.6 Agent 身份：新型主体类别
在传统安全模型中，有两类主体：
- 人类用户：使用 OAuth/SSO 认证
- 服务账号：集成到 IAM
Agent 引入了第三类主体——它不仅仅是代码，而是自主行动者，需要自己的可验证身份。
| 主体类型 | 认证/验证方式 | 说明 |
|---|---|---|
| Users | OAuth / SSO | 人类行为者，完全自主和负责 |
| Agents | SPIFFE（新类别） | 代理权限，代表用户行动 |
| Service Accounts | IAM | 应用/容器，完全确定性 |
为什么 Agent 身份重要
有了加密可验证的 Agent 身份，才能授予其特定的最小权限。SalesAgent 获得 CRM 读写权限，HRAgent 被明确拒绝访问。即使单个 Agent 被攻陷，影响范围也被限制。
6.7 策略约束访问
策略（Policy） 是授权（AuthZ）的一种形式，与认证（AuthN）不同。
| 策略应用对象 | 示例 |
|---|---|
| Agent 本身 | 限制可调用的 API 端点 |
| 工具 | 限制可执行的操作类型 |
| 内部 Agent | 控制 Agent 间通信权限 |
| 上下文共享 | 限制可共享的数据范围 |
| 远程 Agent | 通过 A2A 协议控制跨组织调用 |
核心原则：添加所有 API、数据、工具和 Agent 后，约束访问到仅完成工作所需的最小子集。
6.8 Google ADK 安全实践
使用 Google Agent Development Kit (ADK) 保护 Agent：
| 安全层 | 实现方式 |
|---|---|
| 身份定义 | 用户账号（OAuth）、服务账号（运行代码）、Agent 身份（代理权限） |
| 策略约束 | API 治理层 + MCP/A2A 服务治理 |
| 工具级防护 | 在工具内置安全检查，无论 LLM 推理如何都拒绝不安全操作 |
| Callbacks & Plugins | before_tool_callback 检查参数，"Gemini as a Judge" 实时筛查 |
| Model Armor | 托管服务，筛查 Prompt 注入、越狱、PII 泄露、恶意 URL |
ADK Callback 示例：
python
def before_tool_callback(tool_name: str, params: dict, context: AgentContext) -> bool:
"""在工具执行前进行安全检查"""
# 检查高风险操作
if tool_name == "send_email" and params.get("recipient_count", 0) > 100:
return False, "批量邮件需要人工审批"
# 检查参数是否符合策略
if not validate_against_policy(tool_name, params, context.agent_id):
return False, "操作超出 Agent 授权范围"
return True, None6.9 从单 Agent 扩展到企业舰队
单个 Agent 安全成功后，扩展到数百个 Agent 带来新挑战——Agent Sprawl（Agent 蔓延）。
核心问题
| 问题 | 说明 |
|---|---|
| 可见性 | 不知道有多少 Agent 在运行，做什么 |
| 一致性 | 安全标准参差不齐 |
| 审计 | 无法追踪所有 Agent 活动 |
解决方案：中央网关控制平面
想象一个繁忙的大都市，有数千辆自动驾驶汽车。没有交通灯和车牌，就是混乱。
网关方法：建立所有 Agent 活动的强制入口点：
- 用户到 Agent 的 Prompt/UI 交互
- Agent 到工具的调用（MCP）
- Agent 到 Agent 的协作（A2A）
- 直接推理请求
| 网关功能 | 说明 |
|---|---|
| 运行时策略执行 | 认证（"我认识这个 Actor 吗？"）+ 授权（"它有权限吗？"） |
| 集中治理 | 中央注册表作为真相来源——Agent 和工具的"企业应用商店" |
| 单一玻璃窗观测 | 所有交易的通用日志、指标、追踪 |
| 生命周期管理 | 发布前安全审查、版本控制、细粒度策略 |
七、安全评估与监控
7.1 安全评估指标
| 指标 | 说明 | 目标值 | 测量方法 |
|---|---|---|---|
| 攻击成功率 (ASR) | 攻击绕过防护比例 | <5% | 红队测试 |
| 有害输出率 | 产生有害内容比例 | <0.1% | 自动评估 |
| 误拒率 (FRR) | 错误拒绝正常请求 | <1% | 用户反馈 |
| 检测延迟 | 发现问题的时间 | <1s | 监控系统 |
| 修复时间 (MTTR) | 问题修复的时间 | <24h (P0) | 事件追踪 |
| 覆盖率 | 测试覆盖的攻击向量 | >90% | 红队报告 |
7.2 安全监控仪表盘
| 监控维度 | 关键指标 | 告警阈值 |
|---|---|---|
| 安全事件 | 有害输出数量、攻击尝试 | 超过基线 2x |
| 性能影响 | 安全检查延迟 | >500ms |
| 误报率 | 正常请求被拦截 | >2% |
| 覆盖缺口 | 未检测的攻击类型 | 任何新类型 |
7.3 安全审计清单
| 审计项 | 频率 | 责任人 |
|---|---|---|
| 红队测试报告 | 季度 | 安全团队 |
| 自动化漏洞扫描 | 月度 | DevSecOps |
| 安全事件复盘 | 每事件 | 安全团队 |
| 政策合规检查 | 年度 | 合规团队 |
| 第三方审计 | 年度 | 外部审计 |
| 对齐质量评估 | 季度 | AI 团队 |
八、2025-2026 安全趋势
| 趋势 | 说明 | 成熟度 |
|---|---|---|
| 红队自动化 | AI 驱动的自动化红队测试工具 | 成熟 |
| Agentic AI 安全 | 针对自主 Agent 的专门安全体系 | 早期 |
| 多模态安全 | 跨模态攻击检测与防御 | 发展中 |
| 对齐可扩展性 | RLAIF 和混合方法降低对齐成本 | 成熟 |
| 实时防御 | 低延迟的攻击检测和响应 | 成熟 |
| 隐私增强 | 差分隐私、联邦学习集成 | 发展中 |
| 可解释安全 | 安全决策的可解释性 | 早期 |
| 零信任 AI | 持续验证的 AI 访问控制 | 早期 |
九、学习资源
9.1 官方文档
| 资源 | 链接 |
|---|---|
| OpenAI 安全最佳实践 | platform.openai.com/docs/guides/safety |
| Anthropic 安全研究 | anthropic.com/research |
| Microsoft AI 安全 | microsoft.com/ai/responsible-ai |
| NIST AI RMF | nist.gov/ai |
9.2 红队工具
| 工具 | 链接 |
|---|---|
| PyRIT | github.com/Azure/PyRIT |
| Garak | github.com/leondz/garak |
| Promptfoo | github.com/promptfoo/promptfoo |
核心建议
- 安全优先：将安全考量融入 AI 开发全流程
- 持续测试：定期进行红队测试和漏洞扫描
- 纵深防御：组合多层安全措施
- 快速响应：建立完善的安全事件响应机制
- 人类监督：保持对 AI 系统的人类控制
- 持续学习：Jailbreak 技术快速演进，保持更新