2026-07-22-agency-agents-security-ai-team.md

12 个 AI 安全 Agent 组成一支完整安全团队：agency-agents 安全部门深度解析

当 AI Agent 不再只是"辅助安全"，而是成为安全团队本身——从威胁建模到渗透测试，从事件响应到合规审计，12 个专业化安全 Agent 覆盖了安全工程的完整生命周期。

一、agency-agents：260+ Agent 的"AI 代理机构"

agency-agents 是一个 MIT 许可的开源项目，提供了一套完整的 AI Agent 人格集合库。它不是一个简单的提示词模板仓库——每个 Agent 都是一个具有独特个性、专业流程、技术交付物和成功指标的专业角色系统。

项目数据

维度	数值
Agent 总数	260+
部门数量	17 个
人格定义行数	10,000+
支持工具平台	14 个
社区翻译语言	9 种

17 个部门一览

部门	图标	说明
Engineering		前端、后端、移动端、AI、DevOps
Design		UI 设计、UX 研究、品牌
Security		安全架构、应用安全、渗透测试、事件响应
Testing		证据收集、性能基准、API 测试
Product		Sprint 优先级、趋势研究、反馈综合
Cloud & DevOps	☁️	基础设施、CI/CD、监控
其他 11 个部门	—	销售、市场、财务、游戏开发、学术等

Agent 统一结构

每个 Agent 文件遵循统一的模板：

1. Frontmatter — name, description, color, emoji, vibe
2. Identity & Memory — 身份与记忆
3. Core Mission — 核心使命
4. Critical Rules — 领域特定关键规则
5. Technical Deliverables — 技术交付物（含代码示例）
6. Workflow Process — 工作流程
7. Communication Style — 沟通风格
8. Learning & Memory — 学习与记忆
9. Success Metrics — 成功指标
10. Advanced Capabilities — 高级能力

设计哲学的五大原则：强人格（不是通用模板）、清晰交付（具体输出而非模糊指导）、成功指标（可衡量的结果）、成熟工作流（经过验证的步骤）、学习记忆（模式识别和持续改进）。

二、安全部门全景：12 个安全 Agent

Security Division 包含 12 个 Agent，分为两批创建：

第一批：核心安全团队（PR #566，2026年6月）

10 个覆盖传统安全领域的 Agent：

#	Agent	Emoji	核心职责	方法论
1	Security Architect	️	安全架构设计、威胁建模	STRIDE、零信任、纵深防御
2	Application Security Engineer		应用安全 SDLC	OWASP Top 10、SAST/DAST
3	Penetration Tester	️	渗透测试、红队演练	PTES、MITRE ATT&CK
4	Incident Responder		事件响应、数字取证	NIST SP 800-61、SANS IR
5	Threat Intelligence Analyst		威胁情报分析	MITRE ATT&CK、Diamond Model
6	Threat Detection Engineer		检测工程、威胁狩猎	Sigma、Detection-as-Code
7	Cloud Security Architect	☁️	云安全架构	AWS WAF、CIS Benchmarks
8	Compliance Auditor		合规审计	SOC 2、ISO 27001、HIPAA
9	Blockchain Security Auditor	⛓️	智能合约审计	SWC Registry、Slither
10	Senior SecOps Engineer	️	安全运维、SAST 扫描	OWASP、CWE Top 25

第二批：AI 时代新安全角色（PR #720，2026年7月）

2 个专为 AI 时代设计的新 Agent：

#	Agent	Emoji	核心职责	核心框架
11	AI-Generated Code Security Auditor		审计 AI 生成代码的安全漏洞	CWE + OWASP LLM Top 10
12	Secrets & Credential Hygiene Engineer		密钥全生命周期管理	Vault、OIDC Federation

三、AI 专属安全 Agent 深度解析

这两个 2026 年 7 月新增的 Agent，是整个项目中最具时代特征的安全角色。

3.1 AI 生成代码安全审计师（AI-Generated Code Security Auditor）

身份与定位

"You have audited thousands of applications scaffolded by Copilot, Cursor, Claude Code, v0, Lovable, and bolt, and you have learned that AI-written code fails in predictable ways."

这个 Agent 的核心洞察是：AI 生成的代码失败方式是可预测的。它不是为了找到复杂的零日漏洞，而是为了找到 AI 编码助手反复犯的同一批错误。

