AI Agent身份窃取防御实战：macOS文件权限与网络端口加固指南

1. 项目概述：当你的AI助手成为攻击者的“完美替身”

最近在安全圈里，一个新兴的威胁类别让我这个老运维后背发凉——AI Agent身份窃取。这不再是传统的盗个密码、偷个Cookie那么简单。想象一下，攻击者通过一个普通的窃密木马，把你本地AI助手（比如Claude Desktop、Cursor、OpenClaw）的整个“人格”和“记忆”打包偷走。这个“人格”包括了它的行为指令、私钥、API令牌、甚至是与你对话的全部历史记录。攻击者拿到这些后，就能在另一个地方启动一个完全相同的AI助手，以你的身份、你的权限，持续、自主地行动。而当你发现异常，想去重置密码时，你会发现这招根本没用，因为被盗的不是一个可撤销的凭据，而是一个完整的、可独立运行的数字实体。

这个威胁在2025年初已经发生了实际案例。安全公司Hudson Rock确认了一起感染事件，Vidar窃密木马扫描并窃取了一个用户.openclaw目录下的全部身份文件。更令人担忧的是，SecurityScorecard的报告显示，全球有超过13.5万个OpenClaw实例暴露在互联网上，其中近八成运行着未打补丁的版本。现有的身份与访问管理（IAM）系统，压根就没为这种“AI代理身份”设计过防护和审计策略。

面对这种“降维打击”，我们不能坐以待毙。今天分享的，就是我针对macOS平台（特别是Apple Silicon的Sequoia系统）整理的一套实战加固脚本集。它们不搞花架子，就是三个单功能、聚焦的Bash脚本，帮你从文件权限和网络暴露面这两个最基础的层面，给本地AI Agent套上一层“金钟罩”。无论你是个人开发者、安全研究员，还是对AI工具深度依赖的技术从业者，这套脚本都能帮你快速评估风险并实施基础加固，把“家贼难防”的风险降到最低。

2. 安全加固的核心思路与脚本设计哲学

在动手写代码之前，我花了大量时间琢磨这个问题的本质。AI Agent身份窃取之所以危险，核心在于两点：数据的集中性和身份的持久性。

数据的集中性：与传统应用将配置散落在各处不同，现代AI桌面客户端倾向于将所有状态——从人格设定（soul.md）、密钥材料（device.json）、会话令牌到聊天记忆——集中存储在用户主目录下几个明确的、结构化的文件夹里（如~/.claude,~/.openclaw）。这对用户来说很方便，对窃密木马来说更是“天堂”——它们不需要复杂的逻辑去拼凑信息，一次简单的目录遍历就能“一锅端”。

身份的持久性：被盗的如果是一个OAuth令牌，失效它就行了。但如果被盗的是一个包含椭圆曲线私钥（常见于device.json）和长期有效的网关令牌的完整身份包，那么这个身份在服务端看来就是合法的“你”。攻击者可以永久性地使用这个身份，直到你手动在服务端吊销它——而很多服务目前甚至不提供这样的吊销界面。

基于这两点，我的加固思路非常明确：最小权限原则和攻击面收敛。脚本的设计也遵循了几个铁律：

1. 只做一件事，并做到极致：每个脚本功能单一，避免复杂的逻辑交织导致难以理解和审计。1_tighten_agent_permissions.sh只管文件权限，2_check_port_18789.sh只管端口检查，3_inventory_agents.sh只管资产清点。
2. 默认安全，显式操作：所有可能改变系统的操作（如修改权限），都必须以--apply参数显式触发。默认情况下，脚本只做“模拟运行”（dry-run），详细告诉你它会做什么，但绝不真做。
3. 对macOS生态深度适配：充分利用macOS特有的工具链，如stat -f检查权限、defaults读取应用配置、lsof和pfctl管理网络，而不是写一套跨平台的“阉割版”逻辑。这保证了脚本在目标环境下的有效性和可靠性。
4. 透明与可审查：脚本代码开源、简洁，所有文件匹配规则、权限设置值都一目了然。鼓励用户在运行前阅读代码，在模拟运行后审查输出，确认无误后再应用。

