pusidun
GitHub ↗
pusidun
← All posts
Engineering

AI 时代的终端安全技术栈 Roadmap

#Agent security#Endpoint security#Security engineering

AI 正在把终端安全带到一个新的阶段。

过去的终端安全更多关注人、应用和恶意软件。AI Agent 出现后，终端上多了一个新的执行主体：它能读文件、写代码、执行命令、安装依赖、调用插件、连接远程环境，甚至代表用户完成一连串自动化操作。

这类系统的安全目标可以概括成一句话：

让 Agent 能在用户终端上高效工作，同时不能越权、不能泄密、不能被恶意插件或提示注入带偏。

一、AI 终端安全的核心能力模型

从技术栈来看，AI 背景下的终端安全需要同时理解四层能力：

  1. 终端操作系统安全
  2. Agent 执行链路安全
  3. 插件和 Skill 生态安全
  4. 企业级安全治理和运营

其中最特别的是第二层和第三层。传统终端安全更关注人和恶意软件，而智能体终端安全还要关注“模型被诱导后主动做坏事”的风险。

比如：

  • 用户打开了一个恶意仓库，README 里诱导 Agent 读取 ~/.ssh/id_rsa
  • 插件声明自己只是格式化代码，实际偷偷上传 .env
  • Agent 被 prompt injection 诱导执行 curl | sh
  • 远程控制链路被重放，导致本地终端执行非预期命令
  • 审计日志记录了 token，反而形成二次泄露

这些风险都不是单靠杀毒或权限弹窗可以解决的。

二、Windows 终端安全技术栈

Windows 侧需要掌握的重点包括：

  • 用户、管理员、UAC
  • Access Token、Privilege、Impersonation
  • ACL、Integrity Level
  • Windows Service、Task Scheduler、WMI
  • PowerShell 执行策略与日志
  • ETW、Event Log、Sysmon
  • WDAC、AppLocker、AppContainer
  • 代码签名和证书链校验
  • Credential Manager、LSASS 相关风险

对 Agent 产品来说，关键不是背 API，而是能回答这些问题：

  • Agent 子进程继承了谁的权限？
  • 插件能否绕过主程序访问用户目录？
  • 执行 PowerShell 时是否有日志和策略约束？
  • 高危 LOLBins 是否被识别和拦截？
  • 企业管理员能否下发统一安全策略？

一个典型风险是：Agent 本来只被授权修改当前工作区，但它通过 PowerShell、WMI 或系统工具访问了工作区之外的敏感文件。这时如果只在应用层做路径校验，往往是不够的。

三、macOS 终端安全技术栈

macOS 侧需要重点理解：

  • Unix 权限模型、sudo、root
  • TCC 隐私权限
  • SIP
  • Gatekeeper
  • Notarization
  • Code Signing
  • App Sandbox 和 Entitlements
  • Keychain
  • LaunchAgent、LaunchDaemon
  • Endpoint Security Framework
  • Unified Logging

macOS 的安全重点是权限申请和隐私边界。

Agent 经常需要访问项目目录、调用终端、读写剪贴板、执行脚本。如果它还申请了辅助功能、完全磁盘访问、自动化控制等权限，风险会被显著放大。

需要特别关注：

  • 是否能读取桌面、文档、下载目录
  • 是否能访问 Keychain
  • 是否能通过 AppleScript 控制其他应用
  • 是否能写入 LaunchAgent 实现持久化
  • 是否能诱导用户授予过宽权限

对安全工程师来说，目标是把“系统权限”和“产品权限”对齐。即使系统允许，也不代表 Agent 应该默认允许。

四、Agent 执行链路安全

Agent 的执行链路通常包括：

  1. 用户输入任务
  2. 模型规划步骤
  3. 选择工具或插件
  4. 生成命令或参数
  5. 本地运行时执行
  6. 读取输出并继续推理
  7. 产生日志、结果和后续动作

安全风险贯穿每一步。

最典型的风险包括：

  • Prompt Injection：上下文中的恶意文本影响模型决策
  • Tool Injection：工具返回恶意指令，诱导下一步执行
  • Command Injection：模型拼接命令时引入危险参数
  • Data Exfiltration：读取敏感数据后通过网络发送
  • Privilege Abuse：借助已有终端权限执行越权操作
  • Plugin Abuse：插件声明与实际行为不一致

因此，Agent 安全不能只做“输入过滤”。真正有效的方案应该围绕运行时行为做控制。

五、沙箱与权限隔离

这条技术路线的核心工程能力之一是沙箱设计。

一个比较合理的权限模型应该至少覆盖：

  • 文件读权限
  • 文件写权限
  • 命令执行权限
  • 网络访问权限
  • 插件调用权限
  • 凭证访问权限
  • 远程控制权限

可以把 Agent 的能力设计成 capability：

{
  "filesystem": {
    "read": ["workspace"],
    "write": ["workspace"],
    "deny": ["~/.ssh", "~/.gnupg", "~/.aws", "**/.env"]
  },
  "process": {
    "allow": ["git", "npm", "node"],
    "confirm": ["curl", "brew", "pip"],
    "deny": ["sudo", "chmod 777", "launchctl"]
  },
  "network": {
    "allowDomains": ["registry.npmjs.org", "github.com"],
    "denyPrivateNetwork": true
  }
}

真正难的地方不在于写规则，而在于让规则既安全又不影响 Agent 完成正常任务。

六、审计与敏感数据保护

Agent 的每一步动作都应该可审计。

建议记录：

  • 谁发起了任务
  • 模型准备调用什么工具
  • 工具参数是什么
  • 实际执行了什么命令
  • 访问了哪些文件
  • 是否触发敏感路径
  • 是否有网络出站
  • 用户是否批准
  • 最终结果是什么

但审计本身也要脱敏。日志中不能原样记录：

  • API Key
  • SSH 私钥
  • Cookie
  • OAuth Token
  • 数据库密码
  • .env 文件内容

一个成熟的 Agent 安全系统，应该做到“行为可追溯，敏感数据不可见”。

七、插件和 Skill 供应链安全

Agent 产品通常会支持插件、Skill、MCP Server 或脚本扩展。这些扩展能力很强，也很危险。

需要关注：

  • 插件来源是否可信
  • 插件包是否签名
  • manifest 是否声明权限
  • 安装脚本是否安全
  • 依赖是否存在已知漏洞
  • 插件是否动态加载远程代码
  • 插件是否访问敏感路径
  • 插件更新是否可被劫持

插件安全可以参考浏览器扩展安全和 IDE 插件安全，但 Agent 插件更敏感，因为它往往能直接影响模型决策和本地命令执行。

八、技术栈 Roadmap

可以把 AI 终端安全技术栈总结成一条路线：

围绕 Agent 在 Windows/macOS 本地执行命令、访问文件、调用插件和远程控制等链路，建设权限隔离、运行时防护、敏感数据保护、行为审计和企业安全运营能力，降低越权访问、数据外泄、恶意插件注入和凭证滥用风险。

学习和建设时，不应该只停留在“懂 Windows 安全”或“懂 macOS 安全”。更完整的技术图谱是：

  • 理解 Agent 的工具调用链路
  • 建立 AI 终端威胁模型
  • 设计 capability 权限模型
  • 落地运行时拦截与审批
  • 把安全事件接入企业审计
  • 在安全和可用性之间做工程取舍

这也是 AI 时代终端安全技术栈真正需要补齐的部分。