emisar：给 AI 工具的「生产环境安全阀」

AndrewDryga/emisar 项目核心架构图

一句话概括

emisar 是一个 MCP（Model Context Protocol）服务器，它让 AI Agent 在不获得 SSH 权限的前提下，安全、受控地执行云端基础设施操作——策略决定谁能跑什么，Runner 在主机侧二次验证后才放行。

背景：为什么需要 emisar？

2025 年开始，AI Coding Agent（如 Claude Code、Cursor、Codex）逐步从「写代码」进化到「自己部署代码」。但当前的 agent 工具普遍面临一个根本矛盾：

AI 工具的权限过大。 一个有 shell 访问权的 agent，理论上可以做任何事——删库、执行破坏性命令、泄露密钥。传统的 API Key 授权又过于粗粒度，无法区分「读取配置」和「删除生产数据库」两种操作。

安全团队头疼的是：既要给 agent 开权限让它干活，又不能让 agent 变成随时可能引爆的「定时炸弹」。这正是 emisar 诞生的背景。

作者 Andrew Dryga 曾在多个大型基础设施项目中遇到类似困境：Claude 可以帮开发者写 Terraform，但 Terraform apply 一旦执行就是真实生产环境——没有审计、没有审批、没有回滚保证。emisar 的设计目标，就是把「AI 执行力」和「生产安全」解耦，让 AI 做它擅长的事（分析、生成、诊断），但把关键操作的决定权还给人类或自动化策略引擎。

核心原理：动作包（Action Pack）契约机制

emisar 采用了「声明式动作包」设计——这是项目最核心的安全机制。

传统方式： 给 agent 一个 shell，agent 自己拼命令执行。
emisar 方式： agent 只能从「动作包目录」里选择动作，动作包严格定义了：

• executable：实际执行的可执行文件路径
• argv shape：参数格式和类型（JSON Schema 校验）
• risk：操作风险等级（低/中/高/严重）
• timeout：超时时间
• output limits：输出流大小限制
• redaction：输出脱敏规则（如隐藏密钥、IP）
• side-effect description：副作用说明

也就是说，agent 不是在「执行命令」，而是在「调用一个经过打包、验证、审计的 action」。Runner 在执行前会重新计算 pack 的哈希值，确保磁盘上的动作包与控制面注册的一致——防止运行时被篡改。

项目内置了 80+ 官方动作包，覆盖：

• AWS 生态：EC2、IAM、RDS、S3、CloudWatch、成本查询
• 数据库：PostgreSQL、MySQL、MongoDB、Redis、Cassandra、ClickHouse
• 容器：Docker、Podman、Kubernetes
• 网络：Nginx、Caddy、HAProxy、Traefik、Cloudflare、Firewalld
• IaC：Terraform（只读）、Pulumi
• 系统：systemd 深度管理、ZFS、Prometheus、Grafana

用户也可以自定义动作包，发布到私有注册表，但新 pack 必须经过信任审批流程才能在生产 Runner 上运行。

技术架构：三层分离设计

emisar 的代码库分为三个独立子项目，清晰分离了职责：

子项目	语言	职责
portal/	Elixir/Phoenix	控制平面、Web 管理界面、MCP API、Operator Console
runner/	Go	主机侧 Runner、CLI、action 执行引擎、本地审计日志
mcp/	Go	MCP Bridge：将 stdio MCP 协议转换为 HTTP/WebSocket 与控制面通信

关键架构决策——Runner 不开入站端口。 传统远程执行方案（如 SSH）需要开放 22 端口，被攻击面巨大。emisar Runner 采用 outbound-only 模式：Runner 主动向控制面建立 TLS WebSocket 连接，控制面通过这个通道推送指令。这意味着主机不需要开放任何入站端口，大幅缩小攻击面。

控制面（portal）部署在 Google Cloud Platform，托管在 infra/ 目录下的 Terraform 配置中。生产环境使用 PostgreSQL + Phoenix 运行时 + Keycloak 做身份认证。

安全模型：六层防线

emisar 文档中明确列出了它的安全边界（以及它不是什么）：

1. 入站端口 0：Runner 不监听任何端口，攻击者无法主动连接主机
2. 声明式动作：agent 输入被限制在 schema 校验的参数范围内，无法注入任意命令
3. 内容寻址包：控制面注册可信 pack 哈希，Runner 运行时二次校验，防止供应链攻击
4. 策略优先：Scope、风险策略、覆盖规则在执行前全部评估
5. Runner 侧执行限制：Runner 强制执行超时、内存限制、输出截断和内容脱敏
6. 双记录审计：控制面记录所有请求（含拒绝和待审批），Runner 写哈希链 JSONL 本地日志

项目也诚实说明了安全边界：emisar 不是沙箱，不是进程隔离工具，不能替代 OS 最小权限原则。对于真正危险的 destructive action，安全边界取决于动作包质量、策略配置和主机权限管理。

使用体验：接入有多简单？

用户只需三步就能让 AI 工具连接到自己的服务器：

1. 在 emisar.dev 注册账号，在 Dashboard 点击「Connect a runner」生成注册命令
2. 在目标 Linux 主机执行一条安装命令（curl 管道到 bash，支持 systemd）
3. 在 Claude Desktop / Cursor / Codex 等 MCP 客户端配置 emisar MCP 地址

安装脚本会自动：验证 Release 校验和、创建 systemd 服务、安装主机匹配的动作包。整个过程不需要开放防火墙端口，不需要手动配置 SSH Key。

许可证与开源范围

emisar 采用双许可证设计，这是该项目一个值得注意的细节：

• runner/、mcp/、packs/：Apache License 2.0——这三个是核心的开源组件
• portal/ 和其他：Business Source License 1.1——控制面是源码可用但非开源
• 商业使用需要联系 licensing@emisar.dev 获取商业许可

这意味着用户可以自由部署和修改 Runner 和动作包，但不能 fork 控制面。对于大多数场景来说这足够用——控制面可以看作是一个 SaaS 平台，你付费（或免费用基础版）换取托管的策略引擎和审计功能。

局限与争议

1. 控制面是闭源的：核心的策略评估引擎不开源，用户无法完全自托管完整系统
2. 需要 emisar.dev 账号：即使是 self-hosted Runner，也需要连接到官方控制面——不适用于完全离线的环境
3. 不是进程隔离：危险动作包的权限控制依赖主机 OS 权限体系，绕过不了 root
4. 动作包质量参差：官方包的安全边界需要持续人工审核，恶意或错误包可能造成危害
5. MCP 生态锁定：目前只支持 MCP 协议的客户端，其他协议（如 LangChain Tool）需要额外桥接

行业意义

emisar 代表了一个重要趋势：AI Agent 的安全执行基础设施。随着 AI Coding 工具逐步从「辅助开发」走向「自主部署」，如何在不牺牲安全性的前提下释放 AI 的执行力，成为工程团队必须面对的问题。

传统的最小权限原则（Principle of Least Privilege）和 AI Agent 的灵活性需求之间存在天然张力。emisar 的解法是引入「策略中间层」——不直接给 agent 权限，而是给 agent 一个受限的能力目录，由策略引擎决定每个请求的命运。

从 GitHub Star 增长趋势看（471 ★，活跃维护），这个方向确实击中了真实痛点。随着 MCP 生态的扩大，类似的「AI 基础设施安全工具」赛道预计会持续火热。