我跑了一下Perplexity开源的Mac安全扫描工具，然后默默关掉了咖啡馆的WiFi

我知道你的Mac里是什么样的。

Ollama跑着本地模型，Jupyter Notebook开着，.env文件里散落着OpenAI、Claude、Gemini的API Key，SSH密钥连着三四个远程服务器，~/.zshrc里还有几行当初为了"方便"临时加的环境变量——然后就再也没动过。

我也是这样。直到我跑了Bumblebee，看到那几行红色输出，才意识到自己的Mac在某些场景下，和一扇开着的门没什么区别。

Bumblebee是什么？为什么Perplexity要开源它

Bumblebee是Perplexity AI内部安全团队开发的macOS合规检测工具，最初用于检查员工的Mac是否满足公司安全基线。开源之后，因为精准命中了AI开发者群体的痛点，在开发者社区引发了不小的关注。

它的设计哲学很简单：本地扫描、不上传任何数据、基于macOS原生API。

这三点很重要，因为"用一个安全工具，结果这个工具本身不安全"是很多人的第一层顾虑。Bumblebee的代码完全开源，你可以自己审计，它的所有检测都在本地完成，不会往外发任何东西。

安装非常简单，一行命令搞定：

# 通过 Homebrew 安装（推荐）
brew install perplexity-ai/tap/bumblebee

或者直接 clone 源码运行
git clone https://github.com/perplexity-ai/bumblebee.git
cd bumblebee
./bumblebee scan

安装完成后运行：

bumblebee scan

整个扫描过程大概30秒，然后你会得到一份颜色分级的报告。

实测过程：那几行红色输出

第一次运行的时候，我以为自己的配置还不错。平时也算注意安全，SSH用密钥不用密码，防火墙应该开着……应该。

终端输出大概是这个样子：

Bumblebee Security Scanner v0.4.1
Scanning system configuration...

[✓] FileVault disk encryption: ENABLED
[✓] Screen lock timeout: 5 minutes (within policy)
[⚠] Automatic software updates: DISABLED
[✗] macOS Firewall: DISABLED
[✗] SSH Agent Forwarding: ENABLED globally
[✗] SIP (System Integrity Protection): DISABLED
[⚠] Open network services detected:
- 0.0.0.0:11434 (ollama)
- 0.0.0.0:8888  (jupyter)
[⚠] SSH key permissions: ~/.ssh/id_rsa (644) - should be 600

Summary: 3 critical issues, 3 warnings
Run 'bumblebee fix --guide' for remediation steps

三个红叉。防火墙是关的——我完全不记得自己什么时候关掉的，大概是某次装什么工具的时候顺手关了。SIP是关的——我想起来了，为了跑一个需要修改系统目录的本地模型工具，关掉了，然后忘记开回来。SSH Agent Forwarding全局开启——这个我以为是正常配置。

然后我看到了那两行黄色警告：0.0.0.0:11434和0.0.0.0:8888。

我当时正在咖啡馆。

对AI开发者最致命的3个检测项

检测项①：SSH密钥权限与Agent Forwarding配置

很多开发者为了方便，会在~/.ssh/config里全局开启Agent Forwarding：

Host *
ForwardAgent yes

这行配置的意思是：当你SSH到任何一台服务器时，你的本地SSH私钥会被"转发"到那台服务器上，让你可以从那台服务器继续SSH到其他地方，不用重新输密码。

听起来很方便，但风险在于：如果你连接的那台服务器被攻击者控制，他们可以通过你转发过去的Agent，以你的身份访问你所有其他的服务器——你的GitHub、你的云服务器、你的CI/CD系统。

更危险的场景是：现在很多AI工具会让你安装各种依赖，供应链攻击的风险真实存在。一个恶意的npm包或者pip包，如果能在你的机器上执行代码，配合开着的Agent Forwarding，私钥实际上就暴露了。

SSH密钥文件权限过于宽松也是同类问题。644权限意味着其他用户可以读取你的私钥文件，正确的权限应该是600。

# 修复SSH密钥权限
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_ed25519  # 如果你用的是ed25519密钥

在 ~/.ssh/config 中关闭全局Agent Forwarding
只对需要的特定主机开启

正确的~/.ssh/config写法：

# 默认关闭 Agent Forwarding
Host *
ForwardAgent no

只对特定的跳板机开启
Host bastion.example.com
ForwardAgent yes

检测项②：本地HTTP服务的端口暴露（Ollama/LM Studio/Jupyter）

这是让我当场关掉咖啡馆WiFi的那一项。

Ollama默认监听0.0.0.0:11434，这意味着它不只是监听本地回环地址127.0.0.1，而是监听所有网络接口。在家里的路由器后面，这通常没问题，因为路由器的NAT会挡住外部访问。

