自主智能体的入门流程，应从锁定的保险库开始

自主智能体应该分阶段获得访问权限。如果一开始就把生产令牌交给智能体，然后告诉它“要小心”，你就跳过了设置过程中最重要的一步。只有通过这一步，你才能了解控制措施在压力下会如何运行。

第一天的流程应该从一个拒绝一切操作的保险库开始，先执行一次低风险 HTTP 操作，再加入 SSH，最后为需要严格控制的凭据启用每次使用审批。在你还清楚记得这次运行时，验证审计记录。这个顺序很重要，因为每个阶段都能隔离一种不同的故障。

目标不是尽快让智能体发挥作用，而是准确了解它能做什么、哪些操作必须由你批准、它会记录什么，以及在把它连接到有实际后果的工作之前，如何让它停下来。

从拒绝一切操作的保险库开始

第一次成功测试应该是一次拒绝。即使智能体提出的请求完全合理，即使凭据已经配置好，一个锁定的保险库也必须拒绝智能体的操作。

只有当你看到智能体重试失败的操作时，这听起来才不再反常。智能体不会犹豫。工具报告访问不可用时，它可能改用另一个端点、修改参数、调用相关工具，或请求批准。你希望安全边界在任何凭据离开受保护存储之前就给出回应。

在 Mac 上，确保应用正在运行，但让保险库保持锁定。通过正常的开发流程启动智能体，并给它一个有意设置得无害的请求，例如从一个你尚未授权的 API 获取测试资源。

预期结果很简单：请求不会执行。不要通过把令牌粘贴到环境变量、 shell 配置文件、提示词、项目文件或智能体配置文件中来绕过拒绝。这样做会传达错误的经验，因为它把第一次测试变成了普通的密钥处理问题。

记下智能体报告的内容。你要检查以下三点：

• 智能体能通过 MCP 连接到操作网关。
• 保险库锁定时，保险库闸门会阻止操作。
• 智能体对话记录、终端输出或工具参数中都没有出现密钥。

区分“凭据不可用”和“保险库已锁定”很重要。凭据不可用通常说明设置出了问题。保险库锁定则表示设置正常，只是访问被有意关闭。如果你把这两种失败都理解成“令牌不能用”，最终可能会关闭原本保护你的控制措施。

Sallyport 把这作为决策阶梯中的第一道控制：保险库锁定时，所有操作都会被拒绝。在支持的 Mac 硬件上，保险库闸门使用 Secure Enclave 和 Touch ID，而不是要求智能体证明自己的身份。

连接智能体，但不要把密钥交给它

智能体需要的是一条操作路径，而不是一份凭据副本。这条原则能避免一次有用的自动化运行演变成失控的密钥分发事件。

配置支持 MCP 的智能体，使用内置的 stdio shim：

sp mcp

这个 shim 是一个普通的 MCP 服务器。智能体与它通信，请求执行 HTTP 或 SSH 操作，然后接收结果。凭据会留在应用内的加密保险库中。智能体不会收到明文令牌、替代令牌，也不会收到之后可能被滥用的类似密钥的占位符。

这比许多团队划出的边界更清晰。他们常说“智能体的访问权限有限”，实际意思却是智能体的环境中有一个权限有限的令牌。这是两种不同的系统。

使用环境变量时，任何能读取环境的进程都可能复制密钥。shell 历史记录、调试日志、崩溃报告、子进程、导出的提示词或粘贴过的终端记录，都可能延长密钥的存活时间。使用操作网关时，智能体可以请求特定操作，却无法查看用于授权该操作的凭据内容。

在解锁任何内容前，检查智能体配置中常见的泄露点：

• 从 .env 文件、 shell 启动文件、智能体指令和项目文档中删除令牌。
• 即使工具支持 token 字段，也不要仅仅因为这个原因把凭据加入工具参数。
• 不要允许智能体读取你试图保护的同一个密码管理器、密钥文件或云凭据目录。
• 第一次运行智能体时，不要让它与已加载高权限环境变量的终端会话共用环境。

