mitrity-io/iag-demo-multi-agent

# MITRITY 多 Agent 治理演示 真实的多 Agent 治理场景：**orchestrator** Claude agent 将工作委托给专门的 **worker** agent（`data-worker`，`notification-worker`）。每个 Agent 在各自的容器中运行，拥有独立的 MITRITY Gateway 和 MITRITY agent 身份。委托链、威胁情报匹配以及每个 Agent 的权限边界均源自真实活动 —— 没有种子数据，也没有合成的 UUID。 关联演示：[`iag-demo-mcp-gateway`](https://github.com/mitrity-io/iag-demo-mcp-gateway) 和 [`iag-demo-mcp-sidecar`](https://github.com/mitrity-io/iag-demo-mcp-sidecar) 演示了单 Agent 治理（策略、注入检测、DLP、保留/批准）。 ## 前置条件 - **Pro 或 Enterprise MITRITY 订阅。** Starter 不包含 Threat Intelligence 或 Delegation Chains；此演示可以启动，但相应的仪表板页面将保持为空。 - Docker + docker-compose - 一个 [Anthropic API key](https://console.anthropic.com) - 一个配置了**三个 agent** 的 MITRITY 租户：orchestrator 和两个 worker。具体步骤请参阅 [设置](#setup) 部分。 ## 快速开始 ``` git clone https://github.com/mitrity-io/iag-demo-multi-agent cd iag-demo-multi-agent cp .env.example .env # 填写 6 个 MITRITY_AGENT_* 值 + ANTHROPIC_API_KEY + MITRITY_CONTROL_PLANE_URL docker compose up --build ``` orchestrator runner 会在约 5 分钟内循环执行六个场景。请关注 [mitrity.com/app](https://mitrity.com/app) 上的仪表板 —— 特别是 `/delegation-chains`、`/threat-intel` 和 `/audit`。 ## 设置 ### 1. 在仪表板中配置三个 agent 在 `mitrity.com/app/agents` 中，点击三次 **+ New Agent**： | Agent 名称 | 任务范围 | 需启用的计划限制工具 | |---|---|---| | `orchestrator` | `coordinate customer-order workflow` | (只读：filesystem，无 DB 写入) | | `data-worker` | `query and modify customer order data` | `query_database`, `create_order`, `fetch_orders` | | `notification-worker` | `notify customers of order status changes` | `send_notification`, `email_customer` | 将每个 agent 的 **Agent ID** 和 **Agent Key** 复制到 `.env` 中（参见 `.env.example`）。 ### 2. 确认已启用 Threat Intelligence 如果您的租户创建于 2026 年 5 月 25 日之后，则默认启用 `mitrity_curated` feed。在 `/app/threat-intel/settings` 进行验证 —— **Subscribed feeds** 列表中应包含 `mitrity_curated`。如果没有，请点击该 feed 上的 **Subscribe**。 ### 3. 运行演示 ``` docker compose up --build ``` 首次运行可能需要约 3 分钟来进行多架构镜像构建。后续运行将重用缓存。 ## 演示内容 六个场景按顺序循环。每个场景运行约 30 秒，由 Claude 驱动在多个 agent 间进行真实的工具使用。 | | 场景 | 您将在仪表板中看到的内容 | |---|---|---| | S1 | 干净的订单查询：orchestrator → data-worker | `/delegation-chains` 上的 2 跳链，决策为 `allowed` | | S2 | 创建订单：orchestrator 委托了其自身无法执行的写入操作 | 链被阻塞，原因为 `privilege_escalation`；升级差异卡片将渲染 orchestrator 所缺失的 (tool, op) | | S3 | 端到端 pipeline：orchestrator → data-worker → notification-worker | 干净的 3 跳链 | | S4 | 深层链：通过 worker 级联超出了 `max_chain_depth` | 链在第 N+1 跳被阻塞，原因为 `depth_exceeded` | | S5 | 威胁情报匹配（worker 读取 `/etc/passwd`） | 在 `/threat-intel` 上匹配，在 `/audit` 上被阻塞并带有 **Threat Intel** 徽章 | | S6 | 回环：worker 尝试委托回 orchestrator | 链被阻塞，原因为 `circular_delegation` | ## 架构 ``` ┌─ orchestrator (container) ─┐ ┌─ data-worker (container) ──┐ ┌─ notification-worker (container) ──┐ │ Python runner (Claude SDK) │ │ Python HTTP /task server │ │ Python HTTP /task server │ │ ├─ delegate_to tool │ │ ├─ query_database │ │ ├─ send_notification │ │ └─ read-only fs tools │ │ ├─ fetch_orders │ │ └─ email_customer │ │ mitrity-gateway │ │ ├─ create_order │ │ mitrity-gateway │ │ agent: orchestrator │ │ └─ delegate_to │ │ agent: notification-worker │ └────────────┬───────────────┘ │ mitrity-gateway │ └─────────────┬──────────────────────┘ │ HTTP POST /task │ agent: data-worker │ │ ├────────────────────┴────────────┬───────────────┘ │ │ │ HTTP POST /task │ │ ├──────────────────────────────────┘ ▼ ▼ (chain_id, delegator_agent_id, task as JSON body) All three gateways heartbeat independently to MITRITY_CONTROL_PLANE_URL. Each agent's actions are evaluated by ITS gateway against ITS profile. The delegation chain accumulates real hops across the three event streams. ``` ## 环境变量 | 变量 | 描述 | |---|---| | `ANTHROPIC_API_KEY` | 用于 Claude API 调用（在所有 3 个容器间共享） | | `MITRITY_CONTROL_PLANE_URL` | 例如 `https://api.mitrity.com` | | `MITRITY_AGENT_ID_ORCHESTRATOR` / `_KEY_ORCHESTRATOR` | Orchestrator agent 身份 | | `MITRITY_AGENT_ID_DATA` / `_KEY_DATA` | Data worker agent 身份 | | `MITRITY_AGENT_ID_NOTIFY` / `_KEY_NOTIFY` | Notification worker agent 身份 | 请参阅 [`.env.example`](.env.example)。 ## 凭证 broker（按 agent 划分，热轮换） 所有三个 gateway 配置（`config/orchestrator.yaml.tmpl`、`config/data-worker.yaml.tmpl`、`config/notification-worker.yaml.tmpl`）均附带 `credentials.injection_enabled: true`。S1–S6 并没有直接测试它 —— 这些场景侧重于委托链 + 威胁情报 —— 但该功能完全可以用于临时测试。 尝试方法：在仪表板（`mitrity.com/app/credentials`）中配置一个凭证，将其授予这三个 agent 中的一个（例如 `data-worker`），然后驱动一个参数包含 `${credential:}` 的工具调用。wrapper 会在上游工具运行之前通过 broker 替换该占位符。在仪表板中进行轮换会在 30 秒内传播到正在运行的容器，无需任何重启。 如需引导式的端到端演示（配置、替换、场景中途轮换、fail-closed），请参阅以下任一文档中的第 6 阶段： - [iag-demo-mcp-sidecar](https://github.com/mitrity-io/iag-demo-mcp-sidecar) — 单 agent + 透明代理形式 - [iag-demo-mcp-gateway](https://github.com/mitrity-io/iag-demo-mcp-gateway) — 单 agent + 聚合 gateway 形式 多 Agent 设置增加了一个值得注意的变化：每个 agent 都有自己的 MITRITY 身份，因此凭证授予和轮换都是按 agent 划分作用域的。`data-worker` 可以持有 DB 凭证，而 `notification-worker` 独立持有 SMTP / Slack / SendGrid 密钥；轮换其中一个不会使另一个的缓存失效。 ## 故障排除 **运行后 `/delegation-chains` 页面为空。** 检查 orchestrator 日志（`docker compose logs orchestrator`）中的 `chain_id` 行。如果发出了链但仪表板没有显示，请验证这三个 agent 是否都注册在**同一个租户**下（注册到错误租户的 agent 意味着该 worker 的事件会落入另一个租户的审计日志中）。 **`/threat-intel` 页面未显示匹配项。** 确认 `/app/threat-intel/settings` 中的 `tenant_threat_settings.subscribed_feeds` 包含 `mitrity_curated`。 ## 许可证 版权所有 © 2026 MITRITY AB。请参阅 [LICENSE](LICENSE)。

标签：AI安全, AI智能体, Chat Copilot, Docker, 多智能体协同, 安全防御评估, 版权保护, 请求拦截, 身份与访问控制, 逆向工具