你让 AI 代码代理控制无头服务器——在有用的同时，如果未决定其无人干预时可能执行什么，就很可怕。

你让一个 AI 代码代理控制无头服务器——在有用的同时，如果未决定其在无人干预时可能执行什么，就很可怕。本指南展示了具体规则：哪些可以直接允许、哪些需要明确的人类确认、如何限定令牌和会话范围，以及如何记录和约束代理活动，以防单个 bug 或恶意提示控制你的整套设备。

威胁模型与实用目标

首先明确你关心的风险。能够在无头主机上运行命令的 AI 代码代理可能会：修改代码、外传文件、安装软件、重新配置服务、打开网络连接并创建持久访问。我们假设代理是有用但易出错的——它可能因推理错误做出破坏性更改，或被精心构造的提示强迫执行不良操作。

安全部署的实用目标：

允许常见的开发任务（构建、测试、运行），无需反复人工干预。
对改变网络态势、安装持久性软件或暴露机密的操作要求人工确认。
尽可能使所有代理操作可审计且可逆。
通过主机层面的控制（容器、资源限制、网络白名单）限制代理的影响范围。

能力：代码代理通常需要什么

列出代理日常可能需要的能力，以便将每项映射到策略决策：

读取仓库文件（源代码、测试、配置）。
运行测试与 linter、构建产物、运行容器。
编辑源文件并提交变更到分支。
打包并上传产物到内部注册表。
重启服务、运行迁移或部署到预发布环境。
执行诊断命令（ps、netstat、df、journalctl）。

每项能力应映射为允许动作、受限动作，或需人工批准的动作。

策略：允许、确认与拒绝（具体建议）

保持策略简单且以角色为中心。下文为可适配的实用策略矩阵。经验法则：自动化、只读和短寿命的计算可以允许。持久性更改、网络暴露、机密访问与权限提升需要人工批准。

操作	推荐默认	原因
运行测试、linter、单元套件	允许	对仓库只读；快速且可逆
编辑文件并在特性分支创建提交	允许（仅限分支）	在合并前经过代码审查较为安全
推送到受保护分支、合并到 main	需要人工确认	影响范围大；对发布进行把关
全局安装软件包或添加系统服务	需要人工确认	安装在重启后仍然存在并扩大攻击面
打开入站网络端口 / 修改防火墙	需要人工确认（多重审批）	改变网络暴露情况
读取机密（密码、密钥）	默认拒绝；必要时提供受限的临时凭证	机密不应对无人看管的代理可见
将产物上传到外部注册表	确认目的地与凭证	防止意外公开泄露
以 root / sudo 执行	需要人工确认（默认拒绝）	权限提升是最高风险动作

令牌、凭证与机密处理

永远不要向代理授予长期、广范围的凭证。使用最小权限的短期令牌，并采用可审计的签发模式。

通过审批服务签发短期令牌。令牌有效期为几分钟，与单个作业/会话绑定。
将令牌范围限定得尽可能窄：repository:read、registry:upload:staging、service:restart:staging 等。
不要向代理暴露私钥或 vault 根令牌。相反，应按需从保险库签发临时凭证并记录每次签发。
在可疑活动时轮换或撤销。若代理重复尝试被拒绝的操作，应自动撤销凭证。

隔离：如何在主机上运行代理

在限制其可触及范围的环境中运行代理。以下为实用隔离策略，按隔离程度从低到高排序：

使用 chroot 或用户命名空间并严格挂载文件系统。只给代理仓库树和最小的临时目录。
将执行容器化：在临时容器（OCI）内运行代理作业。限制能力，仅挂载必要卷，并移除 NET_ADMIN 权限。
临时 VM 镜像：对于高风险操作，在一次性 VM 中运行，并在作业完成后销毁。
网络出站白名单：仅允许代理对必要主机（例如包注册表）出站，默认阻止其他所有流量。
资源上限：限制 CPU、内存和磁盘配额，防止构建失控导致 DoS。

降低重建与重启的成本。如果你的隔离依赖临时 VM 或容器，在事件响应计划中演练销毁与重新配置。

审批用户体验：实用的人类确认流程

人工确认是策略与产品的交汇点。保持确认流程快速以减少摩擦，但要足够明确以让审批者理解风险。

