场景解决方案 · WEB-ITDR
AI Agent 与
非人访问治理
AI 助手、Agent、RPA、脚本与服务账号带着人的凭据访问业务系统，身份系统看到的只是「员工正常登录」。本方案按识别、确权、授权、监测四步，把这些访问变成可查、可管、可追责的对象。
The Problem
自动化访问带着人的凭据进来
AI 助手、Agent、RPA、脚本与服务账号都在访问业务系统，用的是员工授权过的凭据或长期有效的密钥。身份系统看到的是一次正常登录，业务系统看到的是一次正常请求，没有哪一层回答「这次到底是谁在操作」。
Where It Applies
五类非人访问，治理取向各不相同
先把「非人」拆开。同样是自动化，来源、责任关系与风险不同，处理方式也不该一样——多数需要的是登记和限权，不是拦截。
| 类别 | 典型形态 | 治理取向 |
|---|---|---|
| 研发环境中的 AI 助手 | 嵌在 IDE 或代码平台里，以开发者身份访问代码仓、测试接口与数据源 | 登记 + 限定可访问的应用范围 |
| 员工授权的通用 Agent | 员工把跨系统的操作交给一段程序，凭据来自本人的授权 | 登记 + 关键动作复核 |
| 浏览器接管类工具 | 直接驱动真实浏览器，继承已经完成的登录与会话 | 严格审核 + 行为基线 |
| 企业自有 RPA 与脚本 | 排班运行的流程机器人、定时脚本与监控探针 | 白名单登记 + 凭据生命周期审计 |
| 外部自动化与攻击工具 | 撞库、爬取、探测类脚本，不属于企业已知的自动化 | 按行为与上下文处置 |
上表按来源与责任关系分类，不是产品支持清单。自动化访问不等于恶意——前四类都是企业里本来就该存在的东西，治理的目标是让它们有登记、有责任人、有授权范围，而不是一律拦截。
第五类的判定依据是这次访问的行为与上下文。不能仅凭工具名称、客户端自述字段或来源云 IP 段直接下结论：同一个隧道工具、同一个云出口，合法业务也在用。
How It Works
识别、确权、授权、监测
四步是一条流水线，也是四件可以分别验收的交付物：一份清单、一组责任关系、一套授权范围、一条持续的监测线。缺任何一件，剩下的都落不了地。
| 识别依据的特征层 | 这一层观察的是什么 |
|---|---|
| 网络层 | 传输握手阶段的客户端特征，用于区分浏览器与程序化客户端 |
| 应用层 | 请求头的组合与顺序，以及客户端自述的身份 |
| 设备与运行环境 | 渲染与运行环境特征，用于识别无界面的自动化运行方式 |
| 交互行为 | 请求之间的时间关系，以及是否存在人机交互事件 |
| 身份关联 | 同一时间窗口内的员工会话、设备与授权令牌，用于把访问关联到责任人 |
多层联合判断，是因为单独任何一层都可以被绕过或伪造；层数不构成准确率承诺。可用的特征层随接入方式变化——旁路镜像与反向代理看到的东西不同，加密流量的可见范围也取决于 TLS 终止位置。识别结果要与责任关系一起看，才谈得上处置。
Division of Responsibility
谁登记、谁授权、谁执行
非人访问治理横跨安全、业务与研发。落地失败大多不是技术问题，而是没约定清楚谁负责哪一段。
| 环节 | Web ITDR | 由现有系统或团队负责 |
|---|---|---|
| 发现与识别 | 在访问链路上识别自动化访问并分类 | 通常没有对应系统，这是本方案补的一层 |
| 台账登记 | 提供已识别对象的清单与访问记录 | 申请与审批流程由 IT 或安全团队维护 |
| 凭据与密钥管理 | 不签发、不托管、不轮换凭据 | 密钥管理与 IAM：签发、轮换与回收 |
| 责任人确认 | 给出关联依据与候选责任人 | 责任归属由管理流程确认，不自动认定 |
| 授权范围 | 按策略限制可访问的应用与接口 | 业务系统自身的权限模型仍然有效 |
| 复核与审批 | 触发复核并记录结果 | 审批动作在企业既有的审批或工单系统中完成 |
| 处置执行 | 在代理链路上放行、验证或拦截 | 停用账号、吊销令牌由身份与密钥系统执行 |
「责任人」指对这次自动化访问负责的人或部门，由管理流程确认。关联结果是给人看的依据，不构成对自然人的自动认定；关联不成立的对象要单独列出来，而不是就近挂到某个账号上。
Rollout
先看清楚，再动策略
治理最容易翻车的做法，是一上来就开拦截。按观测、分类、授权、处置四步推进，每一步都有可以交付的东西，再决定要不要收紧。
- 以观测方式接入，先不介入业务链路
- 统计出现了哪些自动化访问、频次与目标应用
- 输出第一版非人访问清单
- 按来源与责任关系归入五类
- 逐项确认责任人或申请部门
- 标记已停用与来源不明的对象
- 为已登记对象划定应用与接口范围
- 约定哪些动作需要复核
- 先把合规自动化登记进来
- 按策略执行放行、验证或拦截
- 未登记对象先告警观察一段时间
- 处置记录进入审计
顺序很重要：先登记合规自动化，再开处置。反过来做，第一批被拦住的往往是对账机器人或监控探针这类本来就该跑的东西，业务侧一次中断，整个治理就会停摆。
Validation
用两个已知对象对照验证
验证不需要复杂的攻防场景。取一个企业内已知的合规自动化，再取一个已知的 AI 助手，看下面四件事能不能答上来。
建议在验证前约定参与的对象清单、时间窗口与判定标准；未完成验证前不填报识别率一类的数字。演示环境展示的是产品演示场景，用于说明依据如何支持判断，不是某一位客户的实际事件记录。
Expert Consultation
拿您环境里的一个自动化访问，走一遍识别与确权
告诉我们企业内已在使用的 AI 工具、RPA 与服务账号情况，我们会按这些对象演示识别依据、责任人关联方式与授权策略的写法：
识别依据演示
按您在用的工具说明判定依据
确权方式核对
自动化访问如何关联到责任人
授权策略草案
登记、复核、授权与拦截的分档
飞书扫码，即可咨询