从服务账号到临时身份：Agyn 如何重构企业 Agent 的零信任运行时

AI Agent 正在从个人电脑上的自动化助手，进入企业内部的生产环境。

过去我们讨论 Agent，更多关注它能不能规划任务、能不能调用工具、能不能完成复杂工作流。

但当 Agent 真正进入企业系统后，问题会发生变化：它不再只是一个会聊天的模型，而是一个能够访问代码仓库、数据库、消息队列、内部 API 和业务系统的数字主体。

这时候，真正危险的不是 Agent 回答错一句话，而是它拿着过大的权限，在错误的上下文里做了错误的动作。

论文 《Agyn: An Open-Source Platform for AI Agents with Scalable On-Demand Execution, Agent Definition as a Code, and Zero-Trust Access》 讨论的正是这个问题。

https://arxiv.org/pdf/2605.27575

作者提出，企业部署 Agent 的核心挑战，正在从“构建单个 Agent”转向“规模化运营大量 Agent”，而这些 Agent 往往具有 非确定性流程、有状态会话，并且会访问内部高权限服务。

Agyn 给出的答案，是把 Agent 作为一种 云原生工作负载 来管理，通过 Kubernetes、Terraform、OpenZiti 和 OpenFGA 组合出一套企业级 Agent 运行时。

Agent 进入企业后，服务账号开始不够用了

在传统软件系统里，服务账号是一种很常见的设计。一个后端服务需要访问数据库，就给它一个数据库账号；需要调用内部 API，就给它一个服务凭证。只要这个服务逻辑稳定、边界清晰、请求路径可控，这套方式可以工作很多年。

但 Agent 不一样。

Agent 的动作不是固定代码完全写死的。它会根据用户输入、模型推理、工具返回结果不断调整下一步行为。它可能先读一个文档，再调用一个 MCP 工具，然后访问一个内部接口，最后修改某个系统配置。整个过程带有明显的探索性和非确定性。

如果继续用传统服务账号的方式，就会出现一个很尴尬的问题：为了让 Agent 能干活，企业往往会给它比较大的权限；但一旦 Agent 被提示注入、工具污染、上下文劫持，或者只是模型自己判断失误，这些权限就会被放大成真实业务风险。

Agyn 论文把这个问题说得很直接：平台不能因为 Agent 运行在内部网络里，就默认相信它；每一次对数据库、API 或消息队列等内部服务的请求，都应该被单独授权；凭证也不应该暴露给模型上下文。

这其实是 Agent 安全范式的变化。过去我们更关心“模型能不能拒绝危险问题”，现在必须进一步关心“Agent 作为一个数字主体，应该如何被授权、隔离、回收和审计”。

Agent 不是应用功能，而是基础设施对象

Agyn 的定位不是一个新的 Agent 开发框架。它不主要解决“怎么写 Agent 工作流”，也不主要解决“怎么做多 Agent 协作”。它更像是一个 Agent Runtime，也就是企业用来运行、管理和治理 Agent 的基础设施底座。

论文将 Agyn 的设计概括为三个关键词： 按需执行、有代码化定义、零信任访问 。更具体地说，它提供的是一个基于 Kubernetes 的有状态 Serverless Agent 运行时，一个通过 Terraform 管理 Agent 定义和运行环境的配置体系，以及一套基于 OpenZiti 和 OpenFGA 的零信任安全架构。

这三个点背后的逻辑非常清楚。

首先， 企业不可能给每一个 Agent 定义都长期保留一个常驻 worker 。Agent 可能有很多，但真正同时运行的只是其中一部分。如果每个 Agent 都常驻，就会浪费大量计算资源。

其次， Agent 的 prompt、工具、密钥、资源限制，并不是随便填在控制台里的“配置项”，而是会直接影响生产系统行为的基础设施配置。 谁改了 prompt，谁加了工具，谁绑定了密钥，谁调整了资源限制，都应该能被版本控制、代码评审和回滚机制管理起来。

最后， Agent 需要访问内部系统，但模型本身不能被视为可信主体。 它不能直接看到密钥，也不能凭借一个长期服务账号在内网里自由移动。它应该在每次运行时获得一个临时身份，并且只能访问被明确允许访问的服务。

这就是标题里说的“从服务账号到临时身份”。

按需执行：Agent 实例是短生命周期工作负载

Agyn 的第一个关键设计，是把 Agent 实例做成一种有状态的 Serverless 工作负载。

传统 Serverless 更适合 HTTP 请求这类短任务。请求来了，函数启动；请求结束，资源释放。但 Agent 工作负载不同。它往往由一条对话消息触发，执行时间可能持续数分钟，还需要保留多轮上下文、工作目录和中间状态。

Agyn 的做法是“ 计算短暂，状态持久 ”。

