Add files via upload

README.md

@@ -127,6 +127,7 @@ If CyberStrikeAI helps you, you can support the project via **WeChat Pay** or **
 - 🔗 Attack-chain intelligence with graph views, risk scoring, project facts, and step-by-step replay
 - 🧑‍⚖️ Human-in-the-loop governance with approval modes, allowlists, audit-agent review, and traceable decisions
 - 🔒 Password-protected web UI, audit logs, SQLite persistence, and operational evidence retention
+- 🔐 **Platform RBAC** with multi-user accounts, system/custom roles, per-permission scopes (`all` / `assigned` / `own`), ownership, and explicit assignments enforced across APIs, Agents, MCP, background jobs, and chatbots; see the [RBAC administration guide](docs/en-US/rbac.md)
 - 📚 Knowledge base (RAG): **Eino MultiQuery** query rewrite + multi-path vector retrieval + **HTTP rerank** (DashScope `gte-rerank` / Cohere-compatible) + post-processing (dedupe, budget); **Eino Compose** indexing pipeline
 - 📁 Conversation grouping with pinning, rename, and batch management
 - 📂 **Project management**: shared facts (blackboard) across sessions, `upsert_project_fact` + `links` to chain paths; attack-chain and project fact graph views
@@ -649,10 +650,11 @@ enabled: true
 - [API recipes](docs/en-US/api-recipes.md): examples for login, Agent, streaming, multi-agent, uploads, vulnerabilities, KB, and audit export.
 - [Configuration reference](docs/en-US/configuration.md): main `config.yaml` sections, recommended values, and update guidance.
 - [Security model](docs/en-US/security-model.md): authentication, tool execution, HITL, audit, C2/WebShell, and data safety boundaries.
+- [RBAC administration](docs/en-US/rbac.md): platform users, system/custom roles, permission catalog, per-permission scopes, resource assignments, Agent/MCP/robot boundaries, and API examples.
 - [API reference](docs/en-US/api-reference.md): OpenAPI, authentication, Agent, projects, knowledge base, C2, WebShell, and other API entry points.
 - [Multi-agent mode (Eino)](docs/en-US/MULTI_AGENT_EINO.md): **Deep**, **Plan-Execute**, **Supervisor**, `agents/*.md`, `eino_skills` / `eino_middleware`, APIs, and chat/stream behavior.
 - [Graph orchestration guide](docs/en-US/workflow-graph.md): visual workflow design, node configuration, `previous` / `outputs` variable passing, and role binding.
-- [Robot / Chatbot guide](docs/en-US/robot.md): Setup, commands, and troubleshooting for WeChat, WeCom, DingTalk, Lark, Telegram, Slack, Discord, and QQ Bot.
+- [Robot / Chatbot guide](docs/en-US/robot.md): Platform setup, RBAC user-binding/service-account modes, sender allowlists, commands, verification, and troubleshooting.
 - [HITL best practices](docs/en-US/hitl-best-practices.md): reviewer modes, allowlists, Audit Agent prompts, and separate small-model configuration.
 
 ## Project Layout

README_CN.md

@@ -126,6 +126,7 @@ CyberStrikeAI 基于 Go 构建，为 AI 原生安全运营提供完整底座：1
 - 🔗 攻击链智能分析，支持图谱视图、风险打分、项目事实沉淀与步骤回放
 - 🧑‍⚖️ 人机协同治理，支持审批模式、免审批白名单、审计 Agent 复核与可追溯决策
 - 🔒 Web 登录保护、审计日志、SQLite 持久化与行动证据留存
+- 🔐 **平台 RBAC**：支持多用户、系统/自定义角色、逐权限 Scope（`all` / `assigned` / `own`）、资源归属与显式授权，并统一约束 API、Agent、MCP、后台任务和机器人；详见 [RBAC 权限管理](docs/zh-CN/rbac.md)
 - 📚 知识库（RAG）：**Eino MultiQuery** 查询改写 + 多路向量检索 + **HTTP 精排**（DashScope `gte-rerank` / Cohere 兼容）+ 后处理（去重、预算）；索引侧为 **Eino Compose** 流水线
 - 📁 对话分组管理：支持分组创建、置顶、重命名、删除等操作
 - 📂 **项目管理**：共享事实（黑板）跨会话沉淀认知，`upsert_project_fact` + `links` 串联攻击路径；聊天攻击链与项目事实图可视化
@@ -647,10 +648,11 @@ enabled: true
 - [API Recipes](docs/zh-CN/api-recipes.md)：登录、Agent、流式、多代理、上传、漏洞、知识库和审计导出调用示例。
 - [配置参考](docs/zh-CN/configuration.md)：`config.yaml` 各配置段、推荐值和修改建议。
 - [安全模型](docs/zh-CN/security-model.md)：认证、工具执行、HITL、审计、C2/WebShell 和数据安全边界。
+- [RBAC 权限管理](docs/zh-CN/rbac.md)：平台用户、系统/自定义角色、权限目录、逐权限 Scope、资源授权、Agent/MCP/机器人边界与 API 示例。
 - [API 参考](docs/zh-CN/api-reference.md)：OpenAPI、认证、Agent、项目、知识库、C2、WebShell 等接口入口。
 - [多代理模式（Eino）](docs/zh-CN/MULTI_AGENT_EINO.md)：**Deep**、**Plan-Execute**、**Supervisor**、`agents/*.md`、`eino_skills` / `eino_middleware`、接口与流式说明。
 - [图编排使用说明](docs/zh-CN/workflow-graph.md)：可视化流程搭建、节点配置、`previous` / `outputs` 变量传参与角色绑定。
-- [机器人使用说明](docs/zh-CN/robot.md)：个人微信、企业微信、钉钉、飞书、Telegram、Slack、Discord、QQ 机器人的配置、命令与排查。
+- [机器人使用说明](docs/zh-CN/robot.md)：各平台接入、RBAC 逐用户绑定/服务账号模式、发送者白名单、命令、验证与排查。
 - [人机协同最佳实践](docs/zh-CN/hitl-best-practices.md)：审批方模式、白名单、审计 Agent 提示词策略与独立小模型配置。
 
 ## 项目结构

docs/README.md

@@ -15,6 +15,7 @@ Documentation is split by language:
 - [贡献规范](zh-CN/contributing-guide.md)
 - [配置参考](zh-CN/configuration.md)
 - [安全模型](zh-CN/security-model.md)
+- [RBAC 权限管理](zh-CN/rbac.md)
 - [架构说明](zh-CN/architecture.md)
 - [API 参考](zh-CN/api-reference.md)
 - [排错指南](zh-CN/troubleshooting.md)
@@ -45,6 +46,7 @@ Documentation is split by language:
 - [Contributing Guide](en-US/contributing-guide.md)
 - [Configuration Reference](en-US/configuration.md)
 - [Security Model](en-US/security-model.md)
+- [RBAC Administration](en-US/rbac.md)
 - [Architecture](en-US/architecture.md)
 - [API Reference](en-US/api-reference.md)
 - [Troubleshooting](en-US/troubleshooting.md)

docs/en-US/README.md

@@ -8,6 +8,7 @@
 - [Contributing Guide](contributing-guide.md): checklists for APIs, config, tools, frontend, DB, high-risk features, and docs.
 - [Configuration Reference](configuration.md): `config.yaml` fields, hot-apply boundaries, recommended values, and source anchors.
 - [Security Model](security-model.md): trust boundaries, HITL, tool execution, C2/WebShell, and data safety.
+- [RBAC Administration](rbac.md): platform users, system/custom roles, permission catalog, per-permission scopes, resource assignments, Agent/MCP/robot boundaries, and API examples.
 - [Architecture](architecture.md): request flow, module relationships, complexity hotspots, and design trade-offs.
 - [API Reference](api-reference.md): authentication, OpenAPI, SSE, stability tiers, and common endpoints.
 - [Troubleshooting](troubleshooting.md): diagnostic order, minimal commands, common misdiagnoses, and issue template.

docs/en-US/rbac.md