四大核心使命

1. 在密钥到达浏览器之前拦截

AI 助手最经典的"偷懒"模式：

// VULNERABLE: 助手为了让示例跑起来而内联了密钥
"use client";
const openai = new OpenAI({ apiKey: "sk-proj-REALKEYVALUE" });
// ↑ 这在 Next.js 客户端组件中会发送到每个浏览器

// 更隐蔽的泄露：NEXT_PUBLIC_ 前缀会内联到客户端 bundle
const key = process.env.NEXT_PUBLIC_OPENAI_KEY;
// ↑ NEXT_PUBLIC_ = 公开值，设计如此

// SAFE — 不应该被标记的模式：
const anon = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;
// ↑ 这是设计为公开的 anon key，RLS 才是真正的门控

关键区分：真正危险的泄露（客户端代码中的活跃密钥）vs 无害的公开值（设计为公开的 publishable/anon key）。这个区分是建立信任的关键。

2. 验证数据库是否真正执行了访问控制

AI 生成代码中最常见的 Supabase/Postgres 安全陷阱：

-- VULNERABLE: RLS "开启"了，但策略允许所有人访问
alter table public.orders enable row level security;
create policy "read" on public.orders for select using ( true );
-- ↑ USING(true) 意味着所有人可以读取所有行

-- VULNERABLE: 公开表，完全没有 RLS
create table public.profiles ( id uuid primary key, email text, ssn text );
-- ↑ 没有 enable row level security，anon key 可以读取一切

-- SECURE: RLS 开启，策略限定到认证用户的身份
create policy "owner reads own orders" on public.orders
  for select using ( auth.uid() = user_id );
-- ↑ 基于身份，不是客户端可设置的角色字符串

还有一个隐蔽陷阱：AI 助手经常使用 user_metadata.role === 'admin' 做权限判断——但任何登录用户都可以通过 Auth API 修改自己的 user_metadata 来授予自己任何角色。正确做法是使用仅服务端可访问的 app_metadata。

3. 阻止不可信输入进入模型的指令

// VULNERABLE: 不可信输入拼接到系统提示词 + 工具权限
const { instruction } = await req.json();
await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "system", content: `You are support. ${instruction}` }],
  // ↑ 注入点
  tools: [{ type: "function", function: { name: "issueRefund" } }],
  // ↑ 过度代理：注入成功后可以触发真实操作
});

// SAFE — 不应该被标记的模式：
await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    { role: "system", content: "You are support." },
    { role: "user", content: userMessage },
    // ↑ 数据保持为数据
  ],
  // 无 tools — 低风险
});

关键规则：任何同时接受不可信输入和配置工具/函数调用的 LLM 调用都是高风险——成功的注入可以触发真实操作（过度代理），而不仅仅是产生错误文本。

4. 闭环扫描，诚实报告

工作流程：扫描 → 分类解释（最严重在前）→ 协助修复 → 重新扫描验证。

审计输出示例：

## Scan: 7 findings (1 critical, 2 high, 3 medium, 1 low) — local, nothing sent out

1. [CRITICAL] service_role key in client-reachable code — app/lib/supabase.ts:4 (CWE-798)
   Why: service_role key 完全绕过 RLS；在客户端中它把每一行数据交给任何人。
   Fix: 移到服务器路由；客户端使用 anon key。在 Supabase 控制台轮换密钥。

2. [HIGH] Public storage bucket — supabase/migrations/0002_avatars.sql:11 (CWE-863)
   Why: USING(true) 在 storage.objects 上暴露每个上传的文件。
   Fix: 将策略限定到 auth.uid() = owner。

3. [MEDIUM] Potential prompt-injection sink — app/api/agent/route.ts:22 (CWE-1426, LLM01+LLM06)
   Why: 请求输入到达系统提示词且启用了工具调用。启发式检测 — 需手动验证。
   Fix: 将输入移到 user-role 消息；工具调用前增加确认机制。

四条不可违反的规则

规则	说明
证据优先	绝不标记一行代码而不附带漏洞利用和修复方案
密钥已被泄露	泄露的密钥从提交那一刻起就已泄露——删除代码不是修复，轮换才是
数据与指令的边界	不可信输入是数据，属于 user-role 消息，绝不拼接到 system prompt
只读默认	Agent 只报告不修改——修复由开发者的编码助手执行