但在咖啡馆的公共WiFi下，你和其他所有人在同一个局域网里。一个在同一网段的人，可以直接访问192.168.1.xxx:11434，调用你的本地模型API——完全不需要任何认证。

攻击路径并不复杂：扫描局域网内的11434端口，找到开着Ollama的机器，发送API请求，不仅可以免费用你的模型，还可以通过精心构造的prompt尝试提取你的系统信息。Jupyter Notebook的8888端口更危险——默认配置下，访问Jupyter就等于可以在你的机器上执行任意Python代码。

关于Ollama端口暴露的问题，在GitHub和Reddit的AI开发者社区里有大量讨论，这不是小概率事件，而是几乎所有跑本地模型的开发者都会踩的坑。

# 让Ollama只监听本地回环地址
在 ~/.zshrc 或 ~/.bashrc 中添加：
export OLLAMA_HOST=127.0.0.1

重启Ollama服务
ollama stop
ollama serve &

Jupyter Notebook同样设置只监听本地
jupyter notebook --ip=127.0.0.1

检测项③：macOS防火墙状态 + SIP是否被关闭

这两项是Bumblebee会直接标红的最高危配置。

为了跑某些本地模型工具、破解软件或者有特殊需求的开发工具而关闭SIP的开发者不在少数。问题是，很多人关掉之后就忘了，机器一直在这个高危状态下运行。

# 开启 macOS 防火墙（命令行方式）
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

验证防火墙状态
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

重新开启 SIP 需要进入恢复模式：
1. 关机
2. Apple Silicon: 长按电源键进入恢复模式
   Intel Mac: Command+R 开机进入恢复模式
3. 打开终端，运行：
csrutil enable
4. 重启

局限性与替代方案

客观说，Bumblebee不是万能的。它是一个合规检查工具，不是杀毒软件，也不是入侵检测系统。

它能告诉你"防火墙关了"，但不能告诉你"有没有恶意进程正在运行"。它能发现"端口暴露了"，但不能分析"这个端口上的流量是否异常"。

简单说：Bumblebee适合作为AI开发者的"日常体检"，而非"急诊手术"。如果你需要更深度的安全审计，Lynis是个好选择；如果你想做持续的安全监控，osquery更专业，但上手成本也更高。

对于大多数AI开发者来说，Bumblebee已经足够——它覆盖的那几个检测项，恰恰是这个群体最容易忽视、也最容易被利用的配置问题。

修复行动清单

跑完扫描，别只是看看就算了。把下面这些命令收藏起来，对照自己的扫描结果逐项处理：

# ① 修复SSH密钥权限
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

② 关闭Ollama的全网监听（加入 ~/.zshrc）
echo 'export OLLAMA_HOST=127.0.0.1' >> ~/.zshrc
source ~/.zshrc

③ 开启macOS防火墙
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

④ 检查当前所有监听端口（排查是否有意外暴露的服务）
sudo lsof -iTCP -sTCP:LISTEN -n -P

⑤ 检查SIP状态
csrutil status

修复SSH配置，把~/.ssh/config里的全局ForwardAgent yes改成只针对特定主机。重启Ollama，确认它只监听127.0.0.1。开防火墙，如果SIP是关的，找一个时间重启进恢复模式把它打开。

这些操作加起来不超过15分钟，但能把你的安全基线拉高一个量级。

⚠️ 关于SIP：重新开启SIP之后，之前依赖关闭SIP才能运行的工具可能会失效。建议先确认哪些工具有这个依赖，再决定是否开启。大多数正规的本地模型工具不需要关闭SIP。

安全不是偏执，是习惯。跑一次Bumblebee花5分钟，但管好你的API Key是每天的事。

说到API Key管理：如果你同时在用OpenAI、Claude、Gemini多个服务，Key分散在各处本身就是安全隐患——.env文件里的Key越多，泄漏的攻击面就越大。

💡 推荐用统一的API中转层来管理调用：[api.884819.xyz](https://api.884819.xyz) 支持GPT、Claude、Gemini、Deepseek等多模型统一入口，一个Key管所有服务，配合今天说的本地安全配置，才算真正把风险降下来。国产模型（Deepseek、通义千问等）完全免费，新用户注册即送体验token，按量付费，没有月租。

最后说一句：今天聊的这些，本质上都是本地配置层面的安全问题——端口、权限、防火墙，这些你能看见、能修复。

但还有一类风险更隐蔽：你用Cursor或GitHub Copilot写代码时，你的代码片段到底被发送到哪里、在服务器上存了多久、谁有权限访问？ 这件事比Ollama端口暴露更难察觉，也更难修复，因为你根本不知道数据在哪。

下期我会把这个问题拆开来讲——关注我，下周见。

#AI安全 #macOS #Ollama #开发者工具 #本地大模型 #API安全 #8848AI #信息安全