@@ -0,0 +1,374 @@
+# CyberStrikeAI RBAC Administration Guide
+
+[中文](../zh-CN/rbac.md)
+
+CyberStrikeAI can execute Agents, MCP tools, WebShell operations, C2 actions, and batch jobs. RBAC therefore applies beyond navigation visibility: it is enforced across HTTP APIs, resource queries, Agent contexts, built-in and external MCP tools, background jobs, and chatbot execution.
+
+---
+
+## 1. Two different kinds of roles
+
+| Concept | Management location | Purpose |
+|---------|---------------------|---------|
+| **Platform role (RBAC Role)** | **Platform permissions** | Controls which features and resources a user may access |
+| **AI testing role (Agent Role)** | **Roles** / `roles/*.yaml` | Controls Agent prompts, methodology, and candidate tools |
+
+An AI testing role is not an authorization boundary. Selecting a penetration-testing role does not grant platform permissions, and granting RBAC permissions does not change the Agent prompt.
+
+---
+
+## 2. Authorization model
+
+An operation is allowed only when all relevant checks pass:
+
+```text
+enabled account
+  + required permission for the route/tool
+  + scope attached to that permission
+  + resource owner / explicit assignment / parent inheritance
+  + additional rules for process-global operations
+```
+
+Request flow:
+
+1. Login issues a Bearer token whose session contains user, roles, permissions, and per-permission scopes.
+2. HTTP middleware maps the route to a permission, for example `GET /api/projects` → `project:read`.
+3. Resource-ID requests also check ownership, explicit assignments, or supported parent inheritance.
+4. Agent execution receives an immutable Principal through `context.Context`.
+5. Built-in MCP tools authorize both the tool and resource IDs in tool arguments. External MCP has separate restrictions.
+6. Denials are written to RBAC/audit logs.
+
+Frontend button hiding is only a usability feature. The server is the security boundary.
+
+---
+
+## 3. Built-in platform roles
+
+| Role | Scope | Default capability |
+|------|-------|--------------------|
+| **Administrator `admin`** | `all` | Every known permission, including RBAC, configuration, terminal, audit deletion, and global definition management |
+| **Operator `operator`** | `assigned` | Normal read/write/execute work; excludes RBAC, core configuration, terminal, audit management, external MCP execution, and several global definition writes |
+| **Auditor `auditor`** | `all` | Read permissions across modules plus `audit:read`; no writes |
+| **Viewer `viewer`** | `assigned` | Read-only access within authorized resources |
+
+System roles cannot be edited or deleted. Their grants are rebuilt from the current permission catalog during upgrade, preventing stale grants from older versions. Create custom roles for different job functions.
+
+An account without a role can still authenticate but has almost no business capability; do not treat “no role” as a complete job profile.
+
+---
+
+## 4. Permission catalog
+
+Permissions use `module:action`. Common actions are `read`, `write`, `delete`, and `execute`. The authoritative catalog for the running build is available in Platform permissions or `GET /api/rbac/metadata`.
+
+| Module | Permissions |
+|--------|-------------|
+| Account | `auth:self` |
+| Dashboard | `dashboard:read` |
+| Chat | `chat:read`, `chat:write`, `chat:delete` |
+| Agent | `agent:execute`, `agent:local-execute` |
+| HITL | `hitl:read`, `hitl:write` |
+| Tasks | `tasks:read`, `tasks:write`, `tasks:delete` |
+| Projects | `project:read`, `project:write`, `project:delete` |
+| Vulnerabilities | `vulnerability:read`, `vulnerability:write`, `vulnerability:delete` |
+| WebShell | `webshell:read`, `webshell:write`, `webshell:delete` |
+| C2 | `c2:read`, `c2:write`, `c2:delete` |
+| MCP | `mcp:read`, `mcp:execute`, `mcp:write`, `mcp:external:execute` |
+| Knowledge | `knowledge:read`, `knowledge:write`, `knowledge:delete` |
+| Skills | `skills:read`, `skills:write`, `skills:delete` |
+| Markdown Agents | `agents:read`, `agents:write`, `agents:delete` |
+| AI testing roles | `roles:read`, `roles:write`, `roles:delete` |
+| Workflows | `workflow:read`, `workflow:execute`, `workflow:write`, `workflow:delete` |
+| Configuration | `config:read`, `config:write` |
+| Terminal | `terminal:execute` |
+| Audit | `audit:read`, `audit:delete` |
+| RBAC | `rbac:read`, `rbac:write` |
+| Notifications | `notification:read`, `notification:write` |
+| Robots | `robot:read`, `robot:write` |
+| Files | `files:read`, `files:write`, `files:delete` |
+| Attack chain | `attackchain:read`, `attackchain:write` |
+| FOFA | `fofa:execute` |
+| OpenAPI | `openapi:read` |
+| Chat groups | `group:read`, `group:write`, `group:delete` |
+| Monitor | `monitor:read`, `monitor:write`, `monitor:delete` |
+
+Important distinctions:
+
+- `agent:execute` runs Agents but does not grant local filesystem, shell, or arbitrary configured command access.
+- `agent:local-execute` is the local execution fallback and should be limited to trusted operators.
+- `mcp:execute` protects the authenticated MCP HTTP entry point.
+- `mcp:external:execute` allows Agent calls to external MCP tools and currently also requires `all` scope.
+- `mcp:write` manages external MCP configuration; it is separate from external tool execution.
+- `robot:write` manages robot configuration and the test endpoint. Chatbot conversations use the bound user or configured service account's business permissions.
+
+---
+
+## 5. Resource scopes
+
+Each role has one scope:
+
+| Scope | Meaning | Typical use |
+|-------|---------|-------------|
+| `all` | All resources covered by the permission | Administrator, global auditor |
+| `assigned` | Explicitly assigned resources and supported parent-resource inheritance | Project member, assigned asset operator |
+| `own` | Primarily resources created by/owned by the user; some resource types also support explicit assignment or parent inheritance | Personal workspace, isolated robot identity |
+
+Users may have multiple roles. Permissions are unioned, while scopes are merged **for the same permission only**:
+
+```text
+all > assigned > own
+```
+
+Example:
+
+```text
+Global audit role:  project:read  + all
+Personal editor:    project:write + own
+
+Effective:
+project:read  → all
+project:write → own
+```
+
+A global read role does not widen an unrelated write permission. Authorization code must use `ScopeFor(permission)`, not the user's broadest display scope.
+
+### Process-global restrictions
+
+Some definitions have no owner. Their mutations require the corresponding permission with `all` scope even if the user has a `write` key:
+
+- AI testing roles, Skills, and Markdown Agents.
+- External MCP configuration.
+- Robot configuration.
+- Workflow definitions.
+- Knowledge mutations other than search.
+- Global HITL allowlist, reviewer, and audit policy.
+- C2 Profile mutations.
+- Some global monitor statistics.
+
+---
+
+## 6. Ownership, assignments, and inheritance
+
+Use Platform permissions → Member details → Resource assignments. Directly assignable resource types include:
+
+- `project`
+- `conversation`
+- `vulnerability`
+- `webshell`
+- `batch_task`
+- `c2_listener`
+
+A batch request accepts at most 100 resources. Duplicate grants are skipped.
+
+Supported inheritance includes:
+
+| Child resource | Parent access source |
+|----------------|----------------------|
+| Conversation | Project |
+| Vulnerability | Project or related conversation |
+| Message, process detail, attack chain | Conversation |
+| C2 Session | Listener |
+| C2 Task/file/event | Session, Task, or Listener chain |
+
+Assigning a project therefore usually avoids assigning each conversation and vulnerability separately. The concrete route/tool server check remains authoritative.
+
+---
+
+## 7. Web administration workflow
+
+### Create a user
+
+1. Sign in as an administrator and open **Platform permissions**.
+2. Create a user with username, display name, an eight-character-or-longer password, and enabled status.
+3. Assign one or more platform roles.
+4. For `assigned` roles, configure resource assignments.
+5. Have the user sign in again and verify roles, permission count, and scope in the top-right user menu.
+
+### Create a custom role
+
+1. Give the role a job-oriented name and description.
+2. Select `all`, `assigned`, or `own`.
+3. Select only required permissions.
+4. Test list, detail, mutation, deletion, Agent, and tool behavior with a test account.
+5. Assign it to production users only after verification.
+
+System roles are immutable; create a custom role instead of modifying them.
+
+### When changes take effect
+
+- Updating a user, password, enabled state, or role membership revokes that user's sessions; they must sign in again.
+- Updating or deleting a custom role revokes all sessions; all users must sign in again.
+- Robots resolve the bound user/service account on every message, so disablement and role changes affect the next message.
+- Background batch jobs resolve a Principal from the task owner rather than trusting frontend state.
+
+---
+
+## 8. Suggested role templates
+
+### Read-only project member
+
+```text
+Scope: assigned
+dashboard:read
+chat:read
+project:read
+vulnerability:read
+files:read
+attackchain:read
+```
+
+### Daily security operator
+
+```text
+Scope: assigned
+agent:execute
+chat:read / chat:write
+project:read / project:write
+vulnerability:read / vulnerability:write
+tasks:read / tasks:write
+files:read / files:write
+hitl:read / hitl:write
+```
+
+Add `agent:local-execute` or `terminal:execute` only when local commands are required. Add individual `:delete` permissions only when deletion is part of the job.
+
+### Robot service account
+
+```text
+Scope: own (isolated workspace) or assigned (specific projects)
+agent:execute
+chat:read / chat:write
+optional project, vulnerability, and knowledge permissions
+```
+
+`admin` can be used as a robot service account, but exact sender allowlisting still applies. Every allowlisted sender receives full permissions and shares admin-owned data. See the [Robot guide](robot.md).
+
+---
+
+## 9. Agent, MCP, and robot boundaries
+
+### Agent
+
+The HTTP user becomes an immutable Principal propagated to single-agent, multi-agent, workflow, and tool contexts. A long-running task may survive an SSE disconnect while retaining that identity.
+
+### Built-in MCP
+
+Every built-in tool requires an explicit authorization policy. WebShell tools check both `webshell:read/write/delete` and the target `connection_id`; project, vulnerability, task, and C2 tools validate resource arguments as well. An unregistered built-in policy fails closed. Other local/configured tools require `agent:local-execute`.
+
+### External MCP
+
+Agent calls to external MCP require `mcp:external:execute` with `all` scope because an external service's resource model is not protected by local ownership and assignments.
+
+### Robots
+
+- `user_binding`: each platform sender binds their own RBAC user.
+- `service_account`: exact allowlisted senders share one RBAC user.
+- Platform signature verification authenticates message origin, not business authorization.
+- Run `whoami` to inspect the effective Principal.
+
+---
+
+## 10. RBAC API
+
+All requests use:
+
+```http
+Authorization: Bearer <token>
+```
+
+Management routes require `rbac:read` or `rbac:write`; the resource picker requires `rbac:write`.
+
+| Method | Path | Purpose |
+|--------|------|---------|
+| GET | `/api/rbac/me` | Current user, roles, permissions, overall scope, per-permission scopes |
+| GET | `/api/rbac/metadata` | Permission catalog, roles, grants, and scopes |
+| GET/POST | `/api/rbac/users` | List/create users |
+| PUT/DELETE | `/api/rbac/users/:id` | Update/delete a user |
+| GET/POST | `/api/rbac/roles` | List/create roles |
+| PUT/DELETE | `/api/rbac/roles/:id` | Update/delete a custom role |
+| GET | `/api/rbac/resources?type=project&q=...` | Search assignable resources |
+| GET/POST | `/api/rbac/resource-assignments` | List/create assignments |
+| DELETE | `/api/rbac/resource-assignments/:id` | Revoke an assignment |
+
+Create a user:
+
+```bash
+curl -X POST http://localhost:8080/api/rbac/users \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "username": "operator01",
+    "display_name": "Security Operator 01",
+    "password": "change-me-123",
+    "enabled": true,
+    "roles": ["operator"]
+  }'
+```
+
+Create a custom role:
+
+```bash
+curl -X POST http://localhost:8080/api/rbac/roles \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "Project Auditor",
+    "description": "Read assigned projects",
+    "scope": "assigned",
+    "permissions": ["chat:read", "project:read", "vulnerability:read"]
+  }'
+```
+
+Assign projects:
+
+```bash
+curl -X POST http://localhost:8080/api/rbac/resource-assignments \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "user_id": "USER_ID",
+    "resource_type": "project",
+    "resource_ids": ["PROJECT_ID_1", "PROJECT_ID_2"]
+  }'
+```
+
+---
+
+## 11. Audit and operations recommendations
+
+- Use individual administrator accounts instead of sharing one password.
+- Name custom roles by job function and document purpose/owner.
+- Review high-risk permissions separately: `terminal:execute`, `agent:local-execute`, `c2:write/delete`, `webshell:write/delete`, `rbac:write`, and `config:write`.
+- Periodically review `all` roles, service accounts, robot allowlists, and dormant users.
+- On offboarding, disable the account first, then revoke robot bindings, assignments, and sessions.
+- Monitor RBAC denials, user/role changes, resource assignments, and robot service-account execution in audit logs.
+- Pair RBAC with HITL for dangerous tools; permission to invoke does not bypass approval policy.
+
+---
+
+## 12. Troubleshooting
+
+### A button is missing
+
+The frontend hides actions based on `/api/rbac/me`. Verify the required permission. Direct API calls are still rejected server-side.
+
+### Permission exists but the resource is denied
+
+Inspect the scope for that specific permission, not only the overall display scope. Then check owner, explicit assignment, and parent assignment.
+
+### Role changed but the user sees old access
+
+Role changes revoke sessions. Sign in again. Robots resolve again on the next message.
+
+### A global mutation is denied despite `write`
+
+Process-global definitions require the corresponding permission with `all` scope. Create a dedicated global administration role instead of widening unrelated permissions.
+
+### Agent chat works but commands fail
+
+`agent:execute` and `agent:local-execute` are separate. Grant local execution only when necessary and combine it with HITL, tool allowlists, and audit.
+
+### External MCP requires global scope
+
+The user needs `mcp:external:execute`, and that permission's scope must be `all`.
+