这套脚本的目标不是提供一个银弹解决方案，而是为你提供一个坚实、可自动化的基线。在复杂的攻防对抗中，守住基线往往就赢得了大半。

3. 脚本详解（一）：资产清点与风险发现

在加固之前，你必须先知道自己有什么。3_inventory_agents.sh就是这个阶段的“侦察兵”。它的任务不是修改任何东西，而是给你一份详细的本地AI Agent资产清单和潜在的风险报告。

3.1 脚本的核心扫描逻辑

这个脚本的内部逻辑像一张精心设计的检查单，按顺序扫描以下几个关键层面：

第一层：应用本身的存在性检查。脚本会检查一些常见的AI辅助工具是否通过主流方式（如Homebrew Cask、官方App）被安装。它通过查询/Applications目录和Homebrew的安装记录来实现。这一步是为了给你一个宏观概览。

第二层：配置目录的深度遍历。这是重中之重。脚本定义了一个名为AGENT_DIRS的数组，包含了所有已知的AI Agent配置目录路径，例如：

• ~/.claude和~/Library/Application Support/Claude(Claude Desktop)
• ~/.cursor和~/Library/Application Support/Cursor(Cursor)
• ~/.openclaw和~/Library/Application Support/OpenClaw(OpenClaw)
• 以及Continue、Codeium、Aider等其他工具的目录。

对于每一个存在的目录，脚本会使用find命令进行递归遍历，并执行以下关键操作：

• 列出所有文件：直观展示该Agent存储了哪些数据。
• 识别凭据类文件：通过文件名模式匹配（如包含credential、secret、token、key、config等关键词的.json、.yml、.env文件），高亮显示那些可能包含敏感信息的文件。这是发现“明文存储”风险的关键。
• 检查文件权限：使用stat -f %Lp命令获取文件的数字权限码。它会特别关注那些权限过于宽松的文件（例如，权限码为644或755意味着同组或其他用户可读）。

第三层：MCP服务器连接审计。模型上下文协议（MCP）是AI Agent连接外部数据和工具的核心通道，但也可能成为攻击面。脚本会搜索配置文件中关于MCP服务器的声明（通常在soul.md或主配置文件中），并列出所有配置的MCP服务器地址和名称。一个你不认识的、指向外部可疑地址的MCP服务器，就是巨大的风险。

3.2 解读脚本输出与风险研判

运行bash 3_inventory_agents.sh后，你会得到一份结构化的报告。你需要像医生看化验单一样审视几个关键部分：

1. 凭据文件列表：这是风险高发区。你需要逐一核对列表中的文件。例如，一个路径为~/.openclaw/device.json的文件被标记出来。你应该用文本编辑器（切勿在终端直接cat，防止内容被记录）小心打开它，查看里面是否包含私钥、Bearer Token等字段。如果发现API密钥直接以明文形式存储，这就是一个必须修复的高危项。

2. 宽松的文件权限：脚本会列出所有权限不是600（仅所有者可读可写）或700（仅所有者可读可写可执行）的文件和目录。例如，如果你看到~/.claude/sessions/chat_history.db的权限是644，这意味着同一台机器上的其他用户账户（如果有）也能读取你的全部聊天历史。在共享开发机或存在多用户的环境下，这是隐私泄露的通道。

3. MCP服务器配置：检查列出的每一个MCP服务器。你是否主动配置了它？它的地址（如http://localhost:8080或sshd://example.com）是否可信？一个未知的sshd://服务器可能意味着你的Agent被配置为通过SSH执行远程命令，而这可能被滥用。