当用户在某个 thread 里给 Agent 发送消息时，Notifications 服务会发布事件，Agents Orchestrator 收到事件后判断是否需要启动对应的 Agent 实例。如果需要，它会解析密钥、申请 OpenZiti 身份，并通过 k8s-runner 创建 Kubernetes Pod。这个 Pod 会挂载持久卷，并获得 thread 上下文，从而恢复之前的工作状态，而不是每次从零开始。

当 Agent 处于活跃状态时，它会定期发送 keep-alive。默认情况下，如果空闲超过 5 分钟，Orchestrator 会停止 Pod，并删除对应的网络身份，但持久卷和 thread 历史仍然保留。下一次用户继续发送消息时，平台再重新拉起实例，并重新挂载原来的状态。

这套机制看上去像普通弹性调度，但对 Agent 很关键。因为它既避免了大量 Agent 常驻造成的资源浪费，又保留了 Agent 会话所需的状态连续性。

原文图1：Agyn 系统架构图。外部 Chat App、Console 和 Custom Connectors 通过 Gateway 进入平台；控制面负责授权、线程、通知、Agent 编排、组织和密钥管理；执行面以 Agent Pod 形式运行，其中包含 Agent Container、MCP Sidecar 和 Ziti Sidecar。

Agent as Code：Prompt、工具和密钥也应该进入工程治理

Agyn 的第二个关键设计，是 Agent Definition as Code 。

这句话听起来像基础设施领域常见的 IaC ，但放在 Agent 场景里非常有价值。因为 Agent 的核心配置并不是普通 UI 配置，而是会直接改变 Agent 行为边界的生产资产。

一个 Agent 的 system prompt 决定它的角色和行为准则；工具列表决定它能调用什么能力；密钥绑定决定它能访问哪些系统；资源限制决定它能消耗多少计算资源；持久卷决定它能保留哪些状态。这些东西如果只存在某个 Web 控制台里，长期看一定会变成治理黑洞。

Agyn 通过 Terraform Provider 来声明 Agent 和它的 harness。这里的 harness 可以理解为 Agent 周围的运行环境，包括 Agent 容器、workspace、system prompt、模型、MCP server、密钥、持久卷和资源限制等。平台也支持 Claude Code、OpenAI Codex 和 Agyn 自己的 agent-loop 实现，同时允许企业带入自定义容器。

这意味着，Agent 的变化可以进入 Git 仓库，接受 Code Review，保留变更历史，并在出问题时回滚到旧版本。

对企业来说，这一点非常现实。未来 Agent 事故排查时，安全团队不会只问“模型为什么这么回答”，还会问：这个 Agent 什么时候加了这个工具？谁给它绑定了这个密钥？为什么它能访问这个 MCP server？它的 prompt 是什么时候改的？改动有没有经过评审？

如果没有 Agent as Code，这些问题很难回答。

零信任访问：模型不可信，Agent 也不应默认可信

Agyn 最值得关注的部分，是它对 Agent 权限的处理方式。

它没有把安全寄托在“模型会自觉遵守规则”上，也没有简单依赖 prompt 约束，而是采用了更工程化的零信任架构。论文中提到，Agyn 的安全机制主要由三部分组成：每容器隔离、OpenZiti 零信任 overlay 网络，以及 OpenFGA 关系型授权。

第一层是 容器隔离 。Agent 主进程运行在主容器里，MCP server 运行在 sidecar 容器里。每个容器有独立文件系统和进程树，只共享 loopback。密钥只注入真正需要它的容器，通常是 MCP sidecar，而不是注入驱动 LLM 的 Agent 容器。

这个设计非常关键。因为很多 Agent 风险不是模型“想不想作恶”，而是模型上下文里不应该出现的东西被它看见了。一旦密钥进入模型可见范围，提示注入就可能诱导模型泄露、转述、复用或错误调用。Agyn 的思路是让模型不直接接触凭证，把敏感能力封装在受控工具侧。

第二层是 零信任网络 。每个 Agent 实例启动时都会获得自己的 x509 身份，并通过 OpenZiti 建立 mTLS 连接。Gateway 会提取这个身份并在调用链中传播，使下游服务知道“到底是哪一个 Agent 实例在请求”。然后，ABAC 策略会限制 Agent 只能访问显式允许的服务。

第三层是 关系型授权 。Agyn 使用 OpenFGA 实现更细粒度的 ReBAC 权限控制，例如 owner、maintainer、participant 等角色，以及 thread 级别的参与者访问控制。

这三层组合起来，形成了一种很清晰的安全原则：Agent 可以执行任务，但不能天然继承整个内网信任；Agent 可以调用工具，但不能直接持有所有凭证；Agent 可以拥有身份，但这个身份应该和具体实例、具体任务、具体生命周期绑定。

