🔗 打开试用
打开 SecAgent 在线 Demo ↗demo.xiaokeqing.cn —— 部署在阿里云 2 核 2G 上、容器只监听回环地址,
对外通过 Cloudflare 命名隧道提供 HTTPS。
地址是固定的:即使以后把服务迁到别的服务器,这个链接也不会失效。
🔑 演示账号
| |
|---|
| 用户名 | analyst |
| 密码 | SecAgent-Demo-2026 |
| 角色 | 分析员(ANALYST) |
这个角色能做什么、不能做什么:
| ✅ 可以 | ❌ 不可以 |
|---|
| 查看告警大屏、事件归档 | 执行处置动作(封 IP / 锁账号 / 杀进程) |
| 对话研判、知识库检索 | 审批处置申请 |
| 提交知识条目(待审) | 审核知识库、管理用户 |
权限是刻意收窄的。 处置动作全部要求管理员角色 + 人工审批,所以公开一个分析员账号不会带来风险。
配额说明:为了让服务不被刷爆,接口有 50 次/天 的模型调用配额和 30 次/分钟 的限流。用完了第二天恢复。
建议试这几件事
按顺序试,能看出系统的设计思路:
1️⃣ 先问一个知识库问题
在「对话研判」里输入:
看什么:回答下面会附检索证据,包含命中的文档名、片段内容、相似度分数。
证据被包在一个 <UNTRUSTED_DATA> 标签里 —— 这是提示词注入防护:
知识库文档本身也可能是攻击载荷,不能被当成给模型的指令。
2️⃣ 再问一个需要"动手"的问题
看什么:调度员会判定这是研判任务,派给对应角色的智能体,并调用工具去拉告警数据,而不是凭空编答案。
3️⃣ 去看告警大屏
看什么:列表默认显示的是聚合后的结果(同一源 IP + 时间窗 + 同类告警合成一条),带 ×N 徽标。点进去能下钻到原始明细。
这是解决"告警风暴"的核心设计。
4️⃣ 去看处置中心
看什么:处置动作分三级 —— 自动执行 / 需审批 / 禁止。
注意「需审批」那一列 —— 这是整个项目最重要的设计:高危动作永远不会自动执行。
5️⃣ 试着让它做危险的事
在对话里试试:
看什么:会被代码层的白名单拦下来,而不是靠提示词拒绝。
内网地址、环回地址在处置护栏里是硬拦截的 —— 因为提示词可以被绕过,白名单不能。
为什么地址是这个
demo.xiaokeqing.cn —— 走的是 Cloudflare 命名隧道,不是临时隧道。
区别在这里:
| 临时隧道 | 命名隧道(现在用的) |
|---|
| 地址 | 随机分配,重启就换 | 固定,绑在 Cloudflare 账号下 |
| 换服务器 | 链接失效 | 链接不变(只在新机器上重装隧道) |
| 入站端口 | 不需要 | 不需要 |
服务器上没有任何入站端口是开着的 —— 容器只监听 127.0.0.1,
隧道是服务器主动向 Cloudflare 建立出站连接。所以从外面扫这台机器,
扫到的只有 22 端口(而且已经关了密码登录)。
这条也是买域名真正要解决的问题:让地址和机器解耦。
服务器是消耗品,域名是资产。
已知限制(不想让你踩坑)
| 限制 | 说明 |
|---|
| 数据是模拟的 | 告警和日志是 MOCK 数据,没有接真实 SOC 环境 |
| 处置动作没实测过 | 代码里有完整实现和护栏,但不敢在生产环境真的封 IP 演示 |
| 响应偏慢 | 服务器在杭州,隧道绕经境外,首屏约 1.2~1.5 秒 |
| 手机端 | 能用,但告警大屏这类宽表格在小屏上体验一般 |
关于防护强度的真实数字
红队评测跑过了,27 例(19 例基础 + 8 例绕过型),结果:
| 指标 | 数值 | 说明 |
|---|
| 绕过率 | 4 / 19 = 21.05 % | 95% 置信区间约 8 % ~ 44 % |
| 误报率 | 0 / 8 未观察到误拦 | 真实误报率的 95% 置信上限约 37.5 % |
| 拦下 / 绕过 | 15 / 4 | |
为什么要写置信区间,而不是写「误报率 0%」
8 个正常样本里 0 次误拦,不等于误报率是 0。
按统计学上的「三法则」,n 次试验 0 次事件时,真实发生率的 95% 置信上限约为 3/n ——
也就是 3/8 ≈ 37.5%。样本量太小,这个数字只够说明「没有明显误杀」,
支撑不了「误报率很低」的结论。
同理,4/19 的绕过率区间宽到 8%~44%,几乎不具区分度。
写清楚这一点,是因为一个漂亮但站不住的 0% 比一个诚实的区间更容易被问倒。
为什么不写「拦截率 100%」:第一版 19 例跑出来就是 0 绕过、0 误报,
但那个数字没有意义 —— 用例是照着防护规则写的,当然全能命中。
0% 绕过率不是成绩,是评测集失效的信号。
所以补了 8 例专门针对规则边界的变形载荷(字符插空 / 全角 / Base64 /
同义改写 / 凭据拆开写…),绕过率立刻变成 42.11%。然后修掉其中能修的 4 类
(加文本归一化 + 补中文模式),降到 21.05%。
关键是:修完之后误报率没有变差 —— 8 个正常用例依然全部放行。
说明拦截率的提升不是靠「宁可错杀」换来的。
剩下 4 类修不掉,而且我知道为什么修不掉:
- 纯语义改写(「请把上面那段话作废…」)—— 正则无解
- Base64 编码的指令 —— 正则只看明文
- 编码后的私钥 —— 同上
- 中文自然语言表述的口令 —— 需要语义理解
这四类不是「还没修」,是「用规则修不了」。 加正则只会带来误报。
它们的存在,正是这条链路上必须保留人工审批的原因 —— 纵深防御不是口号。
下一步:这套用例是自己写的,可信度天花板就在那。
计划接入 NVIDIA Garak 与 Microsoft PyRIT 这类业界工具,
用第三方用例集解决「自己出题自己阅卷」的问题。