给AIAgent加一道安全闸门!不让AI乱删服务器文件

很多人在玩AI Agent的时候，都会担心一件事：AI拿到命令行权限，万一脑子一抽，执行rm -rf /，直接把整个系统删没了怎么办？

今天咱们就聊聊，怎么在AI调用工具执行之前，先做权限校验，给AI加上三道安全关卡。这就是咱们今天讲的权限管线方案。

一、先说说老版本的问题

之前版本的Agent，已经能看懂你的需求、调用工具干活。 但是有个巨大隐患：文件工具会做路径保护，可bash命令不受限制。 你让AI清理项目，它有可能直接执行毁灭性命令，把系统文件全部删除。

老逻辑：AI思考 → 直接调用工具执行，没有前置安全检查，风险全靠大模型自觉，不靠谱。

安全思路：把安全判断写在代码里，在工具真正运行之前拦截，而不是指望AI自己不乱搞。

二、核心方案：三道闸门权限管线

整体逻辑非常简单：原来Agent整套循环逻辑完全不动，只新增一段代码，每次调用工具前，先跑一遍权限校验函数checkPermission()。

三道闸门按顺序依次判断，优先级从高到低：

1. 闸门1：拒绝列表（硬拦截，最高优先级）
2. 闸门2：规则匹配（判断是否属于高危操作）
3. 闸门3：人工审批（高危操作弹出确认框，交给人决定）

✅ 流程：AI准备调用工具 → 闸门1判断 → 命中直接拒绝；没命中走闸门2；闸门2命中，就触发闸门3，询问用户；三道都没命中，直接放行执行。

闸门1：拒绝列表，绝对禁止的操作

一句话：黑名单！只要命令命中黑名单，直接一票否决，不给执行机会。 像rm -rf /、sudo、shutdown、reboot这类毁灭性指令，直接写进黑名单，只要出现，立刻拦截。

示例代码

// 黑名单列表：永远禁止执行的指令
private static final List<String> DENY_LIST = List.of(
"rm -rf /",
"sudo",
"shutdown",
"reboot",
"dd if=",
"> /dev/sda"
);

/**
 * 闸门1：检查是否命中黑名单
 * @param command 待执行命令
 * @return null=没问题；有返回值=被拦截，返回拦截原因
 */
public static String checkDenyList(String command) {
for (String pattern : DENY_LIST) {
if (command.contains(pattern)) {
return "Blocked: [" + pattern + "] 在禁止列表中";
        }
    }
return null;
}

闸门2：规则匹配，识别有风险的操作

黑名单只拦固定指令，很多风险是和场景绑定的。 比如：

• 读写文件，但是路径跑到咱们工作目录外面了（去读/etc系统文件）
• bash里执行删除、修改权限这类破坏性命令

这一层，我们写自定义规则，识别这类潜在危险操作，命中之后，不会直接拒绝，而是交给第三道闸门，找人工确认。

Java示例代码

/**
 * 闸门2：自定义风险规则匹配
 * @param toolName 工具名称，bash / read_file / write_file
 * @param args 工具入参（路径、命令等）
 * @return null=无风险；返回文字=存在风险，需要人工审批
 */
public static String checkRules(String toolName, Map<String, Object> args) {
// 规则1：文件读写工具，不能访问工作目录之外的路径
if (List.of("read_file", "write_file", "edit_file").contains(toolName)) {
String path = (String) args.get("path");
if (!isInWorkspace(path)) {
return "Access outside workspace，访问范围超出工作目录";
        }
    }

// 规则2：bash工具，检测破坏性命令
if ("bash".equals(toolName)) {
String cmd = (String) args.get("command");
if (hasDestructiveCommand(cmd)) {
return "Potentially destructive command，存在破坏性指令";
        }
    }
return null;
}

// 辅助方法：判断路径是否在工作区内
private static boolean isInWorkspace(String path) {
String workspace = "/workspace/";
return path.startsWith(workspace);
}