注意：脚本的凭据文件匹配基于文件名启发式规则（heuristics），可能存在误报。比如一个名为libcredentials_helper.js的库文件会被标记，但它本身可能不包含有效凭据。因此，脚本的输出是审计的起点，而非终点。你必须人工审查每个被标记的项目，基于上下文判断其真实风险。

4. 脚本详解（二）：网络暴露面检查

资产清点完后，接下来要看这些Agent是否“门户大开”。2_check_port_18789.sh脚本聚焦于一个具体但高危的风险点：OpenClaw默认端口（18789）的暴露情况。OpenClaw默认会监听这个端口以提供本地服务，但如果防火墙配置不当，它可能会监听在0.0.0.0（所有网络接口）上，从而暴露给同一网络内的其他设备，甚至公网。

4.1 端口检查的技术细节

这个脚本虽然短小，但每一步都有讲究：

1. 使用lsof进行精准探测：脚本核心命令是lsof -i :18789 -sTCP:LISTEN。这里有几个关键参数：

   • -i :18789：指定检查18789端口。
   • -sTCP:LISTEN：只查看处于LISTEN（监听）状态的TCP连接。这排除了已经建立的连接，直指正在等待接受新连接的服务。
   • -n：禁止将IP地址转换为主机名。这能让命令执行更快，输出更清晰。
   • -P：禁止将端口号转换为服务名（如http）。确保我们看到的就是确切的端口号。

2. 解析输出，判断风险：lsof命令会输出监听该端口的进程信息，其中最关键的一列是“NODE”，它显示了监听地址。你需要重点关注：

   • localhost或127.0.0.1：仅本地可访问，风险较低，是预期行为。
   • 0.0.0.0或*：监听在所有网络接口上。这意味着同一Wi-Fi或局域网内的其他计算机，都可能尝试连接到你的OpenClaw实例。这是需要警惕的状态。
   • 你的本地局域网IP（如192.168.1.100）：效果同0.0.0.0，暴露在局域网内。

3. 提供修复命令：如果脚本检测到端口暴露，它会打印出两条pfctl命令。这是macOS内置的防火墙（Packet Filter）控制工具。

   • sudo pfctl -a com.apple/250.OpenClawBlock -F all：这首先会刷新（-F all）名为OpenClawBlock的规则锚点（anchor）里的所有规则。锚点是pf防火墙的一个规则集合单元。
   • sudo pfctl -a com.apple/250.OpenClawBlock -Ef /dev/stdin <<‘EOF‘ ... EOF：这是一个经典技巧。-E启用防火墙（如果未启用），-f从文件加载规则。这里通过输入重定向（<<‘EOF‘）从标准输入（/dev/stdin）加载规则，规则内容就是屏蔽对18789端口的入站访问。

4.2 防火墙规则持久化的坑与解决

脚本提供的命令立竿见影，但有一个至关重要的限制：通过pfctl直接添加的规则在系统重启后会失效。这是因为这些规则没有被写入pf的主配置文件/etc/pf.conf。

对于需要持久化规则的用户，你必须手动编辑/etc/pf.conf文件。操作前务必备份！

1. 首先备份原配置：sudo cp /etc/pf.conf /etc/pf.conf.backup
2. 使用sudo vim /etc/pf.conf（或你喜欢的编辑器）打开配置文件。
3. 在文件末尾，rdr-anchor和load anchor相关条目的后面，添加你的规则。例如：

   # 阻塞OpenClaw默认端口的外部访问 block in proto tcp from any to any port 18789

4. 保存文件后，重新加载pf配置使其生效：sudo pfctl -f /etc/pf.conf

实操心得：修改/etc/pf.conf需要格外小心，语法错误可能导致防火墙失效或网络中断。建议先在测试机上练习。对于大多数个人用户，如果只是临时检查，运行脚本提供的命令即可。对于服务器或长期开机的开发机，才考虑持久化配置。另外，macOS的图形化“系统设置-网络-防火墙”只能管理应用级防火墙，对于这种特定端口的精细控制，命令行工具pfctl是更强大的选择。