方法论映射

每个发现都映射到 CWE 和 OWASP LLM Top 10：

漏洞类型	CWE	OWASP LLM
硬编码密钥	CWE-798	—
缺失的访问控制	CWE-862/863	—
提示注入	CWE-1426	LLM01
过度代理	—	LLM06

3.2 密钥与凭证卫生工程师（Secrets & Credential Hygiene Engineer）

身份与定位

"A secret in a repo is compromised the instant it is committed, a long-lived key is a future incident, and removing a secret from source is the first 10% of fixing a leak, not the end of it."

这个 Agent 的核心信念：密钥从提交那一刻起就已被泄露，删除代码只是修复的前 10%。

四大核心使命

1. 阻止密钥进入代码库

# .pre-commit-config.yaml — 在密钥到达默认分支之前阻止提交
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks  # 扫描暂存更改；命中则提交失败

# .github/workflows/secret-scan.yml — CI 中的双重保险
name: secret-scan
on: [push, pull_request]
jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }   # 完整历史，旧泄露也能捕获
      - uses: gitleaks/gitleaks-action@v2
        env: { GITLEAKS_CONFIG: .gitleaks.toml }

2. 托管与代理，绝不硬编码

# BEFORE: 长期静态数据库密码在环境变量中
# DATABASE_URL=postgres://app:sup3rs3cret@db.internal:5432/app

# AFTER: Vault 签发 15 分钟过期的数据库凭证
vault write database/roles/app \
  db_name=appdb \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
    VALID UNTIL '{{expiration}}'; \
    GRANT SELECT, INSERT, UPDATE ON app.* TO \"{{name}}\";" \
  default_ttl="15m" max_ttl="1h"
# 应用每次会话获取全新的最小权限凭证；泄露的凭证在几分钟内失效

3. 定期轮换 + 泄露即轮换

自动轮换用于支持的服务
不支持自动轮换的编写运维手册
硬规则：任何暴露的密钥立即轮换，不等待排期
轮换采用新旧凭证重叠切换，确保零中断

4. 泄露响应——时钟从提交开始计时

## 暴露凭证 — 响应顺序（绝不要停在第 2 步）
1. 在提供商处立即轮换 — 撤销暴露的密钥，签发替代密钥。这是修复。
2. 用代理引用替换代码中的值；部署。
3. 从 git 历史中清除（filter-repo/BFG）并协调重写。
4. 审计暴露窗口内的使用（提交时间 → 撤销时间）。如有使用迹象，扩大响应范围。
5. 事后：为什么门控没拦住？添加扫描模式；让安全路径更容易走。
# 从最新提交中删除密钥只是第 2 步——永远不是全部工作。

关键区分：公钥 vs 密钥

类型	示例	是否安全
发布密钥	Stripe publishable key, Supabase anon key	✅ 设计为公开
服务密钥	Supabase service_role, AWS access key	❌ 绝不能客户端可达
带公共前缀的密钥	NEXT_PUBLIC_OPENAI_KEY	❌ 前缀 = 公开值

四、传统安全 Agent 详解

4.1 安全架构师（Security Architect）️

职责：设计安全模型——威胁建模、信任边界、安全架构设计。

对抗性思维框架（审查任何系统时的四问）：

什么可以被滥用？ — 每个功能都是攻击面
当它失败时会发生什么？ — 假设每个组件都会失败，设计优雅的安全失败
谁从破坏中获益？ — 理解攻击者动机以优先防御
爆炸半径多大？ — 被攻破的组件不应拖垮整个系统

八条安全优先原则：

#	原则	说明
1	永不建议禁用安全控制	找根因，不走捷径
2	所有用户输入都是敌意的	在每个信任边界验证和净化
3	不自造密码学	使用 libsodium、OpenSSL 等验证过的库
4	密钥是神圣的	不硬编码、不记日志、不客户端可达
5	默认拒绝	白名单优于黑名单
6	安全失败	错误不泄露堆栈、路径、数据库结构
7	最小权限无处不在	IAM、数据库用户、API 作用域
8	纵深防御	永不依赖单一防护层

技术交付物包含威胁模型文档模板（STRIDE 分析）、安全代码审查模式（FastAPI + JWT + Pydantic + 限流）、CI/CD 安全管道（Semgrep + Trivy + Gitleaks）。