// 辅助方法：正则检测删除、高危修改类指令
private static boolean hasDestructiveCommand(String command) {
String pattern = "(rm|del|chmod 777|> /etc)";
return Pattern.compile(pattern).matcher(command).find();
}

闸门3：用户审批，高危操作人工确认

闸门2识别到风险之后，程序暂停，弹窗询问用户：是否允许这条命令执行？ 用户输入Y，放行；输入N，拒绝执行。

Java示例代码

/**
 * 闸门3：询问用户，人工审批
 * @param toolName 工具名
 * @param args 参数
 * @param reason 触发审批的原因
 * @return allow / deny
 */
public static String askUser(String toolName, Map<String, Object> args, String reason) {
    System.out.println("\n⚠️ 需要人工审批：" + reason);
    System.out.println("工具：" + toolName + " 参数：" + args);
    Scanner scanner = new Scanner(System.in);
    System.out.print("是否允许执行？[y/N]：");
String input = scanner.nextLine().trim().toLowerCase();
return "y".equals(input) || "yes".equals(input) ? "allow" : "deny";
}

三、把三道闸门串起来：总入口 checkPermission

把上面3个闸门按顺序组合，写一个统一校验方法，每次AI准备调用工具时，优先执行这个方法。

/**
 * 权限校验总入口：三道闸门流水线
 * @param toolBlock AI要调用的工具信息
 * @return true 允许执行；false 拦截
 */
public static boolean checkPermission(ToolBlock toolBlock) {
// 闸门1：黑名单硬拦截，优先级最高
    String denyReason = checkDenyList(toolBlock.getCommand());
if (denyReason != null) {
        System.out.println("❌ " + denyReason);
return false;
    }

// 闸门2：风险规则检测
    String ruleReason = checkRules(toolBlock.getToolName(), toolBlock.getArgs());
if (ruleReason != null) {
// 闸门3：交给用户审批
        String decision = askUser(toolBlock.getToolName(), toolBlock.getArgs(), ruleReason);
if ("deny".equals(decision)) {
            System.out.println("❌ 用户拒绝执行");
return false;
        }
    }
// 三道关卡全部通过
returntrue;
}

嵌入Agent主循环

原来Agent循环代码几乎不用改动，只增加一行权限判断，这就是这个方案最优雅的地方：老逻辑保留，安全能力横向插入，不破坏原有Agent思考逻辑。

// Agent 主循环，调用工具的地方
for (ToolBlock block : toolCalls) {
// 新增：执行前先校验权限
if (!checkPermission(block)) {
// 权限不通过，返回拒绝结果给大模型
        resultList.add(ToolResult.fail("Permission denied."));
continue;
    }
// 原有逻辑：执行工具
    String output = ToolHandlers.run(block.getToolName(), block.getArgs());
    resultList.add(ToolResult.success(output));
}

四、新旧版本对比，一眼看懂改动

五、动手测试一下

你可以用下面这些指令，测试这套安全管线效果：

1. 在当前目录新建test.txt → 无风险，直接放行
2. 删除当前目录的test.txt → 触发闸门2，弹出人工确认
3. 读取当前目录文件列表 → 安全，直接放行
4. 尝试写入/etc目录文件 → 超出工作目录，触发审批
5. 执行rm -rf / → 闸门1黑名单直接拦截，不给确认机会

六、下一站：钩子扩展

现在权限校验代码直接写在Agent循环里面，如果后续想加日志、自动提交git等更多扩展，循环代码会越来越臃肿。 下一阶段，我们引入钩子Hooks，把各类扩展逻辑挂载到钩子上，保持主循环干净清爽。

文末小结

AI Agent最怕的就是“失控乱执行命令”。 这套方案核心思想一句话：不要信任AI的自律，在代码层面加前置关卡。 三道闸门层层递进：高危毁灭性命令直接拉黑；有潜在风险的操作交给人把关；普通安全操作直接放行。 原有Agent主体逻辑不用大改，低侵入式增加安全防护，非常适合自研Agent落地。