5. 脚本详解（三）：文件系统权限加固

这是整个加固流程的核心操作步骤，由1_tighten_agent_permissions.sh完成。它的原理基于Unix/Linux文件系统权限模型，目标是将AI Agent配置数据的访问权限，收紧到“仅所有者本人可读可写”。

5.1 Unix权限模型回顾与加固目标

在macOS（基于Unix）中，每个文件和目录都有三组权限：所有者（user）、所属组（group）和其他用户（others）。每组权限用三位二进制表示（读r、写w、执行x），常以八进制数字表示：

• 7(111): 读、写、执行
• 6(110): 读、写
• 5(101): 读、执行
• 4(100): 只读
• 0(000): 无权限

一个权限755（即-rwxr-xr-x）的目录，意味着所有者可读可写可进入，而同组用户和其他用户只能读和执行（进入）。对于存储敏感身份信息的AI Agent目录，这显然过宽了。

本脚本的加固目标非常明确：

• 目录权限设为700(drwx------)：仅所有者可以进入、列出内容、在其中创建文件。其他任何用户（包括同组用户）都无法访问。
• 普通文件权限设为600(-rw-------)：仅所有者可以读取和修改。其他用户无法进行任何操作。

5.2 脚本的“模拟运行”与“安全执行”机制

这是脚本设计中最体现“安全第一”思想的部分。它通过一个dry_run标志来实现。

当你直接运行bash 1_tighten_agent_permissions.sh时，脚本处于“模拟运行”模式。它会：

1. 遍历所有预定义的AI Agent配置目录。
2. 对于每个目录，使用find命令定位需要处理的条目。
3. 只打印出它将要执行的chmod命令，而并不真正执行。

例如，输出可能如下：

[DRY RUN] Would set directory permission to 700 for: /Users/yourname/.claude [DRY RUN] Would set file permission to 600 for: /Users/yourname/.claude/config.json [DRY RUN] Would set file permission to 600 for: /Users/yourname/.claude/sessions/chat_001.json

这给了你一次完整的“预演”机会，你可以仔细检查哪些路径会被修改，确认没有误包含系统关键目录或你不想动的文件。

只有当你明确加上--apply参数，即运行bash 1_tighten_agent_permissions.sh --apply时，脚本才会将dry_run标志设为假，并真正执行这些chmod命令。

5.3 智能排除与避免“误伤”

在收紧权限时，最怕的是“一刀切”导致应用无法正常运行。AI Agent的目录里除了配置文件，往往还有缓存、扩展插件（extensions）、第三方库（node_modules）等。对这些目录施加过于严格的限制，可能会让Agent无法更新插件或加载必要的库。

因此，脚本内置了排除规则：

• 排除extensions/和node_modules/目录：这些目录通常包含大量第三方代码，需要一定的宽松权限才能正常安装和运行。脚本在遍历时会跳过这些路径，避免因权限问题导致插件系统崩溃。
• 排除符号链接：通过find -type l排除符号链接，只处理实体文件和目录，防止递归修改到其他系统区域。

这个设计体现了“最小影响”原则：在保障核心身份数据安全的同时，尽可能维持应用功能的完整性。当然，这也意味着extensions/目录本身可能成为一个潜在的风险点，因为恶意插件可能驻留其中。这就需要结合脚本3_inventory_agents.sh的审计结果，手动管理插件来源的安全性。

6. 实战操作流程与现场记录

理论说再多，不如动手走一遍。下面是我在一台干净的macOS Sequoia (15.1) 测试机上的完整操作记录，假设机器上已安装了Claude Desktop和Cursor。

第一步：获取与准备脚本