Agyn 和其他 Agent 平台的差异在“能不能被企业治理”

论文还把 Agyn 与 AWS Bedrock AgentCore、Claude Code cloud、Google AX、kagent 做了对比。按照作者给出的表格，Agyn 同时覆盖了自托管、预构建 Agent、MCP 隔离、声明式配置、Serverless、凭证隔离和零信任能力，而其他平台只覆盖其中一部分。

这个对比表需要谨慎看。它是作者自己的总结，不是第三方评测。但它仍然能帮助我们理解 Agyn 的定位。

AgentCore、Claude Code cloud 更偏托管平台，使用方便，但企业对底层运行环境和安全边界的控制会更弱。Google AX、kagent 更偏开源运行时或 Kubernetes-native Agent 平台，但在凭证隔离、零信任访问和弹性执行方面并不完整。LangGraph、AutoGen、CrewAI 这类框架则主要解决 Agent 编排和开发问题，本身不是企业级运行治理底座。

所以 Agyn 的差异点不是“能不能写 Agent”，而是“当企业有很多 Agent 时，能不能把它们像生产工作负载一样管理起来”。

这也是 Agent 安全领域正在发生的变化。过去大家把安全问题放在模型层，讨论越狱、拒答、提示注入、输出过滤。现在 Agent 进入真实业务流之后，安全问题开始下沉到身份、网络、工具、密钥、审计和生命周期治理。

原文 Table 1 对比了 Agyn、AgentCore、Claude Code cloud、Google AX 和 kagent 在自托管、预构建 Agent、MCP 隔离、声明式配置、Serverless、凭证隔离和零信任方面的差异。

局限性

虽然 Agyn 的方向很有价值，但这篇论文也有明显局限。

它不是一篇严格的安全评测论文，也没有提供充分的性能实验。比如，Agent 冷启动时间是多少？高并发下 Pod 创建和回收效率如何？OpenZiti overlay 会带来多少网络开销？状态恢复在大 workspace 下是否稳定？这些问题论文没有展开。

更重要的是，它没有给出真实攻击实验。

例如，间接提示注入下，模型是否真的无法接触凭证？MCP sidecar 被攻陷后是否可能进一步横向移动？Agent 是否可能通过多个被授权工具组合出越权路径？OpenFGA 没有覆盖的 API 路径是否会成为绕过点？这些都是企业落地时必须追问的问题。

论文自己也承认，当前仍存在一些限制，包括 per-exposure Dial policy 还没有按用户粒度收敛，费用上限只是 metered 而不是 hard-capped，ReBAC 没有覆盖所有 API 路径，外部 runner 的信任模型也还没有明确。

这些限制说明，Agyn 不是一个已经解决所有 Agent 安全问题的终局方案。它更像是把问题方向摆正了：不要再把 Agent 安全简单理解为提示词防御，而要把 Agent 当成一种需要身份治理、权限治理和运行时治理的生产主体。

启发

Agyn 最重要的价值，不是提出了某个复杂算法，而是把 Agent 的企业化问题讲清楚了。

当 Agent 只是个人助手时，它的风险更多是误答、误操作和局部数据泄露。当 Agent 进入企业生产环境后，它就会变成一个可以持续行动、跨系统调用、持有上下文状态的工作负载。此时，安全问题就不再只是“模型是否对齐”，而是“这个数字主体是否被正确治理”。

一个成熟的企业 Agent 平台，至少要回答几个问题：Agent 是如何被定义的？谁可以修改它？它的每一次运行实例是谁触发的？它代表哪个用户执行任务？它能访问哪些工具和服务？密钥是否进入模型上下文？任务结束后身份是否销毁？每一次访问是否可审计？当 Agent 被提示注入影响时，最坏损害边界在哪里？

Agyn 给出的答案是：用 Serverless 解决弹性，用 Agent as Code 解决变更治理，用临时身份和零信任网络解决访问控制，用容器隔离和 ReBAC 缩小损害范围。

这套思路对国内企业同样有参考价值。尤其是在 Agent 开始连接办公系统、研发平台、客服系统、数据平台和业务 API 之后，企业不能只做“模型安全评测”或“输出内容过滤”。更底层的问题是，Agent 的身份、权限、工具和运行环境必须被纳入统一安全架构。

未来 Agent 安全的关键，不是谁能把提示词写得更严，而是谁能把 Agent 运行时做成可授权、可隔离、可审计、可回滚、可销毁的基础设施。

这正是 Agyn 这篇论文值得关注的地方。

它提醒我们：企业 Agent 的下一步，不是给模型更多权限，而是给每一个 Agent 更清晰、更短暂、更可控的身份。