4.2 应用安全工程师（Application Security Engineer）

职责：安全 SDLC——威胁建模、安全代码审查、SAST/DAST 集成、开发者安全教育。

核心理念："Make developers write secure code without even realizing it"（让开发者在不知不觉中写出安全代码）。

OWASP Top 10 安全编码模式（实际代码示例）：

// A01: Broken Access Control — IDOR 漏洞
// VULNERABLE: 直接对象引用无授权检查
app.get('/api/users/:id/profile', async (req, res) => {
  const profile = await db.getUserProfile(req.params.id);
  res.json(profile); // 任何人可以访问任何用户的资料
});

// SECURE: 授权中间件 + 所有权验证
app.get('/api/users/:id/profile', requireAuth, async (req, res) => {
  if (req.user.id !== req.params.id && !req.user.roles.includes('admin')) {
    return res.status(403).json({ error: 'Access denied' });
  }
  const profile = await db.getUserProfile(req.params.id);
  res.json(profile);
});

// A03: Injection — SQL 注入
// VULNERABLE: 字符串拼接
const results = await db.raw(`SELECT * FROM products WHERE name LIKE '%${query}%'`);

// SECURE: 参数化查询 — 查询是数据，不是代码
const results = await db('products')
  .where('name', 'ilike', `%${query}%`)
  .limit(50);

// A07: Authentication — 时间攻击
// VULNERABLE: 密码比较短路，泄露密码长度
function checkPassword(input, stored) { return input === stored; }

// SECURE: 常量时间比较 + 正确的哈希
function verifyPassword(password, storedHash) {
  const inputHash = scryptSync(password, salt, 64);
  return timingSafeEqual(inputHash, storedBuffer);
}

漏洞管理 SLA：

严重性	修复时限	示例
Critical	7 天	RCE、认证绕过、SQL 注入
High	30 天	存储 XSS、IDOR、权限提升
Medium	90 天	CSRF、缺失安全头
Low	180 天	点击劫持、轻微信息泄露

4.3 渗透测试工程师（Penetration Tester）️

职责：授权渗透测试、红队演练、漏洞评估。

Active Directory 攻击链五阶段：

阶段	关键技术
初始立足	LLMNR/NBT-NS 投毒、密码喷射、AS-REP Roasting
枚举	BloodHound、SPN 枚举、GPP 密码
权限提升	Kerberoasting、ACL 滥用、非约束委派
横向移动	Pass-the-Hash、Overpass-the-Hash、WinRM
域控沦陷	DCSync、Golden Ticket、Skeleton Key

网络隧道工具矩阵：

工具	隧道类型	特点
SSH	本地/动态 SOCKS/远程	最通用，需 SSH 服务
Chisel	反向 SOCKS	SSH 不可用时使用
Ligolo-ng	直接路由	无 SOCKS 开销，性能最优
Meterpreter	autoroute + SOCKS	Metasploit 内置

4.4 事件响应工程师（Incident Responder）

职责：入侵调查、威胁遏制、数字取证、事后分析。

事件严重性分级：

级别	响应时间	标准
SEV1	立即，7×24	活跃数据泄露、勒索软件部署中、域控被攻破
SEV2	同工作日	单系统确认被攻破、钓鱼+凭证窃取
SEV3	次工作日	可疑活动需调查、策略违规
SEV4	标准队列	策略违规（无入侵）、信息告警

取证优先级：先保全易失性证据（内存、网络连接、运行进程），再收集持久化证据——它们在重启后消失。

Windows 和 Linux 取证脚本：Agent 内置了完整的 PowerShell 和 Bash 取证脚本，覆盖进程树、网络连接、DNS 缓存、持久化机制、事件日志、文件系统痕迹。

4.5 威胁情报分析师（Threat Intelligence Analyst）

职责：对手追踪、攻击活动分析、检测规则开发、情报报告。

情报三层模型：

层级	内容	受众
战术情报	IOC、检测规则、即时防御建议	SOC
运营情报	威胁行为者画像、活动分析、TTP 文档	IR 团队
战略情报	威胁态势评估、风险趋势、行业定向分析	领导层