# 1. 将三个脚本下载到本地，例如放在 ~/Security/ai_hardening 目录下 cd ~/Security mkdir ai_hardening && cd ai_hardening # （假设你已经通过git clone或直接下载获得了三个.sh文件） # 2. 赋予脚本执行权限 chmod +x 1_tighten_agent_permissions.sh 2_check_port_18789.sh 3_inventory_agents.sh # 3. 首先，运行资产清点脚本，了解现状 bash 3_inventory_agents.sh

清点脚本输出节选：

=== AI Agent 资产清点报告 === 扫描时间：2024-05-27 10:30:00 [!] 发现已安装应用： - Claude Desktop (位于 /Applications/Claude.app) - Cursor (位于 /Applications/Cursor.app) === 检查配置目录 === [*] 目录存在: /Users/test/.claude [+] 找到潜在凭据文件： - /Users/test/.claude/claude_desktop_config.json (权限: 644) [!] 发现宽松权限文件： - /Users/test/.claude/claude_desktop_config.json (644 -> 建议 600) - /Users/test/.claude/sessions/2024-05-26.db (644 -> 建议 600) [*] 目录存在: /Users/test/Library/Application Support/Claude （目录权限为755，正常） [*] 目录存在: /Users/test/.cursor [+] 找到潜在凭据文件： - /Users/test/.cursor/auth_token.json (权限: 600) # 良好，已是600 （未发现异常宽松权限） === MCP服务器配置摘要 === 在 /Users/test/.claude/claude_desktop_config.json 中发现MCP服务器配置： - 名称: filesystem - 地址: local （配置看起来正常）

从报告看出，Claude的配置文件权限是644，存在风险。Cursor的令牌文件权限良好。

第二步：检查网络端口

bash 2_check_port_18789.sh

端口检查输出：

=== 检查 OpenClaw 默认端口 (18789) 暴露情况 === 运行命令: lsof -nP -i :18789 -sTCP:LISTEN 未发现进程监听在 18789 端口。 您的 OpenClaw 端口未暴露，或 OpenClaw 未运行。

这台测试机没有安装或运行OpenClaw，所以端口安全。

第三步：预览权限修改（模拟运行）

bash 1_tighten_agent_permissions.sh

模拟运行输出节选：

=== AI Agent 目录权限加固 (模拟运行模式) === [*] 处理目录: /Users/test/.claude [DRY RUN] 将设置目录权限为 700: /Users/test/.claude [DRY RUN] 将设置文件权限为 600: /Users/test/.claude/claude_desktop_config.json [DRY RUN] 将设置文件权限为 600: /Users/test/.claude/sessions/2024-05-26.db [跳过] 排除目录: /Users/test/.claude/node_modules (如存在) [*] 处理目录: /Users/test/Library/Application Support/Claude [DRY RUN] 将设置目录权限为 700: /Users/test/Library/Application Support/Claude （目录下未发现需要收紧权限的配置文件） ... (类似输出继续) ...

输出详细列出了所有即将被修改的路径。仔细核对，确认没有误包含个人文档或其他关键目录。

第四步：应用权限修改

# 确认模拟运行输出无误后，执行实际修改 bash 1_tighten_agent_permissions.sh --apply

实际运行输出：

=== AI Agent 目录权限加固 (应用模式) === [*] 处理目录: /Users/test/.claude 已设置目录权限为 700: /Users/test/.claude 已设置文件权限为 600: /Users/test/.claude/claude_desktop_config.json 已设置文件权限为 600: /Users/test/.claude/sessions/2024-05-26.db [跳过] 排除目录: /Users/test/.claude/node_modules ... (操作成功完成) ... ✅ 权限加固操作完成。

第五步：验证加固效果再次运行资产清点脚本，检查权限是否已更新：

bash 3_inventory_agents.sh | grep -A2 “发现宽松权限文件”

此时，输出中应该不再显示Claude的那些配置文件，因为它们已经从644被加固为600了。

7. 超越脚本：构建纵深防御体系

