当企业将 AI 编码代理投入生产环境时，一个被长期忽视的安全工程缺口逐渐显现：如何让 agent 在代表用户执行操作时安全地获取凭证。传统的做法是在代码或环境变量中硬编码一个 API 密钥，所有用户和所有会话共享同一个密钥。这种做法在单个开发者使用 AI 辅助编程时勉强可以接受，但当组织内有数十甚至数百人同时使用 AI 代理时，问题迅速恶化：密钥泄露风险陡增、无法针对单个 agent 进行撤销、审计日志无法追溯到底是哪个 agent 在代表哪个人执行了操作。Kontext 作为这一领域的代表性解决方案，提供了一种全新的委托凭证模型，其核心思路值得所有构建 AI agent 基础设施的团队参考。
传统凭证管理的结构性困境
在传统的软件系统中，身份模型相对固定：要么是真实用户在操作，要么是服务账号在运行后台任务。这两种模型都有成熟的解决方案 —— 用户通过 OAuth 2.0 进行身份认证，服务账号使用长周期 API 密钥或 JWT。然而 AI 编码代理的出现打破了这个二元划分。Agent 不是用户，它没有自己的登录凭证；Agent 也不是纯粹的服务账号，因为它需要代表特定的终端用户行事，其权限范围应该与该用户的权限一致。这种「委托代理」的特性使得现有的身份系统无从建模。
实际生产中的做法往往是退而求其次：在项目根目录放置一个共享的 .env 文件，里面写着 GitHub、Slack、Jira 等服务的 API 密钥。整个团队共用这些密钥，所有 agent 的所有操作都使用同一套凭证。这意味着，如果某一个 agent 因为 prompt 注入或逻辑错误而执行了恶意操作，攻击者实际上获得了该用户在所有服务上的完整权限。更糟糕的是，当安全事故发生后，团队无法从审计日志中判断究竟是哪一次 agent 调用导致了问题，因为在日志里它们都来自同一个 API 密钥。
Kontext 的委托凭证模型
Kontext 解决的问题本质上是「如何为 agent 建立一种新的身份主体」。它的核心设计思路是：agent 应该拥有自己独立的身份，但这个身份的权限范围来自委托它的用户，且这种委托关系应该是临时的、可撤销的、作用域受限的。具体来说，Kontext 提供了一种运行时凭证机制，开发者只需要一行代码即可获取针对特定服务的短期凭证。
在代码层面，Kontext 的 SDK 暴露了一个极为简洁的接口。假设一个 AI 编码代理需要代表用户访问 GitHub API，只需要调用 kontext.require("github", token) 即可获得一个短期有效的访问令牌。这个令牌的生成过程包含四个关键维度：谁在操作（agent 的标识）、代表谁操作（授权的人类用户）、操作的范围（scopes）、以及有效期（通常以分钟计）。这四个维度被编码在令牌内部，使得后续的每一次 API 调用都可以追溯到具体的委托关系。
与传统的 OAuth 流程相比，Kontext 的优势在于对开发者透明。团队不需要为每个用户配置复杂的 OAuth 授权流程，SDK 内部已经处理好了令牌的获取、缓存和刷新。开发者只需要在发起请求时从 Kontext 获取当前有效的凭证，然后将其附加到 HTTP 请求的 Authorization 头部即可。对于已经存在的 AI 代理代码，改造成本通常只是将硬编码的 API 密钥替换为一次 Kontext 调用。
Go 实现的核心架构解析
虽然 Kontext 官方并未开源其完整实现细节，但从公开的技术描述和 HN 讨论中可以提炼出其 Go 实现的核心架构思路。首先是凭证的发行层，即 Kontext Server。它负责验证发起请求的用户身份（通常与企业已有的身份提供商集成，如 Okta、Auth0 或 Google Workspace），同时验证发起请求的 agent 是否被该用户授权。在双重验证通过后，Server 生成一个短期令牌，这个令牌本身可以是 JWT 格式，也可以是一个随机生成的 opaque token，取决于目标 API 的兼容性要求。
其次是 SDK 层的客户端实现。一个健壮的 Go SDK 需要处理以下几个工程细节。第一是令牌缓存：不要每次调用都向 Server 请求新令牌，SDK 应该在内存中维护当前有效的令牌，并在令牌即将过期（例如还剩 30 秒）时提前刷新。第二是错误处理：当服务器返回 401 时，SDK 应该自动触发一次令牌刷新，而不是直接向调用者返回错误。第三是安全存储：即使在客户端侧需要临时存储刷新令牌，也应该使用操作系统提供的凭证保险库（如 macOS 的 Keychain 或 Windows 的 Credential Manager），而不是明文写入磁盘文件。
在 HTTP 客户端层面，Go 的 http.RoundTripper 接口为这种自动凭证注入提供了天然的支持。开发者可以实现一个自定义的 RoundTripper，在每个请求发送前检查本地缓存的令牌是否有效，如果无效则先调用 Kontext SDK 获取新令牌，然后将令牌填入请求头。这种设计的最大好处是对上层业务代码完全透明 —— 业务逻辑只需要使用标准的 http.Client，无需额外处理凭证管理的复杂性。
密钥轮换与撤销机制
短期令牌是安全的基础，但要让这个基础真正发挥作用，还需要配套的轮换和撤销策略。Kontext 的设计理念中，每个令牌的默认有效期被设置得非常短，通常在 5 到 15 分钟之间。这个时间窗口的选取是一个权衡：太短会增加 Server 的请求压力并导致客户端频繁刷新，太长则会在令牌泄露时增加风险窗口。对于大多数企业场景，10 分钟是一个合理的默认值。
当需要撤销某个特定 agent 的权限时，Kontext 支持按 agent ID 进行细粒度撤销。与传统的 API 密钥管理不同，撤销操作不需要轮换共享密钥 —— 因为每个 agent 在每次请求时都会从 Kontext 获取一个独立的短期令牌。一旦某个 agent 被撤销，它在下一次请求时将无法获得新令牌，旧的令牌在几分钟窗口期过后也会自然失效。这种机制大大缩短了安全事件的响应时间，从过去的「立即轮换所有密钥并通知所有用户」降低到「在管理面板中点击一次撤销」。
审计日志是委托凭证模型的另一个关键组成部分。Kontext 生成的每个令牌在发行时都会记录完整的上下文信息：哪个用户授权了该 agent、授权的时间戳、请求的 scopes 列表、以及分配的唯一标识符。这些元数据随后会被写入到审计日志中。当安全团队需要调查某次异常操作时，他们可以直接在日志中定位到具体的 agent 标识和对应的授权人，而不需要像过去那样在海量日志中猜测哪个 API 密钥对应哪个人。
面向多租户场景的工程参数
将 Kontext 这样的凭证代理部署到企业多租户环境时，有几个关键的工程参数需要根据实际业务规模进行调整。第一个参数是令牌刷新阈值，建议设置为令牌剩余有效期的 20% 或 60 秒，取两者中的较大值。例如，如果令牌有效期为 10 分钟，那么当令牌剩余 2 分钟或 60 秒时（取 2 分钟），SDK 就应该开始预刷新。第二个参数是凭证缓存的大小，在高并发场景下建议为每个租户维护独立的缓存实例，避免跨租户的数据泄露。
第三个参数是超时配置。Kontext Server 的请求超时建议设置为 5 秒，超过这个时间后客户端应该回退到使用当前缓存的令牌（即使它已经接近过期），而不是让整个请求失败。这是因为凭证获取失败不应该阻塞业务请求，业务请求可以使用旧令牌碰碰运气，风险无非是收到一个 401，然后在错误处理中触发一次同步刷新。第四个参数是重试策略，建议采用指数退避策略，首次重试等待 100 毫秒，随后每次重试时间翻倍，最大重试次数设为 3 次。
对于需要将 Kontext 与现有基础设施集成的团队，一个常见的部署模式是在 Kubernetes 集群中运行 Kontext Server 作为一项内部服务，每个 namespace 部署一个 SDK sidecar 或者在应用 pod 中直接注入 SDK 依赖。在这种模式下，SDK 与 Server 之间的通信可以通过 mTLS 加密，确保即使在集群内部网络中被截获，也无法伪造凭证请求。
资料来源
本文核心信息来源于 Kontext 官方发布公告与 Hacker News 讨论，Kontext 将自身定位为 AI 代理的运行时凭证解决方案，其核心价值在于为 agent 提供一种区别于用户和服务账号的第三类身份主体模型。