代理请求一个具名动作：例如“在 staging 上安装包 xglob@1.2.3”或“将分支 feature/ai-fix 合并到 main”。
请求包含简要说明和差异或命令预览。展示受影响的文件、网络规则以及将使用的凭证。
对低风险操作（非 root 的预发布部署）要求单人审批。对高风险操作（root 安装、防火墙更改）要求两名审批者或值班工程师。
带有身份的时间戳批准（2FA 会话或 SSO 令牌）及可选评论。
批准会签发一个时限令牌，代理必须在短时间窗口内使用该令牌（例如 10 分钟）。

审计、可观测性与事后控制

尽可能让每个代理操作可见且可逆。良好的审计与可观测性可缩短检测平均时间并加速恢复。

记录每个执行步骤的完整命令文本、环境与工作目录。
捕获任何文件变更的差异并将其存储在追加式审计日志中。
记录签发了哪些令牌、签发对象与原因；撤销与可疑活动相关的令牌。
将会话输出流到日志后端（按事件保留期保存）。避免以明文保存敏感输出；将日志视为可能敏感。
在可行时自动回滚：存储产物快照以及 Terraform/Ansible 计划，以便快速撤销部署。

为合规与取证，还应包含身份绑定：将代理请求与触发它们的用户或服务关联（网页 UI 点击、webhook 身份或调度器作业 id）。

示例策略 JSON（最小、真实场景）

{
  "policy_name": "ai-agent-ci-policy",
  "defaults": {
    "allow_tests": true,
    "allow_branch_commits": true,
    "allow_protected_branch_push": false,
    "require_human_for_install": true,
    "require_human_for_sudo": true,
    "allow_secret_read": false
  },
  "scopes": [
    { "name": "repo:read", "duration_minutes": 60 },
    { "name": "repo:write:feature-branch", "duration_minutes": 10 }
  ],
  "approval": {
    "low_risk": { "approvers": 1, "token_ttl_minutes": 10 },
    "high_risk": { "approvers": 2, "token_ttl_minutes": 5 }
  }
}

何时自建中继与何时使用托管中继

远程会话路由很重要，因为许多代理操作会通过中继到达无头服务器（NAT 穿透、防火墙绕过）。Tenvo 的托管中继是推荐的默认选项：它提供多区域故障切换、带每台设备证书的 TLS，以及生产级的中继网络——免费 $0 / Lite $2.99/mo / Pro $7.99/mo。除非你有书面要求自建中继（严格的数据驻留规则、隔离网络或合规性要求禁止第三方基础设施），否则使用托管中继。

重要安全事实：TLS 在中继处终止。直接点对点连接在主机间是端到端的，但当流量回落到中继时，中继会终止 TLS，因此可以观察会话流量。在设计策略与信任边界时考虑这一点。如果你无法接受，应自建中继，并在决策中包含其运营成本（补丁、证书续期、值班）。

投入使用前的运营检查清单

定义简明的策略矩阵（允许/确认/拒绝）并发布给团队。
实现临时凭证签发并设置短令牌 TTL。
将代理运行容器化并强制执行网络出站白名单。
实现审批流程，签发短期令牌并记录审批者身份。
启用全面审计日志并根据合规需求保留日志。
演练撤销与回滚：模拟恶意代理并实践隔离措施。

延伸阅读与相关主题

如果你想了解此设置在远程访问方面的更深入背景，请阅读 Tenvo 关于代理控制和安全的文章。关于 AI 代理控制桌面的策略与工具，请参阅 ai agent remote desktop：策略、审批、审计。关于基础的远程访问威胁模型，请阅读远程桌面安全吗？一个诚实的威胁模型。要设计可审计的会话轨迹，请查看远程桌面审计日志。

这些基于实用的远程访问基础——如果你需要快速的无头主机连接指南，我们的 60 秒远程访问设置指南是快速入门。

最后说明

让 AI 代码代理控制服务器很强大。恰当的默认设置能在不增加危险的前提下提高生产力：允许临时的、以读取为先的操作；将持久化和权限变更操作置于人工批准之下；使用短期凭证；在受限环境中运行代理；并记录一切。除非你有具体的书面自建中继要求，否则优先使用 Tenvo 的托管中继。规划撤销并演练事件——隔离是一个运营能力，而不是一个勾选项。

AI 代码代理远程服务器：安全控制策略