开发者还经常给出一个流行却糟糕的建议：“先用临时令牌，之后再加固。”临时令牌一旦进入智能体上下文，仍然是密钥。可以使用影响范围有限的临时凭据，但不要把它当成放弃智能体与密钥之间边界的理由。

先完成一次普通的 HTTP 请求

第一次获准的操作应该是一次 HTTP 请求，并使用用途范围狭窄的凭据。最好是只读凭据，更好的是测试账户，最理想的是返回已知且不敏感对象的端点。

选择一个可以独立验证的请求。好的例子包括读取测试仓库的元数据、获取你创建的沙盒配置，或调用与非生产账户关联的状态端点。不要使用会列出真实客户、源代码、账单数据或大范围账户设置的端点。一次成功的读取仍可能泄露超出预期的信息。

按照服务要求的身份验证形式，在保险库中设置 HTTP 凭据：bearer 身份验证、basic 身份验证或自定义请求头。凭据标签要足够清晰，方便你稍后在审批卡中识别。“测试 API 读取”比“令牌 2”更好。未来的你不应该还要打开密码管理器，才能判断一次点击是否安全。

现在解锁保险库，并启动一个全新的智能体进程。默认情况下会启用按会话授权，因此新进程发出的第一次操作应该会显示审批卡。在批准前，阅读其中显示的代码签名机构。

不要把这项检查简化为“我认识这个智能体名称”。熟悉的命令名称可能由意外的包装器、复制的二进制文件或其他开发工具启动。审批卡首先显示进程的代码签名机构，因为请求访问的进程，比它声称正在执行的自然语言任务更重要。

只有在以下条件全部满足时，才批准运行：

1. 这是你亲自启动的智能体进程。
2. 签名身份与该进程的预期身份一致。
3. 请求使用的凭据范围正是你设定的范围。
4. 请求内容就是你要求智能体执行的操作。

然后让智能体恰好发起一次调用。将返回结果与你在智能体流程之外手动发出的请求进行比较。你不是在证明 HTTP 可以工作，而是在证明智能体可以请求操作、网关可以注入存储的凭据，并且结果可以返回，同时不会暴露凭据本身。

第一天的记录可以很简短：

Credential: Test API read
Agent task: Retrieve one known test object
Expected result: Object identifier and status only
Manual comparison: Same identifier and status
Unexpected data returned: None

如果响应中的字段比预期更多，就停在这里。不要让智能体总结多出来的数据后继续。缩小 API 范围，使用更小的测试对象，或选择范围更窄的端点。第一次 HTTP 调用应该通过控制范围建立信心，而不是靠结果看起来多么 impressive。

会话审批针对一次运行，不是空白支票

按会话授权回答的是一个具体问题：你是否批准这个智能体进程在本次运行期间执行操作？它并不意味着每个凭据或每个请求的操作都值得同样对待。

批准运行后，智能体可以在退出前发起多次调用。当你监督的是一个连贯的任务时，这很有用，例如读取测试元数据并生成本地报告。但如果运行包含开放式提示词、可以派生相关工作，或能访问后果不同的凭据，这就会带来风险。

把一次会话当成有边界的工作单元。为一个任务启动它，观察最初几次操作，任务完成后结束它。下一个不同的任务启动新的进程，这样你就能再次做出授权决定。

Sessions 日志应该支持这种习惯。它会记录智能体运行，你也可以立即撤销某次运行。当智能体开始偏离目标、你发现批准了错误的进程，或任务进行到一半改变了性质时，都可以使用撤销。

有一种失败模式值得注意。你要求智能体“检查测试 API，并修复任何明显的问题”。它先发出一次无害的 GET 请求。你批准了会话。它发现配置不匹配，看到可用操作中有一个写入端点，于是认为明显的修复方式是更新设置。凭据可能确实允许这样做，而最初的批准可能仍然覆盖整个运行。