这三个脚本提供了重要的基础加固，但安全是一个体系工程。要有效防御AI Agent身份窃取，你还需要在以下几个层面构建纵深防御：

1. 密钥与令牌的生命周期管理

• 迁移明文令牌到密钥链：脚本会帮你发现明文存储的令牌，但修复需要手动操作。对于macOS用户，最安全的方式是使用系统自带的“钥匙串访问”（Keychain Access）。你可以将API密钥从config.json中删除，转而使用钥匙串服务来存储和提供。许多成熟的命令行工具（如security命令）和SDK都支持与钥匙串交互。
• 探索使用硬件密钥：对于最高安全级别的场景，考虑支持FIDO2/WebAuthn的硬件安全密钥（如YubiKey）进行身份验证。这能从根源上防止私钥文件被窃取，因为私钥永远不出硬件设备。
• 定期轮换与审计：即便使用了钥匙串，也应定期检查AI Agent服务商账户的“已登录设备”或“活动会话”列表，主动吊销不认识的设备。如果服务支持，定期轮换API密钥。

2. 终端与软件供应链安全

• 保持所有Agent软件更新：攻击者常利用已知漏洞。确保Claude Desktop、Cursor、OpenClaw等客户端设置为自动更新，或养成定期手动检查更新的习惯。SecurityScorecard报告中78%的OpenClaw实例未打补丁，这就是最大的可乘之机。
• 严格审查插件与扩展：CoSAI的MCP威胁目录和报告中提到的“12%的AI Agent市场插件被确认为恶意软件”都指向了供应链攻击。只从官方市场或极度信任的来源安装插件。定期使用3_inventory_agents.sh审计已安装的MCP服务器和扩展，移除任何不明确或不必要的组件。
• 强化终端安全基线：在macOS上，确保“系统设置-隐私与安全性”中的各项保护（如完全磁盘访问、自动化控制）被合理配置。考虑使用额外的端点检测与响应（EDR）软件，它们可以检测窃密木马等恶意行为。

3. 网络与行为监控

• 启用并配置macOS防火墙：除了用脚本管理特定端口，确保系统级防火墙（系统设置-网络-防火墙）处于开启状态。对于高级用户，可以配置pf规则集，限制AI Agent进程的非必要出站连接（如果它们不需要访问外部网络的话）。
• 监控异常网络活动：使用活动监视器或终端命令如lsof -i和netstat，偶尔检查AI Agent进程建立了哪些网络连接。一个向陌生IP地址发送数据的连接值得深究。
• 隔离高风险活动：如果需要进行高风险的分析或测试，考虑在专用的虚拟机（VM）或容器中运行AI Agent。这样即使被入侵，攻击者也难以触及宿主机的核心数据。

4. 意识与流程

• 将AI Agent视为特权用户：在心理上和组织流程上，将能访问代码库、内部文档和操作系统的AI Agent，视为一个需要严格管理的“特权用户”。其身份文件（soul.md,device.json等）应等同于特权账户的SSH私钥。
• 建立事故响应预案：思考一下，如果你的AI Agent身份疑似泄露，第一步该做什么？可能是立即在相关服务商处吊销该设备身份，检查最近的对话记录有无敏感信息泄露，并全面扫描主机是否存在恶意软件。

8. 常见问题与排查技巧实录

在实际使用和推广这套脚本的过程中，我遇到并收集了一些典型问题。这里汇总成一份速查表，方便你遇到时快速解决。

我的个人避坑经验：在第一次对生产环境机器运行--apply之前，务必先在一台测试机或虚拟机里完整走一遍流程。权限修改是不可逆的（除非你提前备份了权限信息），脚本虽然设计了排除规则，但不同AI Agent的目录结构可能有细微差别。模拟运行（dry-run）输出的日志就是你最好的检查清单。另外，对于依赖AI Agent进行核心工作的用户，建议选择一个工作间隙（比如午休时）进行操作，以防万一需要回退而不影响工作。