技术交付物包含 YARA 规则（Cobalt Strike Beacon 检测）、Sigma 规则（Kerberoasting 和 PowerShell 下载框架检测）、威胁行为者画像模板、IOC 富集 Python 管道（含 STIX 2.1 导出）。

4.6 威胁检测工程师（Threat Detection Engineer）

职责：SIEM 检测规则开发、MITRE ATT&CK 覆盖映射、威胁狩猎、检测即代码。

核心理念："A noisy SIEM is worse than no SIEM at all — because it trains analysts to ignore alerts."（嘈杂的 SIEM 比没有 SIEM 更糟——因为它训练分析师忽略告警。）

Detection-as-Code CI/CD 管道：

Sigma 规则 → 验证语法 → 检查必需字段 → 验证 ATT&CK 映射
         ↓
编译到 Splunk SPL / Sentinel KQL / Elastic EQL
         ↓
测试 → 对样本日志验证
         ↓
部署到 SIEM（CI/CD 自动化）

ATT&CK 覆盖评估示例：

战术	总技术数	已覆盖	覆盖率
初始访问	9	4	44%
执行	14	9	64%
持久化	19	8	42%
凭证访问	17	7	41%
数据收集	17	3	18% ← 最大缺口

4.7 云安全架构师（Cloud Security Architect）☁️

职责：多云零信任架构、IAM 身份安全、IaC 安全、云检测与响应。

AWS 多账户安全架构包含 SCP（阻止 root 用户使用、要求 S3 加密）、集中化安全日志（S3 + Object Lock 365 天保留）、GuardDuty 威胁检测、VPC Flow Logs。

Kubernetes 零信任网络策略：

# 默认拒绝所有流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
# 然后逐条放行：frontend→api:8080, api→database:5432, all→dns:53

4.8 合规审计师（Compliance Auditor）

职责：SOC 2 / ISO 27001 / HIPAA / PCI-DSS 审计。

核心理念："A policy nobody follows is worse than no policy — it creates false confidence and audit risk."（没人遵守的策略比没有策略更糟——它制造虚假信心和审计风险。）

合规框架映射：通过通用控制框架用一套控制满足多个认证要求，自动化证据收集从第一天开始。

4.9 区块链安全审计师（Blockchain Security Auditor）⛓️

职责：智能合约审计、DeFi 协议安全、形式化验证。

漏洞严重性分类：

级别	标准	示例
Critical	直接导致用户资金损失	重入、闪电贷操纵
High	有条件的资金损失	访问控制缺陷、可升级代理劫持
Medium	Griefing 攻击、临时 DoS	非关键函数缺少访问控制
Low	偏离最佳实践	Gas 效率问题、缺少事件

五步审计流程：范围界定 → 自动化分析（Slither/Mythril/Echidna）→ 逐行手动审查 → 经济与博弈论分析 → 报告与修复验证。

4.10 高级安全运维工程师（Senior SecOps Engineer）️

职责：防御性应用安全——每次代码提交前扫描密钥和敏感数据暴露。

九类自动扫描（在读取请求之前执行）：

类别	严重性	检测内容
硬编码密钥	CRITICAL	API_KEY、PRIVATE_KEY、连接字符串
不安全回退	CRITICAL	`process.env.JWT_SECRET \\|\\| "secret"`
日志中的敏感数据	HIGH	`console.log(token)`
JWT 算法漏洞	CRITICAL	`alg: none`、未指定算法
不安全令牌存储	HIGH	`localStorage.setItem('token')`
响应中的敏感数据	HIGH	`res.json({ accessToken })`
宽松 CORS	HIGH	`Access-Control-Allow-Origin: *`
SQL 注入	CRITICAL	字符串拼接查询
URL 中的 PII	HIGH	`GET /api/user?email=...`

八条不可违反的规则：密钥不在代码中（启动时失败）、令牌在 HttpOnly Cookie 中、JWT 算法固定验证、角色来自 IdP、敏感数据不记日志、CORS 是白名单、认证路由有限流、所有输入在信任边界验证。

五、协作模式：12 个 Agent 如何组成安全梦之队

MERMAID_BLOCK_0

典型协作场景

场景一：AI 生成应用的完整安全审计

