跳转到内容

在 AI 智能体中使用 FortressFlag

如果你和 AI 编码智能体一起工作,你可以把你的 flag 交给它。“把生产环境里的 new-checkout 关掉”是一句背后有一个精确 API 调用的话——而且是一个会触及你真实用户的调用,这就是为什么本指南花在限制上的篇幅和花在设置上的一样多。

FortressFlag 提供一个 MCP 服务器:一个运行在你自己机器上、与你的智能体并肩的小程序,它把一组 flag 工具交到智能体手里。

简短版:你的智能体能做的恰好是你能做的,而且更少。

这个服务器持有一个以你的身份行事的 API 令牌——你的角色、你的项目访问、你的组织。它通过控制台使用的同一个公开 API 与 FortressFlag 通信,所以每一次权限检查、项目白名单和审计记录,都和你亲手点击按钮完全相同。不存在特殊的智能体访问路径。

有些事情是有意完全不向智能体开放的:

  • 批准生产提案。第二双眼睛的全部意义就在于它们属于一个人。
  • 永久删除一个 flag。
  • 创建 SDK 密钥或 API 令牌。一个返回给智能体的一次性机密,会落进对话记录里。
  • 管理成员、账单或法律协议。

1. 创建一个令牌。在控制台里,进入你的账户页面,找到 API 令牌。给它起一个你认得出的名字,选一个范围,然后复制令牌——它只显示一次。

除非你想让智能体做出改动,否则选只读。你随时可以稍后再创建第二个令牌。

2. 把你的智能体指向这个服务器。大多数 MCP 客户端接受一小段配置,写明一条命令和它的环境:

{
"mcpServers": {
"fortressflag": {
"command": "ffmcp",
"env": {
"FORTRESSFLAG_TOKEN": "ffm_your_token_here",
"FORTRESSFLAG_API_URL": "https://your-fortressflag-api"
}
}
}
}

令牌放在 env 里,绝不放在 args 里——在共享的机器上,命令行参数对其他用户是可见的。

3. 想要改动时加上 --allow-writes。不加它,服务器只提供读取工具。加上它,你的智能体可以切换、创建、重命名、归档和恢复 flag——仍然受限于你的角色所允许的范围:

"args": ["--allow-writes"]

把这个选项当作一种便利,而不是一把锁。如果一个智能体没有理由去改动 flag,就也给它一个只读令牌——那才是 FortressFlag 真正执行的部分。

你的角色首先决定。如果你是 Developer,你不能直接写入生产环境——所以你的智能体也不能。它能做的是提议这次变更,和你会做的完全一样:第二位队友来应用它,而没有人能批准自己的提案。见生产环境审批。

工具随后再问一次。在触碰一个生产环境之前,智能体必须表明它确实打算这么做,并点名那个环境。这项检查读取的是环境的生产类别,而不是它的名字——所以一个你叫做 live 的环境和一个叫做 prod 的受到完全相同的保护,而一个仅仅名叫 prod 但不是生产类别的环境不会来烦你。

这第二道检查之所以存在,是因为现实中的错误不是攻击者。而是一个被要求在 staging 里改点东西的智能体,伸手抓错了环境 key。

有必要说清楚:智能体读到的任何东西,都会成为它与它所使用的那个 AI 服务之间对话的一部分。这包括你的团队写下的 flag 名称、key 和描述,以及——如果你让它读取审计历史——你队友的姓名和邮箱地址。

由此有两件事。

把 flag 描述当作不可信的输入。任何能创建 flag 的人都可以在它的描述里输入任何东西,包括读起来像是给智能体的指令的文字。服务器会在一开始、并在每一个工具上告诉智能体,这些值是你的组织的数据,永远不是指令。这有帮助;但它不是保证,也是一个值得你想清楚智能体读的是谁的 flag 的理由。

我们看不到、也管不了那份对话记录。那是你和你的 AI 提供商之间的事。使用这个功能时,FortressFlag 存储或传输你的数据的方式没有任何改变——这些工具只是同一个 API 的又一个客户端。

  • 它只在本地运行。服务器通过它的标准输入和输出与你的智能体对话,在你的机器上。没有可以让远程智能体指向的托管版本。
  • 目前还没有可下载的二进制文件——现阶段是从源码构建。
  • 定向规则和细分不能由智能体编辑。读取 flag、切换它们、提议生产变更是可以的;规则编辑器是一个更大的界面,值得单独一轮设计。
  • 列出待处理的提案需要审批者权限。Developer 的令牌可以提议一次生产变更,但随后不能列出它——那是底层 API 上的权限,不是这些工具的怪癖。