docs/en-US/robot.md

@@ -2,7 +2,7 @@
 
 [中文](../zh-CN/robot.md)
 
-This document explains how to chat with CyberStrikeAI from **personal WeChat**, **DingTalk**, **Lark (Feishu)**, and **WeCom (Enterprise WeChat)** using long-lived connections or HTTP callbacks—no need to open a browser on the server. Following the steps below helps avoid common mistakes.
+This guide covers **Personal WeChat, WeCom, DingTalk, Lark, Telegram, Slack, Discord, and QQ Bot**, including platform connectivity, RBAC identity binding, service-account allowlists, commands, verification, and troubleshooting.
 
 ---
 
@@ -15,10 +15,18 @@ This document explains how to chat with CyberStrikeAI from **personal WeChat**,
    - **Personal WeChat**: Open **WeChat / iLink** → **Generate QR code and bind**, then scan with WeChat (see [Section 3.4](#34-personal-wechat-wechat--ilink))
    - **DingTalk**: Enable and fill in Client ID / Client Secret
    - **Lark**: Enable and fill in App ID / App Secret
-5. Click **Apply configuration** to save (WeChat binding saves and enables automatically on success—usually no extra click needed)
-6. **Restart the CyberStrikeAI process** (DingTalk/Lark: saving alone does not establish the connection; WeChat auto-restarts the iLink poll after binding—usually no manual restart needed)
+5. Click **Apply configuration** to save and automatically restart the corresponding bot connection. WeChat binding saves and enables automatically on success.
 
-Settings are written to the `robots` section of `config.yaml`; you can also edit the file directly. **After changing DingTalk or Lark config, you must restart for the long-lived connection to take effect.** Personal WeChat binding automatically writes `robots.wechat` and restarts the iLink long poll.
+Settings are written to the `robots` section of `config.yaml`; you can also edit the file directly. Web-based **Apply configuration** restarts the corresponding connection automatically. Restart the CyberStrikeAI process only when editing YAML directly. Personal WeChat binding automatically writes `robots.wechat` and restarts the iLink long poll.
+
+### Shortest path to first use
+
+After the platform connection works, configure the business identity before sending normal prompts:
+
+- **Multiple users**: choose User binding → each user generates a code from the top-right Web user menu → sends the bind command to the bot → runs `whoami` to verify.
+- **Only you**: run `whoami` first and copy the sender ID → choose Service account → set User ID to `admin` or another RBAC user → paste the exact sender allowlist → apply configuration → run `whoami` again.
+
+Start normal AI chat only after the response shows an authorized status and the expected effective identity.
 
 ---
 
@@ -82,7 +90,7 @@ If you only have a **custom bot** Webhook URL (`oapi.dingtalk.com/robot/send?acc
    - In CyberStrikeAI: System settings → Robot settings → DingTalk.  
    - Enable “Enable DingTalk robot”.  
    - Paste the Client ID and Client Secret from step 3.  
-   - Click **Apply configuration**, then **restart CyberStrikeAI**.
+   - Click **Apply configuration**; CyberStrikeAI restarts the DingTalk connection automatically.
 
 ---
 
@@ -105,7 +113,7 @@ If you only have a **custom bot** Webhook URL (`oapi.dingtalk.com/robot/send?acc
 | App Secret | From Lark open platform app credentials |
 | Verify Token | Optional; for event subscription |
 
-**Lark setup in short**: Log in to [Lark Open Platform](https://open.feishu.cn) → Create an enterprise app → In “Credentials and basic info” get **App ID** and **App Secret** → In “Application capabilities” enable **Robot** and the right permissions → Add **event subscription** and **permissions** below → Publish the app → Enter App ID and App Secret in CyberStrikeAI robot settings → Save and **restart** the app.
+**Lark setup in short**: Log in to [Lark Open Platform](https://open.feishu.cn) → Create an enterprise app → In “Credentials and basic info” get **App ID** and **App Secret** → In “Application capabilities” enable **Robot** and the right permissions → Add **event subscription** and **permissions** below → Publish the app → Enter App ID and App Secret in CyberStrikeAI robot settings → **Apply configuration**.
 
 **Event subscription**  
 The long-lived connection only receives message events if you subscribe to them. In the app’s **Events and callbacks** (事件与回调) → **Event subscription** (事件订阅), add the event **Receive message** (**im.message.receive_v1**). Without it, the connection succeeds but no message events are delivered (no logs when users send messages).
@@ -272,12 +280,79 @@ In **Permission management** (权限管理), enable the following (names and ide
 
 ---
 
-## 4. Bot commands
+## 4. RBAC authorization and bot commands
+
+Platform credentials and callback signatures authenticate the messaging platform. CyberStrikeAI RBAC determines what the sender can actually do. Each bot instance uses one authorization mode.
+
+### 4.1 Choose an authorization mode
+
+| Scenario | Recommended mode | Identity and data behavior |
+|----------|------------------|----------------------------|
+| Shared WeCom, Lark, DingTalk, or Slack bot | `user_binding` | Each sender binds their own Web user; permissions and resources remain isolated |
+| Personal WeChat, single-user bot, fixed automation entry | `service_account` | Allowlisted senders share the configured RBAC user's permissions and owned resources |
+
+Both modes resolve user status, roles, per-permission scope, and resource assignments before every message. Basic AI chat requires:
+
+```text
+agent:execute
+chat:read
+chat:write
+```
+
+Grant project, role, local execution, WebShell, C2, or MCP permissions only when those features are required. Conversation deletion also requires `chat:delete`.
+
+### 4.2 User-binding mode (default)
+
+Administrator:
+
+1. Open System settings → Robot settings → select a platform.
+2. Set Authorization policy to `user_binding` and apply the configuration.
+
+Each user:
+
+1. Sign in to the Web UI and open the top-right user menu → **Bind robot account**.
+2. Generate a binding code; a five-minute countdown starts.
+3. Send the full command to the target bot, for example `bind 7C6E-BD4C`.
+4. Send `whoami` and confirm the effective RBAC identity is their own Web user.
+
+Codes are stored only as hashes and are single-use. When the countdown ends, the UI marks the code expired, disables copying, and refreshes the binding list; the server also rejects it. Generating a new code immediately invalidates the previous unused code. Users can send `unbind` or revoke a binding from the Web dialog.
+
+### 4.3 Service-account mode
+
+1. Connect the bot to its messaging platform.
+2. Have each intended sender run `whoami` and copy the exact sender ID. For Personal WeChat it usually resembles `xxxx@im.wechat`; never substitute `ilink_bot_id` or configured `ilink_user_id`.
+3. In Robot settings, select `service_account`.
+4. Enter the RBAC **User ID**, not its display name. `admin` is allowed; every allowlisted sender then receives full platform permissions and the UI shows a red warning.
+5. Add one exact sender ID per line. Matching is case-sensitive and `*` wildcards are rejected.
+6. Apply configuration and run `whoami` again to verify the effective user, roles, and scope.
+
+Example:
+
+```yaml
+robots:
+  wechat:
+    auth:
+      mode: service_account
+      service_user_id: admin
+      allowed_external_users:
+        - "o9cq806s32Sm2_kyOmkyaV7Rn1lU@im.wechat"
+```
+
+Service-account mode rejects `bind` and `unbind`. All allowlisted senders share conversations, projects, and other resources owned by the service account. Use `user_binding` when that sharing is undesirable.
+
+### 4.4 Inspect the effective identity
+
+Send `whoami`. The response includes platform, exact sender ID, authorization mode and status, effective RBAC user and ID, roles, scope, and permission count. A non-allowlisted sender sees only the denial status and no service-account details.
+
+### 4.5 Command list
 
 Send these **text commands** to the bot on any connected platform (text only):
 
 | Command | Description |
 |---------|-------------|
+| **绑定 \<code\>** or **bind \<code\>** | Bind the verified platform sender to the RBAC user that generated the code |
+| **解绑** or **unbind** | Remove the current platform identity binding |
+| **身份** or **whoami** | Show sender ID, authorization mode, binding status, and the effective RBAC user, roles, and scope |
 | **帮助** (help) | Show command help |
 | **列表** or **对话列表** (list) | List all conversation titles and IDs |
 | **切换 \<conversationID\>** or **继续 \<conversationID\>** | Continue in the given conversation |
@@ -292,6 +367,8 @@ Send these **text commands** to the bot on any connected platform (text only):
 
 Any other text is sent to the AI as a user message, same as in the web UI (e.g. penetration testing, security analysis).
 
+Group messages are authorized as the actual sender, never as a group ID. In service-account mode, explicitly allowlisted senders intentionally share the configured account.
+
 ---
 
 ## 5. How to use (do I need to @ the bot?)
@@ -310,14 +387,17 @@ Summary: **Personal WeChat and direct chat**—just send; **DingTalk/Lark in a g
 
 1. CyberStrikeAI web UI → System settings → Robot settings → **WeChat / iLink** → **Generate QR code and bind**.  
 2. Scan with WeChat and confirm (enter pairing code on the web page if prompted).  
-3. After binding, send “帮助” in the WeChat private chat to test.
+3. Send `whoami` in the WeChat private chat and copy the sender ID.
+4. Choose `user_binding`, or configure `service_account` with the RBAC user and exact sender allowlist.
+5. Apply configuration, run `whoami` again, then send a normal message.
 
 **DingTalk / Lark**
 
 1. **In the open platform**: Complete app creation, copy credentials, enable the bot (DingTalk: **Stream mode**), set permissions, and publish (Section 3).  
 2. **In CyberStrikeAI**: System settings → Robot settings → Enable the platform, paste Client ID/App ID and Client Secret/App Secret → **Apply configuration**.  
-3. **Restart the CyberStrikeAI process** (otherwise the long-lived connection is not established).  
-4. **On your phone**: Open DingTalk or Lark, find the bot (direct chat or @ in a group), send “帮助” or any message to test.
+3. **Choose authorization**: use `user_binding` for multiple users, or configure a service account and exact allowlist for a dedicated bot.
+4. **Apply configuration**; the Web UI restarts the corresponding connection automatically.
+5. **On your phone**: Open the bot, run `whoami` first, then send a normal message.
 
 If the bot does not respond, see **Section 9 (troubleshooting)** and **Section 10 (common pitfalls)**.
 
@@ -331,6 +411,11 @@ Example `robots` section in `config.yaml`:
 robots:
   wechat: # Personal WeChat iLink (auto-filled after QR bind; usually no manual edit)
     enabled: true
+    auth:
+      mode: service_account
+      service_user_id: admin
+      allowed_external_users:
+        - "exact sender ID copied from whoami"
     bot_token: "your_bot_token@im.bot:..."
     ilink_bot_id: "your_bot_id@im.bot"
     ilink_user_id: "your_user_id@im.wechat"
@@ -339,10 +424,14 @@ robots:
     bot_agent: "CyberStrikeAI/1.0"
   dingtalk:
     enabled: true
+    auth:
+      mode: user_binding
     client_id: "your_dingtalk_app_key"
     client_secret: "your_dingtalk_app_secret"
   lark:
     enabled: true
+    auth:
+      mode: user_binding
     app_id: "your_lark_app_id"
     app_secret: "your_lark_app_secret"
     verify_token: ""
@@ -372,7 +461,7 @@ robots:
     sandbox: true
 ```
 
-After changing DingTalk/Lark/WeCom/Telegram/Slack/Discord/QQ settings, **Apply configuration** restarts the corresponding connections. Personal WeChat QR binding saves and restarts automatically.
+Authorization is configured independently per platform; omitting `auth` defaults to `user_binding`. **Apply configuration** restarts the corresponding connections. Restart the process only after editing YAML directly. Personal WeChat QR binding saves and restarts automatically.
 
 ---
 
@@ -380,20 +469,24 @@ After changing DingTalk/Lark/WeCom/Telegram/Slack/Discord/QQ settings, **Apply c
 
 You can verify bot logic with the **test API** (no DingTalk/Lark client needed):
 
-1. Log in to the CyberStrikeAI web UI (so you have a session).
-2. Call the test endpoint with curl (include your session Cookie):
+1. Sign in with an account that has global `robot:write` permission and obtain a Bearer token.
+2. Call the test endpoint with curl:
 
 ```bash
-# Replace YOUR_COOKIE with the Cookie from your browser (F12 → Network → any request → Request headers → Cookie)
+# Adjust the URL, username, and password for your deployment
+TOKEN=$(curl -s -X POST "http://localhost:8080/api/auth/login" \
+  -H "Content-Type: application/json" \
+  -d '{"username":"admin","password":"YOUR_PASSWORD"}' | jq -r '.token')
+
 curl -X POST "http://localhost:8080/api/robot/test" \
   -H "Content-Type: application/json" \
-  -H "Cookie: YOUR_COOKIE" \
+  -H "Authorization: Bearer $TOKEN" \
   -d '{"platform":"dingtalk","user_id":"test_user","text":"帮助"}'
 ```
 
-If the JSON response contains `"reply":"【CyberStrikeAI 机器人命令】..."`, command handling works. You can also try `"text":"列表"` or `"text":"当前"`.
+If the JSON response contains `"reply":"【CyberStrikeAI 机器人命令】..."`, command handling works. `help`, `version`, and `whoami` work before binding. `list`, `current`, and normal AI messages enforce RBAC: the test `platform + user_id` must already be bound or exactly match the service-account allowlist.
 
-API: `POST /api/robot/test` (requires login). Body: `{"platform":"optional","user_id":"optional","text":"required"}`. Response: `{"reply":"..."}`.
+API: `POST /api/robot/test` (requires global `robot:write`). Body: `{"platform":"optional","user_id":"optional","text":"required"}`. Response: `{"reply":"..."}`. This endpoint simulates bot business logic only; it does not validate a third-party callback signature or long-lived connection.
 
 ---
 
@@ -407,7 +500,7 @@ Check in this order:
    Robot settings should show “Connected” or a bound Bot ID; `robots.wechat.bot_token` in `config.yaml` must not be empty.
 
 2. **Enabled?**  
-   Confirm “Enable WeChat robot” is checked; restart CyberStrikeAI if you just changed settings.
+   Confirm “Enable WeChat robot” is checked and click **Apply configuration** if you just changed settings.
 
 3. **Application logs**  
    - On startup: `微信 iLink 长轮询已启动`;  
@@ -430,8 +523,8 @@ Check in this order:
 1. **Client ID / Client Secret match the open platform exactly**  
    Copy from “Credentials and basic info”; avoid typing. Watch **0** vs **o** and **1** vs **l** (e.g. `ding9gf9tiozuc504aer` has **504**, not 5o4).
 
-2. **Did you restart after saving?**  
-   The long-lived connection is created at **startup**. “Apply configuration” only updates the config file; you **must restart the CyberStrikeAI process** for the DingTalk connection to start.
+2. **Did you apply the configuration?**  
+   Web changes require **Apply configuration**, which restarts the corresponding connection automatically. Restart the process only after editing `config.yaml` directly.
 
 3. **Application logs**  
    - On startup you should see: `钉钉 Stream 正在连接…`, `钉钉 Stream 已启动（无需公网），等待收消息`.  
@@ -441,6 +534,15 @@ Check in this order:
 4. **Open platform**  
    The app must be **published**. Under “Robot” you must enable **Stream** for receiving messages (HTTP callback only is not enough). Permission management must include robot receive/send message permissions.
 
+### 9.3 Reply says unbound, sender denied, or permission missing
+
+1. Run `whoami` and inspect the authorization mode and status.
+2. In `user_binding`, generate a code from the top-right Web user menu and send the complete bind command from the same platform identity. Regenerate expired or already-used codes.
+3. In `service_account`, copy the exact sender ID from `whoami` into that platform's allowlist. Preserve case, tenant prefixes, and suffixes such as `@im.wechat`.
+4. If an effective user is shown but permissions are missing, grant at least `agent:execute`, `chat:read`, and `chat:write` for normal AI chat.
+5. A missing or disabled service user is rejected when applying configuration.
+6. If `admin` is denied, the usual cause is an allowlist mismatch—not insufficient admin permissions.
+
 ---
 
 ## 10. Common pitfalls
@@ -448,7 +550,11 @@ Check in this order:
 - **Personal WeChat vs WeCom**: Personal WeChat uses `robots.wechat` + web QR bind; WeCom uses `robots.wecom` + admin callback URL—they are completely different.  
 - **WeChat QR expired**: QR codes last ~5 minutes; regenerate instead of reusing an old one.  
 - **Wrong bot type**: The “Custom” bot added in a DingTalk **group** (Webhook + sign secret) **cannot** be used for two-way chat. Only the **enterprise internal app** bot from the open platform is supported.  
-- **Saved but not restarted**: After changing DingTalk/Lark robot settings you **must restart** the app (WeChat QR bind restarts the connection automatically).  
+- **Configuration not applied**: Click **Apply configuration** after Web changes; connections restart automatically. A process restart is needed only for direct YAML edits.  
+- **Bot ID used as sender ID**: Copy the sender ID from `whoami`; do not use `ilink_bot_id`, configured `ilink_user_id`, a group ID, or a display name.  
+- **Reusing an expired code**: Codes last five minutes and are single-use; generating a new code immediately invalidates the old one.  
+- **Assuming service-account users are isolated**: All allowlisted senders share that account's conversations and owned resources. Use `user_binding` for isolation.  
+- **Assuming admin removes the allowlist**: It does not. The sender must still match exactly, but every matching sender gets full permissions.  
 - **Client ID typo**: If the platform shows `504`, use `504` (not `5o4`); prefer copy/paste.  
 - **DingTalk: only HTTP callback, no Stream**: This app receives messages via **Stream**. In the open platform, message reception must be **Stream mode**.  
 - **App not published**: After changing the bot or permissions in the open platform, **publish a new version** under “Version management and release”, or changes won’t apply.
@@ -459,5 +565,5 @@ Check in this order:
 
 - All platforms: **text messages only**; other types (e.g. image, voice) are not supported and may be ignored.  
 - Personal WeChat: **private chat only**—group @-bot is not supported.  
-- Conversations are shared with the web UI: conversations created from the bot appear in the web “Conversations” list and vice versa.  
+- Bot data is shared with the web UI: under `user_binding` it belongs to the bound user; under `service_account` it belongs to the service account and is shared by allowlisted senders.  
 - Bot execution uses the same **Eino single/multi-agent** path as the web UI (`ProcessMessageForRobot`, with progress callbacks and process details stored in the DB); only the final reply is sent back to personal WeChat/DingTalk/Lark/WeCom in one message (no SSE). Default: `robot_default_agent_mode: eino_single`.

docs/zh-CN/README.md

@@ -8,6 +8,7 @@
 - [贡献规范](contributing-guide.md)：新增 API、配置、工具、前端、数据库、高风险能力和文档的 checklist。
 - [配置参考](configuration.md)：`config.yaml` 字段、热应用边界、参数建议和源码锚点。
 - [安全模型](security-model.md)：信任边界、HITL、工具执行、C2/WebShell 与数据安全。
+- [RBAC 权限管理](rbac.md)：平台用户、系统/自定义角色、权限目录、逐权限 Scope、资源授权、Agent/MCP/机器人边界与 API 示例。
 - [架构说明](architecture.md)：请求路径、模块关系、复杂度热点和设计取舍。
 - [API 参考](api-reference.md)：认证、OpenAPI、SSE、稳定性分层和常用接口。
 - [排错指南](troubleshooting.md)：诊断顺序、最小命令、常见误判和故障模板。

docs/zh-CN/rbac.md

@@ -0,0 +1,386 @@
+# CyberStrikeAI RBAC 使用与管理指南
+
+[English](../en-US/rbac.md)
+
+CyberStrikeAI 是可执行 Agent、MCP、WebShell、C2 和批量任务的安全自动化平台。RBAC 不仅控制页面是否可见，还会贯穿 HTTP API、资源查询、Agent 上下文、内置/外部 MCP 工具、后台任务和机器人执行链路。
+
+---
+
+## 一、先区分两种“角色”
+
+| 概念 | 管理入口 | 作用 |
+|------|----------|------|
+| **平台角色（RBAC Role）** | 左侧 **平台权限** | 决定用户能调用哪些功能、能访问哪些资源 |
+| **AI 测试角色（Agent Role）** | 左侧 **角色** / `roles/*.yaml` | 决定 Agent 的提示词、测试方法和可选工具集合 |
+
+AI 测试角色不是安全授权边界。即使选择了“渗透测试”角色，用户仍必须拥有对应的平台权限；反过来，RBAC 有权限也不会自动改变 Agent 提示词。
+
+---
+
+## 二、授权模型
+
+一次访问同时满足以下条件才会放行：
+
+```text
+有效账号
+  + 路由/工具所需 permission
+  + 该 permission 对应的 scope
+  + 目标资源 owner / 显式授权 / 父资源继承
+  + 全局操作的额外限制
+```
+
+处理链路：
+
+1. 登录后签发 Bearer Token，会话包含用户、角色、权限和逐权限 Scope。
+2. HTTP 中间件把路由映射为权限，例如 `GET /api/projects` → `project:read`。
+3. 对带资源 ID 的请求继续校验 owner、显式资源授权或父资源继承。
+4. Agent 启动时把不可变 Principal 写入 `context.Context`。
+5. 内置 MCP 工具根据工具和参数再次检查权限与资源；外部 MCP 也有独立限制。
+6. 拒绝事件写入 RBAC/审计日志。
+
+前端隐藏按钮只用于改善体验，不构成安全边界；真正的拒绝发生在服务端。
+
+---
+
+## 三、内置平台角色
+
+| 角色 | Scope | 默认能力 |
+|------|-------|----------|
+| **管理员 `admin`** | `all` | 所有已知权限，包括 RBAC、配置、终端、审计删除和全局定义管理 |
+| **操作员 `operator`** | `assigned` | 日常读写与执行能力；不含 RBAC、核心配置、终端、审计管理、外部 MCP 执行和部分全局定义写权限 |
+| **审计员 `auditor`** | `all` | 各模块只读权限和 `audit:read`，不执行写操作 |
+| **只读用户 `viewer`** | `assigned` | 各模块只读权限，仅查看被授权范围 |
+
+系统角色不可修改或删除，升级时会按当前版本的权限目录重新构建授权，避免旧版本残留权限。需要不同组合时创建自定义角色。
+
+没有分配任何角色的账号仍可登录，但基本没有业务权限；不要依赖“无角色”作为完整岗位配置。
+
+---
+
+## 四、权限命名与目录
+
+权限使用 `模块:动作` 命名。常见动作：
+
+- `read`：查看、列表、查询、导出。
+- `write`：创建、更新、执行或管理。
+- `delete`：删除。
+- `execute`：执行 Agent、终端、工作流或特定能力。
+
+当前权限按模块分组如下；运行版本的权威目录以“平台权限”页面或 `GET /api/rbac/metadata` 为准。
+
+| 模块 | 权限 |
+|------|------|
+| 账号 | `auth:self` |
+| 仪表盘 | `dashboard:read` |
+| 对话 | `chat:read`、`chat:write`、`chat:delete` |
+| Agent | `agent:execute`、`agent:local-execute` |
+| HITL | `hitl:read`、`hitl:write` |
+| 任务 | `tasks:read`、`tasks:write`、`tasks:delete` |
+| 项目 | `project:read`、`project:write`、`project:delete` |
+| 漏洞 | `vulnerability:read`、`vulnerability:write`、`vulnerability:delete` |
+| WebShell | `webshell:read`、`webshell:write`、`webshell:delete` |
+| C2 | `c2:read`、`c2:write`、`c2:delete` |
+| MCP | `mcp:read`、`mcp:execute`、`mcp:write`、`mcp:external:execute` |
+| 知识库 | `knowledge:read`、`knowledge:write`、`knowledge:delete` |
+| Skills | `skills:read`、`skills:write`、`skills:delete` |
+| Markdown Agents | `agents:read`、`agents:write`、`agents:delete` |
+| AI 测试角色 | `roles:read`、`roles:write`、`roles:delete` |
+| 工作流 | `workflow:read`、`workflow:execute`、`workflow:write`、`workflow:delete` |
+| 系统配置 | `config:read`、`config:write` |
+| 终端 | `terminal:execute` |
+| 审计 | `audit:read`、`audit:delete` |
+| RBAC | `rbac:read`、`rbac:write` |
+| 通知 | `notification:read`、`notification:write` |
+| 机器人 | `robot:read`、`robot:write` |
+| 文件 | `files:read`、`files:write`、`files:delete` |
+| 攻击链 | `attackchain:read`、`attackchain:write` |
+| FOFA | `fofa:execute` |
+| OpenAPI | `openapi:read` |
+| 对话分组 | `group:read`、`group:write`、`group:delete` |
+| 执行监控 | `monitor:read`、`monitor:write`、`monitor:delete` |
+
+特殊权限说明：
+
+- `agent:execute` 允许运行 Agent，但不自动允许本地文件系统、Shell 或任意配置命令。
+- `agent:local-execute` 是本地执行兜底权限，应仅授予可信操作员。
+- `mcp:execute` 用于访问认证后的 MCP HTTP 入口。
+- `mcp:external:execute` 用于 Agent 调用外部 MCP 工具，当前还要求该权限的 Scope 为 `all`。
+- 管理外部 MCP 配置使用 `mcp:write`，与执行外部工具是两项权限。
+- `robot:write` 管理机器人配置和测试入口；机器人聊天本身使用绑定用户或服务账号的业务权限。
+
+---
+
+## 五、资源 Scope
+
+每个角色包含一个 Scope：
+
+| Scope | 含义 | 适合场景 |
+|-------|------|----------|
+| `all` | 访问该权限覆盖的所有资源 | 管理员、全局审计员 |
+| `assigned` | 访问管理员指定的资源及系统支持的父资源继承范围 | 项目成员、指定资产操作员 |
+| `own` | 以本人创建/归属资源为主；部分资源仍可通过显式授权或父资源关系访问 | 个人工作区、机器人独立身份 |
+
+权限和 Scope 是绑定在一起计算的。一个用户可拥有多个角色，权限取并集；**同一个权限**的 Scope 取最宽值：
+
+```text
+all > assigned > own
+```
+
+示例：
+
+- “全局审计”角色：`project:read` + `all`
+- “个人项目编辑”角色：`project:write` + `own`
+
+最终结果是：
+
+```text
+project:read  → all
+project:write → own
+```
+
+全局读取不会把无关的写权限扩大为全局写入。服务端授权必须使用 `ScopeFor(permission)`，不能使用用户的最宽总 Scope。
+
+### 全局对象限制
+
+部分对象是进程级共享定义，没有 owner。即使用户拥有 `write`，若该权限 Scope 不是 `all`，服务端仍拒绝修改。例如：
+
+- AI 测试角色、Skills、Markdown Agents。
+- 外部 MCP 配置。
+- 机器人配置。
+- 工作流定义。
+- 知识库写操作（搜索除外）。
+- HITL 全局白名单、默认审核方和审计策略。
+- C2 Profile 写操作。
+- 部分全局监控统计。
+
+---
+
+## 六、资源归属、显式授权与继承
+
+可在“平台权限 → 成员详情 → 资源授权”中给用户分配资源。当前可直接选择的主要类型：
+
+- 项目 `project`
+- 对话 `conversation`
+- 漏洞 `vulnerability`
+- WebShell `webshell`
+- 批量任务队列 `batch_task`
+- C2 Listener `c2_listener`
+
+一次批量授权最多 100 个资源。重复授权会跳过，不会创建重复记录。
+
+部分子资源会继承父资源访问能力：
+
+| 子资源 | 可继承的父资源 |
+|--------|----------------|
+| 对话 | 所属项目 |
+| 漏洞 | 所属项目或关联对话 |
+| 消息、过程详情、攻击链 | 所属对话 |
+| C2 Session | Listener |
+| C2 Task / 文件 /事件 | Session、Task 或 Listener 链路 |
+
+因此，给用户授权一个项目，通常不需要再逐个授权该项目中的每条对话和漏洞。仍应以具体页面/API 的服务端检查结果为准。
+
+---
+
+## 七、Web 管理流程
+
+### 7.1 创建用户
+
+1. 使用管理员进入左侧 **平台权限**。
+2. 创建平台用户，设置用户名、显示名称、至少 8 位密码和启用状态。
+3. 分配一个或多个平台角色。
+4. 若角色 Scope 为 `assigned`，继续配置资源授权。
+5. 让用户重新登录并在右上角用户菜单确认角色、权限数量和 Scope。
+
+### 7.2 创建自定义角色
+
+1. 新建平台角色并填写清晰的岗位名称与说明。
+2. 选择 `all`、`assigned` 或 `own`。
+3. 只勾选岗位实际需要的权限。
+4. 先用测试账号验证列表、详情、写操作、删除和 Agent 工具调用。
+5. 再批量分配给正式用户。
+
+系统角色不可编辑；复制其思路创建自定义角色即可。
+
+### 7.3 权限变更何时生效
+
+- 更新用户、密码、启用状态或角色后，该用户现有会话会被撤销，需要重新登录。
+- 更新或删除自定义角色后，平台会撤销全部现有会话，所有用户需重新登录。
+- 机器人每条消息实时解析绑定用户/服务账号权限；用户禁用或角色调整会立即影响下一条消息。
+- 后台批量任务会根据任务 owner 重新解析 Principal，不应依赖创建任务时的前端状态。
+
+---
+
+## 八、推荐角色模板
+
+以下是起点，不是固定策略。
+
+### 只读项目成员
+
+```text
+Scope: assigned
+dashboard:read
+chat:read
+project:read
+vulnerability:read
+files:read
+attackchain:read
+```
+
+### 日常安全操作员
+
+```text
+Scope: assigned
+agent:execute
+chat:read / chat:write
+project:read / project:write
+vulnerability:read / vulnerability:write
+tasks:read / tasks:write
+files:read / files:write
+hitl:read / hitl:write
+```
+
+只有确实需要本机命令时才增加 `agent:local-execute` 或 `terminal:execute`；需要删除时再增加对应 `:delete`。
+
+### 机器人专用账号
+
+```text
+Scope: own（独立工作区）或 assigned（指定项目）
+agent:execute
+chat:read / chat:write
+按需增加 project、vulnerability、knowledge 等权限
+```
+
+也可使用 `admin` 作为机器人服务账号，但发送者仍需精确白名单；白名单内每个人都会获得完整权限并共享 admin 数据。详见[机器人指南](robot.md)。
+
+---
+
+## 九、Agent、MCP 与机器人边界
+
+### Agent
+
+HTTP 登录用户会被转换为不可变 Principal，传入单 Agent、多 Agent、工作流和工具执行上下文。长任务脱离 SSE 连接后仍保留身份，但不会因为前端按钮可见而绕过服务端权限。
+
+### 内置 MCP
+
+每个内置工具必须有显式授权策略。例如 WebShell 工具会同时检查 `webshell:read/write/delete` 和 `connection_id` 的资源访问；漏洞、项目、任务与 C2 工具也会检查参数指向的资源。
+
+未登记授权策略的内置工具默认拒绝。普通本地/配置工具需要 `agent:local-execute`。
+
+### 外部 MCP
+
+Agent 调用外部 MCP 工具需要 `mcp:external:execute`，且当前要求 Scope 为 `all`。这是因为外部服务的资源模型通常不受本地 owner/assignment 约束。
+
+### 机器人
+
+- `user_binding`：平台发送者绑定自己的 RBAC 用户。
+- `service_account`：精确白名单发送者统一使用一个 RBAC 用户。
+- 平台验签只做来源认证，不代替业务授权。
+- 发送 `身份` / `whoami` 可检查实际 Principal。
+
+---
+
+## 十、RBAC API
+
+所有接口使用：
+
+```http
+Authorization: Bearer <token>
+```
+
+管理接口需要 `rbac:read` 或 `rbac:write`，资源选择器需要 `rbac:write`。
+
+| 方法 | 路径 | 说明 |
+|------|------|------|
+| GET | `/api/rbac/me` | 当前用户、角色、权限、总 Scope 与逐权限 Scope |
+| GET | `/api/rbac/metadata` | 权限目录、角色、角色权限和 Scope 列表 |
+| GET/POST | `/api/rbac/users` | 列出/创建用户 |
+| PUT/DELETE | `/api/rbac/users/:id` | 更新/删除用户 |
+| GET/POST | `/api/rbac/roles` | 列出/创建角色 |
+| PUT/DELETE | `/api/rbac/roles/:id` | 更新/删除自定义角色 |
+| GET | `/api/rbac/resources?type=project&q=...` | 分页搜索可授权资源 |
+| GET/POST | `/api/rbac/resource-assignments` | 列出/创建资源授权 |
+| DELETE | `/api/rbac/resource-assignments/:id` | 撤销资源授权 |
+
+创建用户示例：
+
+```bash
+curl -X POST http://localhost:8080/api/rbac/users \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "username": "operator01",
+    "display_name": "安全操作员 01",
+    "password": "change-me-123",
+    "enabled": true,
+    "roles": ["operator"]
+  }'
+```
+
+创建自定义角色示例：
+
+```bash
+curl -X POST http://localhost:8080/api/rbac/roles \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "项目审计员",
+    "description": "只读查看指定项目",
+    "scope": "assigned",
+    "permissions": ["chat:read", "project:read", "vulnerability:read"]
+  }'
+```
+
+批量授权项目示例：
+
+```bash
+curl -X POST http://localhost:8080/api/rbac/resource-assignments \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "user_id": "USER_ID",
+    "resource_type": "project",
+    "resource_ids": ["PROJECT_ID_1", "PROJECT_ID_2"]
+  }'
+```
+
+---
+
+## 十一、审计与运维建议
+
+- 使用个人账号管理平台，避免多人共享管理员密码。
+- 自定义角色按岗位命名，描述中写明用途和负责人。
+- 高风险权限单独审批：`terminal:execute`、`agent:local-execute`、`c2:write/delete`、`webshell:write/delete`、`rbac:write`、`config:write`。
+- 定期检查 `all` Scope 角色、服务账号、机器人白名单和长期未使用用户。
+- 用户离职时先禁用账号，再撤销机器人绑定、资源授权和会话。
+- 在日志审计中关注 `rbac/access_denied`、角色/用户变更、资源授权、机器人服务账号执行。
+- 配合 HITL 控制高风险工具；RBAC 允许调用不等于可以跳过审批。
+
+---
+
+## 十二、常见问题
+
+### 页面按钮看不到
+
+检查用户是否有对应权限；前端会根据 `/api/rbac/me` 隐藏无权操作。直接调用 API 仍会由服务端拒绝。
+
+### 有权限但返回“无权访问该资源”
+
+检查该权限的 Scope，而不是只看用户总 Scope；再检查资源 owner、显式授权和父资源授权。
+
+### 角色改了但用户仍是旧权限
+
+角色变更会撤销会话。让用户重新登录；机器人下一条消息会重新解析权限。
+
+### `write` 权限存在但全局配置仍被拒绝
+
+全局对象写操作要求对应权限的 Scope 为 `all`。创建一个 `all` Scope 的专用管理角色，而不是扩大无关权限。
+
+### Agent 能对话但不能运行命令
+
+`agent:execute` 与 `agent:local-execute` 分离。按需授予本地执行权限，并结合 HITL、工具白名单和审计。
+
+### 外部 MCP 提示需要 global scope
+
+除 `mcp:external:execute` 外，该权限的 Scope 还必须为 `all`。外部 MCP 的数据边界不由本地资源授权自动保护。
+

docs/zh-CN/robot.md

@@ -2,7 +2,7 @@
 
 [English](../en-US/robot.md)
 
-本文档说明如何通过**个人微信**、**钉钉**、**飞书**与 **企业微信** 与 CyberStrikeAI 对话（长连接 / 回调模式），在手机端即可使用，无需在服务器上打开网页。按下面步骤操作可避免常见弯路。
+本文档说明如何通过**个人微信、企业微信、钉钉、飞书、Telegram、Slack、Discord 和 QQ 机器人**使用 CyberStrikeAI，包括平台接入、RBAC 身份绑定、服务账号白名单、命令、验证与故障排查。
 
 ---
 
@@ -15,10 +15,18 @@
    - **个人微信**：点击「微信 / iLink」→「生成二维码并绑定」，用微信扫码确认（见 [3.4 个人微信](#34-个人微信-wechat--ilink)）
    - **钉钉**：勾选并填写 Client ID / Client Secret
    - **飞书**：勾选并填写 App ID / App Secret
-5. 点击 **应用配置** 保存（微信扫码绑定成功后会**自动保存并启用**，一般无需再点）
-6. **重启 CyberStrikeAI 应用**（钉钉/飞书：只保存不重启，长连接不会建立；微信绑定成功后会自动重启连接，通常无需手动重启）
+5. 点击 **应用配置** 保存；程序会自动重启对应机器人连接。微信扫码绑定成功后会自动保存并启用，一般无需再点。
 
-配置会写入 `config.yaml` 的 `robots` 段，也可在配置文件中直接编辑。**修改钉钉/飞书配置后必须重启，长连接才会生效。** 个人微信绑定成功后程序会自动写入 `robots.wechat` 并重启 iLink 长轮询。
+配置会写入 `config.yaml` 的 `robots` 段，也可在配置文件中直接编辑。通过 Web 点击“应用配置”会自动重启对应连接；直接手工修改 `config.yaml` 时，需要重启 CyberStrikeAI 进程。个人微信绑定成功后程序会自动写入 `robots.wechat` 并重启 iLink 长轮询。
+
+### 最短使用路径
+
+平台连接成功后，不要直接开始普通对话，先完成业务身份配置：
+
+- **多人使用**：机器人设置选择“逐用户绑定” → 每位用户在 Web 右上角头像生成绑定码 → 在机器人中发送绑定命令 → 发送 `身份` 验证。
+- **只有自己使用**：先在机器人中发送 `身份` 复制发送者 ID → 机器人设置选择“专用服务账号” → User ID 填 `admin` 或其他 RBAC 用户 → 粘贴发送者白名单 → 应用配置 → 再次发送 `身份` 验证。
+
+看到“鉴权状态：已授权”且“实际身份”正确后，即可直接发送普通文本与 AI 对话。
 
 ---
 
@@ -300,12 +308,88 @@
 
 ---
 
-## 四、机器人命令
+## 四、RBAC 鉴权与机器人命令
+
+平台 Token、签名或长连接凭证只负责证明“消息来自该平台”；真正能执行哪些操作，由 CyberStrikeAI 的 RBAC 决定。每个机器人实例都必须选择一种业务鉴权模式。
+
+### 4.1 应该选择哪种模式
+
+| 使用场景 | 推荐模式 | 身份与数据范围 |
+|----------|----------|----------------|
+| 企业微信、飞书、钉钉、Slack 等多人共享机器人 | `user_binding` | 每个发送者绑定自己的 Web 用户，权限和数据互相隔离 |
+| 个人微信、单人专属机器人、固定自动化入口 | `service_account` | 白名单发送者统一使用配置的 RBAC 用户，并共享该账号的数据 |
+
+两种模式都会在**每条消息**执行前重新读取用户状态、角色、逐权限 Scope 和资源授权。用户被禁用或权限被收回后，下一条消息立即失效。
+
+机器人执行普通 AI 对话至少需要以下权限：
+
+```text
+agent:execute
+chat:read
+chat:write
+```
+
+使用项目、角色、本地命令、WebShell、C2 或外部 MCP 时，还需按功能增加对应权限。删除对话需要 `chat:delete`。
+
+### 4.2 逐用户绑定模式（默认）
+
+管理员操作：
+
+1. 系统设置 → 机器人设置 → 选择平台。
+2. 在“业务鉴权策略”中选择“逐用户绑定（`user_binding`）”。
+3. 点击“应用配置”。
+
+每位使用者操作：
+
+1. 登录 CyberStrikeAI Web，点击右上角头像 → **绑定机器人账号**。
+2. 点击 **生成绑定码**，页面开始 5 分钟倒计时。
+3. 在目标机器人中发送页面给出的完整命令，例如 `绑定 7C6E-BD4C`。
+4. 发送 `身份` 或 `whoami`，确认“鉴权状态：已授权”且“实际身份”是自己的 Web 用户。
+
+绑定码仅保存哈希、只能使用一次。倒计时结束后前端会标记失效、禁用复制并刷新绑定列表；服务端也会拒绝过期码。重新生成会让此前尚未使用的旧码立即失效。用户可发送 `解绑`，或在 Web 绑定窗口中撤销绑定。
+
+### 4.3 专用服务账号模式
+
+1. 先让机器人正常连接平台。
+2. 目标使用者向机器人发送 `身份` / `whoami`，复制返回的完整“发送者 ID”。个人微信的 ID 通常形如 `xxxx@im.wechat`；必须以命令返回值为准，不能用 `ilink_bot_id` 或配置中的 `ilink_user_id` 代替。
+3. 系统设置 → 机器人设置 → 选择平台 → 业务鉴权策略选择“专用服务账号（`service_account`）”。
+4. 填写服务账号的 **RBAC User ID**，不是显示名称。可以填写 `admin`；此时白名单发送者拥有完整平台权限，界面会显示红色风险提示。
+5. 在“允许的平台发送者 ID”中每行填写一个完整 ID。必须精确匹配、区分大小写，不允许 `*` 通配符。
+6. 点击“应用配置”，再发送 `身份` 确认“实际身份”和角色正确。
+
+示例：
+
+```yaml
+robots:
+  wechat:
+    auth:
+      mode: service_account
+      service_user_id: admin
+      allowed_external_users:
+        - "o9cq806s32Sm2_kyOmkyaV7Rn1lU@im.wechat"
+```
+
+服务账号模式不接受 `绑定` / `解绑` 命令。多个白名单发送者会共享服务账号创建的对话、项目和其他 `own` 范围资源；若不希望共享，请使用逐用户绑定。
+
+### 4.4 如何检查当前身份
+
+发送：
+
+```text
+身份
+```
+
+返回内容包含：平台、真实发送者 ID、鉴权模式、鉴权状态、实际 RBAC 用户、RBAC User ID、平台角色、资源范围和有效权限数量。不在服务账号白名单中的发送者只会看到拒绝状态，不会看到服务账号详情。
+
+### 4.5 命令列表
 
 在任一已接入平台（钉钉/飞书/微信/Telegram/Slack/Discord/QQ 等）向机器人发送以下**文本命令**（仅支持文本）：
 
 | 命令 | 说明 |
 |------|------|
+| **绑定 \<绑定码\>** | 将当前平台发送者绑定到生成绑定码的 RBAC 用户 |
+| **解绑** | 解除当前平台账号绑定；也可在 Web 端的绑定列表中撤销 |
+| **身份** 或 **whoami** | 显示平台发送者 ID、鉴权模式、绑定状态及当前实际 RBAC 用户、角色和资源范围 |
 | **帮助** | 显示命令帮助与说明 |
 | **列表** 或 **对话列表** | 列出所有对话的标题与对话 ID |
 | **切换 \<对话ID\>** 或 **继续 \<对话ID\>** | 指定对话 ID，后续消息在该对话中继续 |
@@ -320,6 +404,8 @@
 
 除以上命令外，**直接输入任意文字**会作为用户消息发给 AI，与 Web 端对话逻辑一致（渗透测试/安全分析等）。
 
+群聊消息按实际发送者鉴权，不使用群 ID 作为业务身份。服务账号模式除外：白名单发送者会明确共享配置的服务账号权限和资源。
+
 ---
 
 ## 五、如何使用（要 @ 机器人吗？）
@@ -338,14 +424,17 @@
 
 1. CyberStrikeAI Web 端 → 系统设置 → 机器人设置 → **微信 / iLink** → **生成二维码并绑定**。  
 2. 手机微信扫码确认（如需配对数字则在 Web 页填写）。  
-3. 绑定成功后，在手机微信私聊中发「帮助」测试。
+3. 在手机微信私聊中发送 `身份`，复制发送者 ID。  
+4. 回到机器人设置选择 `user_binding`，或选择 `service_account` 并填写服务账号与发送者白名单。  
+5. 点击应用配置，在微信中再次发送 `身份`，确认实际 RBAC 身份后再发送普通消息。
 
 **钉钉 / 飞书**
 
 1. **在开放平台**：按第三节完成应用创建、凭证复制、机器人开通（钉钉务必选 **Stream 模式**）、权限与发布。  
 2. **在 CyberStrikeAI**：系统设置 → 机器人设置 → 勾选对应平台，粘贴 Client ID/App ID、Client Secret/App Secret → 点击 **应用配置**。  
-3. **重启 CyberStrikeAI 进程**（否则长连接不会建立）。  
-4. **在手机钉钉/飞书**：找到该机器人（单聊直接发，群聊需 @机器人），发「帮助」或任意内容测试。
+3. **选择鉴权模式**：多人使用建议 `user_binding`；专用机器人配置服务账号与发送者白名单。  
+4. **应用配置**：Web 会自动重启对应连接。  
+5. **在手机钉钉/飞书**：找到机器人（单聊直接发，群聊需 @），先发 `身份` 检查鉴权，再发普通内容测试。
 
 若发消息没反应，先看 **第九节排查** 和 **第十节常见弯路**。
 
@@ -359,6 +448,11 @@
 robots:
   wechat: # 个人微信 iLink（扫码绑定后自动写入，一般无需手填）
     enabled: true
+    auth:
+      mode: service_account
+      service_user_id: admin
+      allowed_external_users:
+        - "从身份命令复制的完整发送者 ID"
     bot_token: "your_bot_token@im.bot:..."
     ilink_bot_id: "your_bot_id@im.bot"
     ilink_user_id: "your_user_id@im.wechat"
@@ -367,10 +461,14 @@ robots:
     bot_agent: "CyberStrikeAI/1.0"
   dingtalk:
     enabled: true
+    auth:
+      mode: user_binding
     client_id: "your_dingtalk_app_key"
     client_secret: "your_dingtalk_app_secret"
   lark:
     enabled: true
+    auth:
+      mode: user_binding
     app_id: "your_lark_app_id"
     app_secret: "your_lark_app_secret"
     verify_token: ""
@@ -400,7 +498,7 @@ robots:
     sandbox: true
 ```
 
-修改钉钉/飞书/企业微信/Telegram/Slack/Discord/QQ 配置后，点击 **应用配置** 会自动重启对应长连接。个人微信扫码绑定成功后会自动写入并重启 iLink 连接。
+每个平台的 `auth` 独立配置；省略时默认为 `user_binding`。修改配置后，在 Web 点击 **应用配置** 会自动重启对应连接；手工编辑 YAML 则需重启进程。个人微信扫码绑定成功后会自动写入并重启 iLink 连接。
 
 ---
 
@@ -408,20 +506,24 @@ robots:
 
 在未安装钉钉或飞书时，可用**测试接口**验证机器人逻辑是否正常：
 
-1. 先登录 CyberStrikeAI Web 端（保证有登录态）。  
-2. 使用 curl 调用测试接口（需携带登录后的 Cookie）：
+1. 使用具有全局 `robot:write` 权限的账号登录并获取 Bearer Token。  
+2. 使用 curl 调用测试接口：
 
 ```bash
-# 将 YOUR_COOKIE 替换为登录后获得的 Cookie（浏览器 F12 → 网络 → 任意请求 → 请求头中的 Cookie）
+# 先登录；请按实际地址、用户名和密码修改
+TOKEN=$(curl -s -X POST "http://localhost:8080/api/auth/login" \
+  -H "Content-Type: application/json" \
+  -d '{"username":"admin","password":"YOUR_PASSWORD"}' | jq -r '.token')
+
 curl -X POST "http://localhost:8080/api/robot/test" \
   -H "Content-Type: application/json" \
-  -H "Cookie: YOUR_COOKIE" \
+  -H "Authorization: Bearer $TOKEN" \
   -d '{"platform":"dingtalk","user_id":"test_user","text":"帮助"}'
 ```
 
-若返回 JSON 中含有 `"reply":"【CyberStrikeAI 机器人命令】..."`，说明命令处理正常。可再试 `"text":"列表"`、`"text":"当前"` 等。
+若返回 JSON 中含有 `"reply":"【CyberStrikeAI 机器人命令】..."`，说明命令处理正常。`帮助`、`版本` 和 `身份` 可在未绑定时执行；`列表`、`当前` 和普通 AI 消息会走真实 RBAC，测试用 `platform + user_id` 必须已经绑定，或与服务账号模式的发送者白名单精确匹配。
 
-接口说明：`POST /api/robot/test`（需登录），请求体 `{"platform":"可选","user_id":"可选","text":"必填"}`，响应 `{"reply":"回复内容"}`。
+接口说明：`POST /api/robot/test`（需全局 `robot:write`），请求体 `{"platform":"可选","user_id":"可选","text":"必填"}`，响应 `{"reply":"回复内容"}`。该接口仅模拟机器人业务逻辑，不验证第三方平台签名或长连接。
 
 ---
 
@@ -458,8 +560,8 @@ curl -X POST "http://localhost:8080/api/robot/test" \
 1. **Client ID / Client Secret 是否与开放平台完全一致**  
    从「凭证与基础信息」里**复制粘贴**，不要手打。注意数字 **0** 与字母 **o**、数字 **1** 与字母 **l**（例如 `ding9gf9tiozuc504aer` 中间是 **504** 不是 5o4）。
 
-2. **是否在保存配置后重启了应用**  
-   机器人长连接在**应用启动时**建立。在 Web 端点击「应用配置」只写入配置文件，**必须重启 CyberStrikeAI 进程**后钉钉连接才会生效。
+2. **配置是否已应用**  
+   在 Web 端修改后必须点击“应用配置”，程序会自动重启对应连接。若直接手工编辑 `config.yaml`，则需重启 CyberStrikeAI 进程。
 
 3. **看程序日志**  
    - 启动后应看到：`钉钉 Stream 正在连接…`、`钉钉 Stream 已启动（无需公网），等待收消息`。  
@@ -469,6 +571,15 @@ curl -X POST "http://localhost:8080/api/robot/test" \
 4. **开放平台侧**  
    应用需已**发布**；在「机器人」能力中需开启**流式接入（Stream）** 用于接收消息（仅 HTTP 回调不够）；权限管理里需有机器人接收、发送消息等权限。
 
+### 9.3 收到回复但提示未绑定、白名单拒绝或权限不足
+
+1. 先发送 `身份`，查看“鉴权模式”和“鉴权状态”。
+2. `user_binding` 显示未绑定：在 Web 右上角头像中生成绑定码，并在同一个平台账号中发送完整绑定命令。绑定码过期或已经使用时需重新生成。
+3. `service_account` 显示白名单拒绝：把 `身份` 返回的完整发送者 ID 原样加入当前平台的白名单，注意大小写、租户前缀和 `@im.wechat` 等后缀。
+4. 显示实际身份但提示缺少权限：在“平台权限”检查该 RBAC 用户的角色。普通 AI 对话至少需要 `agent:execute`、`chat:read`、`chat:write`。
+5. 服务账号不存在或被禁用：应用配置会拒绝保存；恢复用户或选择其他已启用 RBAC 用户。
+6. 使用 `admin` 时仍被拒绝：通常是发送者不在精确白名单中，而不是 admin 权限不足。
+
 ---
 
 ## 十、常见弯路（避免踩坑）
@@ -476,7 +587,11 @@ curl -X POST "http://localhost:8080/api/robot/test" \
 - **个人微信与企业微信混淆**：个人微信走 `robots.wechat` + Web 扫码绑定；企业微信走 `robots.wecom` + 管理后台回调 URL，二者完全不同。  
 - **个人微信二维码过期**：二维码约 5 分钟有效，过期需重新生成，不要一直扫旧码。  
 - **用错了机器人类型**：在钉钉**群里**添加的「自定义」机器人（Webhook + 加签）**不能**用来做对话，本程序只支持**开放平台「企业内部应用」**里的机器人。  
-- **只保存没重启**：钉钉/飞书改完配置后必须**重启应用**，否则长连接不会建立（个人微信扫码绑定会自动重启连接）。  
+- **改完没有点应用配置**：Web 中修改机器人配置后要点击“应用配置”；程序会自动重启对应连接。只有手工编辑 YAML 时才需要重启进程。  
+- **把 Bot ID 当成发送者 ID**：服务账号白名单必须填写 `身份` 命令返回的“发送者 ID”，不要填 `ilink_bot_id`、`ilink_user_id`、群 ID 或显示昵称。  
+- **绑定码过期后继续使用**：绑定码 5 分钟有效且只能使用一次；新生成的码会让旧码立即失效。  
+- **服务账号误以为数据隔离**：同一服务账号白名单中的发送者共享该账号的对话和 `own` 范围资源；需要隔离时应使用 `user_binding`。  
+- **admin 配置后任意人都能用**：不会。即使服务账号是 `admin`，发送者仍必须与白名单精确匹配；但白名单中的人将拥有完整权限。  
 - **Client ID 抄错**：开放平台是 `504` 就填 `504`，不要填成 `5o4`；尽量用复制粘贴。  
 - **钉钉只开了 HTTP 回调没开 Stream**：本程序通过 **Stream 长连接**收消息，开放平台里机器人的消息接收方式必须选 **Stream 模式**。  
 - **应用没发布**：开放平台里修改了机器人或权限后，要在「版本管理与发布」里**发布新版本**，否则不生效。
@@ -487,5 +602,5 @@ curl -X POST "http://localhost:8080/api/robot/test" \
 
 - 各平台均**仅处理文本消息**；其他类型（如图片、语音）会提示暂不支持或忽略。  
 - 个人微信仅支持**私聊**，不支持群聊 @ 机器人。  
-- 会话与 Web 端共用同一套对话数据：在机器人里创建的对话会在 Web 端「对话」列表中看到，反之亦然。  
+- 会话与 Web 端共用同一套数据：`user_binding` 下归属于绑定用户；`service_account` 下归属于服务账号，并由白名单发送者共享。  
 - 机器人执行与 **Eino 单/多代理** 相同逻辑（`ProcessMessageForRobot`，含进度回调与过程详情入库），仅不向客户端推送 SSE，最后一次性回复个人微信/钉钉/飞书/企业微信。默认 `robot_default_agent_mode: eino_single`。