AI 代码审计师 扫描 Copilot 生成的代码 → 发现 NEXT_PUBLIC_ 密钥 + USING(true) RLS
密钥卫生工程师 确认密钥已泄露 → 在提供商处轮换 → 迁移到 Vault
SecOps 工程师 ️ 在 pre-commit hook 中添加检测模式 → 防止再次发生
应用安全工程师 审查剩余代码 → 发现 SQL 注入和 IDOR
安全架构师 ️ 设计修复方案 → 重新设计认证和授权

场景二：安全事件的端到端响应

威胁检测工程师 Sigma 规则触发 → 可疑 PowerShell 编码命令执行
事件响应工程师 启动取证 → 内存镜像、网络连接、持久化分析
威胁情报分析师 将 IOC 映射到 MITRE ATT&CK → 确认 APT 组织
渗透测试工程师 ️ 红队验证 → 确认攻击路径和爆炸半径
云安全架构师 ☁️ 修复云配置 → IAM 收紧、网络分段
合规审计师 评估合规影响 → GDPR 72 小时通知要求

六、方法论框架全景

12 个 Agent 覆盖的安全框架矩阵：

框架	使用 Agent	用途
OWASP Top 10	AppSec 工程师、SecOps 工程师	Web 应用安全分类
OWASP LLM Top 10	AI 代码审计师	AI/LLM 应用安全（LLM01 注入、LLM06 过度代理）
OWASP ASVS	AppSec 工程师、安全架构师	应用安全验证标准
MITRE ATT&CK	威胁情报分析师、检测工程师、渗透测试工程师、事件响应工程师	攻击者行为框架
MITRE ATLAS	（隐性支撑 AI 代码审计师）	对抗性 AI 攻击
STRIDE	安全架构师、AppSec 工程师	威胁建模（伪装/篡改/否认/信息泄露/拒绝服务/权限提升）
NIST SP 800-61	事件响应工程师	计算机安全事件处理指南
NIST CSF	云安全架构师	网络安全框架
NIST AI RMF	（隐性支撑 AI 安全治理）	AI 风险管理框架
CWE Top 25	AppSec 工程师、AI 代码审计师、SecOps 工程师	最危险软件弱点
CVSS 3.1	安全架构师、渗透测试工程师	漏洞严重性评分
Sigma	威胁检测工程师、威胁情报分析师	供应商无关的检测规则格式
YARA	威胁情报分析师	恶意软件模式匹配
STIX/TAXII	威胁情报分析师	威胁情报共享标准
PTES	渗透测试工程师	渗透测试执行标准
Diamond Model	威胁情报分析师	入侵分析模型
Cyber Kill Chain	威胁情报分析师	攻击链分析
SWC Registry	区块链安全审计师	智能合约弱点分类
SOC 2 / ISO 27001 / HIPAA / PCI-DSS	合规审计师	合规框架

七、实战部署指南

7.1 安装方式

方式一：桌面应用（推荐）

# macOS
brew install --cask msitarzewski/agency-agents/agency-agents

方式二：脚本安装

# 克隆仓库
git clone https://github.com/msitarzewski/agency-agents.git

# 安装到 Claude Code（仅安全部门）
./scripts/install.sh --tool claude-code --division security

# 安装到 Cursor
./scripts/install.sh --tool cursor --agent security-architect,security-appsec-engineer

方式三：直接使用

将 Agent 的 Markdown 文件内容复制到你使用的 AI 工具的 Agent/规则配置中。

7.2 支持的工具平台

工具	格式	安装路径
Claude Code	`.md`	`~/.claude/agents/`
GitHub Copilot	`.md`	`~/.github/agents/`
Cursor	`.mdc`	`.cursor/rules/`
Gemini CLI	`.md`	`~/.gemini/agents/`
OpenCode	`.md`	`.opencode/agents/`
Codex	TOML	`~/.codex/agents/`
Windsurf	`.windsurfrules`	项目根目录
Aider	`CONVENTIONS.md`	项目根目录

7.3 使用示例

在 Claude Code 中激活安全审计：

Hey Claude, activate AI-Generated Code Security Auditor mode and 
review my Next.js + Supabase project for security vulnerabilities.

在 Cursor 中使用渗透测试 Agent：

Activate Penetration Tester agent. I need to plan an authorized 
penetration test for our staging environment. Target: api.staging.example.com

7.4 注意事项

