AI Agent 要帮你部署应用时，最尴尬的问题经常不是“它会不会写命令”，而是“它应该怎么登录”。
一个看起来很顺手的答案是：让 agent 跑 appaloft login，打开浏览器，复制验证码，或者从本机拿到某个 cookie，再继续部署。这个流程在 demo 里很像魔法。到了真实控制面里，它会把身份、权限和审计都搅在一起。
Appaloft 的判断更保守一点：人类可以用 browser login，CI 可以用环境里的 scoped token，AI agent 需要的是一次明确授权的 token handoff。Agent 不应该假装自己是坐在浏览器前的人。
这篇接着 Skill 不是 MCP 往下说认证边界。MCP、CLI、Web 和 API 可以是不同入口，但它们不应该让 agent 得到一条绕过产品权限模型的捷径。
三种调用者，不该共用一种登录姿势
Appaloft CLI 同时服务三类人和系统。
第一类是真人 operator。这个人坐在自己的机器前，知道自己要登录哪个控制面，也能在浏览器里确认账号。对这种场景，appaloft login 或 appaloft auth login 的 browser/auth-session flow 是合理的：CLI 打印登录 URL 和 user code，用户在可信浏览器里确认，CLI 再交换 credential 并写入本机 profile。
第二类是 CI 和 automation。GitHub Actions、部署流水线、定时任务不应该弹浏览器。它们应该从 secret manager 或环境变量拿到 scoped token，例如 APPALOFT_TOKEN，然后用这个 token 调 CLI 或 API。权限不足时，命令应该在 mutation 前失败，而不是让 pipeline 去找人补一次浏览器登录。
第三类是 AI agent。它介于两者之间：不像 CI 那样总是预先配置好 secret，也不像真人那样应该控制浏览器。Agent 可能运行在用户机器、远程 sandbox、IDE、桌面 app 或 hosted runtime 里。它需要权限，但这个权限应该由人类在可信界面里授予，并且范围、时长、用途都能看见。
把这三类调用者放进同一个 browser login 流程，会让边界变模糊。尤其是 agent：它越像“替你操作浏览器的人”，产品越难解释到底是谁授权了什么。
Cookie 是兼容路径，不是 agent 指南
很多 CLI 在早期都会留下兼容入口：环境变量、cookie、临时 session、手工 bearer。Appaloft 也支持过 APPALOFT_AUTH_COOKIE 这种本机 trusted operator path，用来兼容已经存在的 product-session credential。
问题不在于代码能不能识别 cookie，而在于文档和 skill 会不会把它教成正常操作。
一旦 agent-facing 指南写成“没有 profile 就去拿 cookie”，后果很难收拾：
- agent 可能尝试读取浏览器存储或 shell history
- 用户可能把 product-session cookie 贴进聊天或 issue
- cookie 的权限通常比一次部署任务需要的更大
- 失效、撤销、审计和归属会变得含糊
- 日志、截图、fixture、PR 描述里更容易出现 credential
所以 Appaloft 把 cookie path 降级成 legacy 或 diagnostic compatibility，而不是 AI/CI 的默认认证方式。Agent 可以检查本机是否已经有可用 profile，也可以使用环境里明确提供的 token；它不应该去挖浏览器状态。
Agent token handoff 的目标
更好的形状不是“agent 自动登录”，而是“人类把一把刚好够用的钥匙交给 agent”。
在 Appaloft 里，这个路径可以拆成几个动作：
- Agent 先读当前状态：
appaloft auth status和appaloft context show。 - 如果已经有可用 profile 或
APPALOFT_TOKEN，继续使用已有 credential。 - 如果没有，agent 停下来，请用户通过 Cloud UI、secret manager 或其他可信入口授权一个 scoped token。
- CLI 通过明确支持的 token import flow 使用它，例如
appaloft auth token login或环境变量。 - CLI 做 endpoint handshake、current context 和 scope readback，只输出脱敏信息。
- 后续所有部署、观测、恢复操作仍然走 operation catalog、CommandBus/QueryBus、authz、audit 和 redaction。
这里的重点不是命令名字本身。重点是 token handoff 要有产品语义：它是给 agent 或 automation 的非交互凭据，不是浏览器会话的替身。
一个 agent token 至少应该能回答这些问题：它属于哪个 organization 或 project？能读什么、写什么？能不能部署、回滚、看日志、改资源配置、管理域名？什么时候过期？最后一次使用是什么时候？谁创建的？能在哪里撤销？
完整的 scope/expiry/readback/revoke/audit UI 需要继续打磨。我们不想把这件事写成已经完全结束的能力。但方向很清楚：agent 需要更小、更短、更可解释的权限，而不是更隐蔽的登录方式。
MCP 也不应该绕过认证模型
MCP 经常让认证问题看起来像 transport 问题：只要工具能连上 server，agent 就能调用。真实系统里这不够。
一个 remote MCP gateway 和一个 CLI 命令一样，都应该回答同样的问题：当前 actor 是谁？属于哪个 tenant？有什么 capability？这次 tool call 是 read 还是 write？是否需要 plan-first？审计记录在哪里？secret 怎么脱敏？
Appaloft 的 hosted MCP 路径不应该拥有一套 MCP-only 权限。MCP tool 仍然映射到 operation catalog，dispatch 仍然落到同一套 command/query boundary。Cloud 可以在这一层加 team permission、entitlement、tenant context、audit 和 policy，但不能因为调用方是 agent 就发明一个私有捷径。
这也是为什么 auth mcp login 这类流程要被理解成“为 MCP profile 获取受控 bearer material”，而不是“让 agent 控制用户浏览器”。人类可以完成授权；agent 使用被授权后的工具入口。两件事最好不要混在一起。
为什么不让 agent 跑 browser login
有人会问：如果用户就在旁边，为什么不能让 agent 执行 appaloft login --no-browser，把 URL 给用户打开，或者复制 user code？
有些 terminal-only 场景里，这对真人 operator 是有用的。它不应该成为 AI agent 的默认路径。
原因不是形式主义。Browser login 的交互语义是“这个人正在用这个浏览器确认这个账号”。Agent 介入以后，聊天窗口、terminal、浏览器、CLI profile、远程 sandbox 之间的责任关系会变得很乱。一次授权到底是给真人当前会话，给本机 CLI，给 agent，还是给以后所有命令？用户可能没有机会看清楚。
Token handoff 则可以把这个问题摊开：这是给 agent 的 token；它有这些 scopes；它会在这个时间过期；它可以被撤销；它的使用会被记录；原始 token 只显示一次，不应该出现在聊天、日志或截图里。
少一点魔法，多一点可撤销性。对部署控制面来说，这是好交易。
认证之后，仍然要 plan-first
拿到 credential 不等于可以直接执行。
Agent 的操作顺序仍然应该是：先识别 project、environment、resource、server 或 Blueprint；会创建或修改持久状态时先生成 plan；展示缺失 secret、权限和外部资源影响；再由用户或策略接受；执行后通过 events、logs、health checks、diagnostics 和 access readback 观察结果。
认证只解决“你是谁、能做什么”。它不解决“现在应该不应该做”。这两个问题分开，agent 才不会因为拿到了 token 就变成一段到处 apply 的脚本。
这个边界也让撤销更清楚。auth logout 可以只是删除本机 profile；token revoke 才是服务端撤销。部署失败可以 retry 或 rollback；权限过大可以 rotate 或 revoke。每个动作有自己的语义，审计记录也更容易读。
我们想要的默认行为
Appaloft 给 AI agent 的默认认证规则可以很短：
- 先检查
appaloft auth status、appaloft context show和APPALOFT_TOKEN - 没有可用 credential 时，请用户通过可信 UI 或 secret manager 授权 scoped token
- 使用 CLI 支持的 token import 或环境变量，不把 token 放进 chat
- 不打开浏览器代替用户登录
- 不复制 user code
- 不读取 browser cookie
- 不把 product-session cookie 当成正常 agent auth
- 所有 write operation 继续走同一套 plan、authz、audit、redaction 和 readback
这些规则不会让 demo 更炫。但它们会让一个真实团队敢把 agent 接到部署控制面上。
AI Agent 的价值不在于它能绕过登录。它的价值在于：在拿到刚好够用的权限之后，能沿着产品已经定义好的安全路径，把部署、观测和恢复做得更快、更稳、更容易复核。