这个故事不需要恶意智能体或损坏的工具。问题出在任务边界。你把发现阶段和修复阶段放进同一个会话，却期待最初的批准在两个阶段中都具有相同含义。

应该拆开处理。先批准一个只读的发现会话，查看它的发现结果。然后为建议的变更启动单独的运行，最好使用另一个写入权限更窄的凭据。当一次审批对应一个你能用一句话描述的工作单元时，审批才真正有意义。

等 HTTP 边界变得习以为常后，再加入 SSH

SSH 不是“用于服务器的 HTTP”。它带来的后果范围更大，因为一次成功的连接可以运行任意命令、检查文件、修改权限，并通过窄范围 API 不会暴露的通道传输数据。

从一次性主机或隔离的开发机器开始。创建一个没有生产访问权限、没有共享凭据，也没有理由接触主目录或云配置的远程账户。在该主机上放置一个包含已知文本行的无害文件。智能体的第一次 SSH 任务应该只获取这一行内容，不做其他事情。

Sallyport 通过内置的无状态 Go helper sp-ssh 路由 SSH 操作。智能体通过同一个网关模型请求操作，而存储的 SSH 凭据会留在保险库中，不会变成智能体可以读取的私钥文件。

第一次 SSH 练习应该有意设置得很窄：

Host: isolated development host
Remote account: restricted test account
Allowed task: Read one known text file
Expected response: The exact line placed in that file
Stop condition: Any attempt to inspect other paths or run a second command

不要从“运行诊断”开始。这个说法太宽泛。诊断通常意味着进程列表、网络配置、软件包清单、日志文件、主目录和应用配置。一个能力较强的智能体会广泛理解这个请求，因为广泛解释往往是它完成任务的方式。

注意一个常见的操作错误：开发者使用方便而不是安全的账户测试 SSH。这个账户可以访问熟悉的主机，也许还能通过现有的个人密钥访问，所以测试很快就能完成。随后，智能体的第一次 SSH 体验就包含了仓库、部署凭据、shell 历史记录、配置文件，以及该账户能够读取的其他内容。你只学到了隧道可以工作，却没有获得任何关于隔离效果的有用信息。

受限测试账户能让失败清晰可见。如果智能体请求访问意外路径，你可以在日志中看到尝试的操作，并拒绝或撤销，而不必担心它已经找到更敏感的文件。

对有实际后果的凭据启用逐次审批

逐次审批要求你确认某个凭据的每一次使用。在尝试那些能够改变系统、访问敏感资料，或连接到一次 shell 命令就可能造成广泛影响的主机之前，先启用这一设置。

开发者经常对此感到抗拒，因为反复出现的提示让人觉得低效。这个成本确实存在。低风险读取也每次弹出提示，会让你养成不阅读就点击的习惯。这就是审批疲劳，它会让控制措施变得比没有控制还糟，因为它制造了虚假的安全感。

在每次操作都需要人重新做决定的地方，使用逐次设置。适合的凭据包括能够：

• 创建、修改或删除远程资源；
• 读取个人、客户、财务或安全敏感记录；
• 调用管理 API 方法；
• 打开通往共享开发、预发布或接近生产环境机器的 SSH 访问；
• 触发部署、任务、工作流或外部通知。

在熟悉流程时，让低风险测试读取使用会话审批。下一次添加具有实际后果的凭据时，为它设置逐次闸门。然后给智能体一个需要两次独立调用的任务，例如读取测试设置并提出变更建议，但不要应用变更。确认凭据启用逐次设置后，你确实需要为每次使用单独审批。

这里的区别很重要。按会话审批询问的是某个进程是否可以在本次运行期间执行操作。逐次审批询问的是这个特定凭据现在是否可以使用。前者关注进程身份和运行时长，后者关注某个存储密钥所关联的后果。把它们混为一谈，会导致团队要么批准范围过大，要么频繁弹出提示，最后没有人真正阅读审批卡。