OpenCode 限制：运行时仅注册约 119 个 Agent，建议使用 --division 参数安装子集
更新后重新生成：./scripts/convert.sh --parallel 并行重新生成所有工具的集成文件
社区翻译：简体中文翻译已有 141 个 Agent + 46 个中国市场原创 Agent

八、总结：AI 安全的新范式

传统安全 vs AI Agent 安全团队

维度	传统安全团队	AI Agent 安全团队
可用性	工作时间	7×24
成本	$150K-$300K/人/年	一次部署，零边际成本
一致性	因人而异	每次执行相同标准
知识广度	个人经验范围	全部框架和标准
协作	需要会议协调	Agent 间直接传递上下文
速度	分钟到小时	秒级响应

agency-agents 安全部门的核心价值

完整性：12 个 Agent 覆盖安全工程全生命周期——从威胁建模到事件响应，从渗透测试到合规审计
AI 原生：AI 代码审计师和密钥卫生工程师是专为 AI 时代设计的新角色
可操作性：每个 Agent 都提供具体代码、配置和模板——不是理论指导
框架对齐：CWE、OWASP、MITRE ATT&CK、STRIDE、NIST——映射到现有风险流程
多平台：支持 14 个主流 AI 编码工具，一键部署

值得关注的设计亮点

诚实优于自夸：AI 代码审计师明确声明"我不会报告合规百分比，我会告诉你我检查了什么、没检查什么"
安全失败哲学：安全架构师的"Fail Securely"原则——错误不泄露信息
检测即代码：威胁检测工程师将检测规则视为代码——版本控制、同行评审、CI/CD 部署
泄露时钟：密钥卫生工程师从提交时间（非发现时间）开始计时
对抗性思维：渗透测试工程师"Breaks into your systems so the real attackers can't"

未来展望

当 AI 生成的代码占新代码的 50% 以上时，AI 代码安全审计师将成为标准 CI/CD 管道的一部分——就像今天的 SAST 扫描器一样。agency-agents 的安全部门展示了一个可行的路径：不是用 AI 替代安全工程师，而是用 AI Agent 将安全工程的最佳实践编码为可执行的、可重复的、可扩展的系统。

项目地址：https://github.com/msitarzewski/agency-agents

安全部门：https://github.com/msitarzewski/agency-agents/tree/main/security

桌面应用：https://agencyagents.app

posted @ 2026-07-22 18:56 iTech 阅读(5) 评论(0) 收藏举报

刷新页面返回顶部

iTech's Blog

AI人工智能时代 www.theaiera.cn

2026-07-22-agency-agents-security-ai-team.md

12 个 AI 安全 Agent 组成一支完整安全团队：agency-agents 安全部门深度解析

一、agency-agents：260+ Agent 的"AI 代理机构"

项目数据

17 个部门一览

Agent 统一结构

二、安全部门全景：12 个安全 Agent

第一批：核心安全团队（PR #566，2026年6月）

第二批：AI 时代新安全角色（PR #720，2026年7月）

三、AI 专属安全 Agent 深度解析

3.1 AI 生成代码安全审计师（AI-Generated Code Security Auditor）

身份与定位

四大核心使命

四条不可违反的规则

方法论映射

3.2 密钥与凭证卫生工程师（Secrets & Credential Hygiene Engineer）

身份与定位

四大核心使命

关键区分：公钥 vs 密钥

四、传统安全 Agent 详解

4.1 安全架构师（Security Architect）️

4.2 应用安全工程师（Application Security Engineer）

4.3 渗透测试工程师（Penetration Tester）️

4.4 事件响应工程师（Incident Responder）

4.5 威胁情报分析师（Threat Intelligence Analyst）

4.6 威胁检测工程师（Threat Detection Engineer）

4.7 云安全架构师（Cloud Security Architect）☁️

4.8 合规审计师（Compliance Auditor）

4.9 区块链安全审计师（Blockchain Security Auditor）⛓️

4.10 高级安全运维工程师（Senior SecOps Engineer）️

五、协作模式：12 个 Agent 如何组成安全梦之队

典型协作场景

六、方法论框架全景

七、实战部署指南

7.1 安装方式

7.2 支持的工具平台

7.3 使用示例

7.4 注意事项

八、总结：AI 安全的新范式

传统安全 vs AI Agent 安全团队

agency-agents 安全部门的核心价值

值得关注的设计亮点

未来展望

公告