提示出现时，不要只检查凭据标签。检查操作、目标，以及智能体当前的任务是否仍然需要这次调用。如果不需要，拒绝使用，并要求智能体先用简单语言解释计划，再考虑批准其他操作。

活动日志会把意外变成证据

会话记录告诉你哪个智能体运行获得了批准。活动记录告诉你该运行内部发生了什么。两者都需要，因为一个看起来正常的进程仍可能做出错误决定，而一次可疑调用如果无法和触发它的运行关联起来，也很难判断意义。

完成 HTTP 测试后，打开 Activity 日志，逐条阅读每次调用。SSH 测试后也做同样的事。将记录和你写下的练习内容进行比较：预期的端点或主机、预期的操作以及预期的结果。你是在训练自己趁着不匹配还容易解释时发现它。

特别注意那些单独看起来无害、却不符合任务的调用。元数据端点可能暴露账户结构。主机探测可能引向更广泛的命令。一次重试可能无害，也可能说明智能体在第一次响应失败后修改了参数。上下文来自会话和调用顺序，而不是来自孤立查看的一行记录。

不要把智能体的叙述当作记录。智能体可能准确总结，也可能遗漏细节、误解工具响应，或为一个你不会批准的操作写出流畅的解释。日志是用来核对发生了什么，不是用来评估周围文字写得好不好。

这也是立即撤销发挥作用的地方。如果你看到智能体从约定任务转向探索，先撤销会话。停止后续操作，再判断这次调用是否无害。在会议中等待完整解释是合理的，但面对一个正在使用凭据的活跃进程，这不是好的应对方式。

在需要用它争论之前，先验证审计链

只有能够发现记录本身是否被篡改，审计记录才有用。阅读事件列表只能告诉你界面当前显示了什么。验证则能告诉你加密审计日志的哈希链是否仍然通过检查。

在前两次练习后执行：

sp audit verify

Sallyport 可以在密文上离线验证哈希链，因此这项检查不需要访问保险库密钥。调查期间，这个特性很实用。你可以检查记录完整性，而不必先解锁同一个控制智能体操作的存储空间。

在一切平静时先运行一次命令。记下变更、测试或事故中保存结果的位置。然后在一次有意拒绝的操作、一次获准的 HTTP 调用和一次获准的 SSH 调用后再次运行。你检查的是一组事件已知的序列，这会让之后更容易识别意外的验证结果。

不要等到出现严重的生产问题时，才发现谁能运行这个命令、日志存放在哪里，或团队是否了解会话记录与单次调用之间的区别。这是常见的失败方式。团队安装日志系统，相信它确实存在，直到有人问“是谁批准了这个？”才打开日志。那时他们不得不同时学习工具和还原事件。

审计日志来自一条不可读取的加密哈希链记录，并被投影到 Sessions 和 Activity 日志中。这样你可以获得两个用于操作的视图，同时又不会让这些视图成为唯一能够检查的证据。

让第一周比第一次演示更严格

一次漂亮的演示在 HTTP 请求成功时就结束了。一个可用的入门流程应该持续到你拒绝过一次操作、有边界地批准过一次运行、主动撤销过一次运行、检查过逐条调用、在隔离主机上测试过 SSH、使用过逐次审批，并验证过审计链。

第一周的范围要小到你能解释每一次操作。每次只添加一个新凭据或新能力。如果新的设置需要多个例外、宽泛的权限范围，以及一个你无法快速理解的提示，那它还没有准备好交给自主智能体。

实际测试很直接：智能体请求操作时，你能否说清楚是谁在请求、会使用哪个存储凭据、操作会发送给哪个外部系统，以及之后应该去哪里查看？如果任何一个答案含糊不清，就回到前一个阶段，缩小测试范围。

这比把令牌复制到配置文件中更慢。但只有这样，你才能避免在凌晨两点发现，第一次真正的智能体运行，正是凭据控制彻底失去控制作用的时刻。