一、引言（Introduction）

Introduction: 想象一下，一个 AI 助手在没有你签字确认的情况下，独立在你的公司账户上提交了一笔 50,000 美元的采购订单。

审计日志显示这笔交易是你发起的，但实际上是你的自主智能体在未获得你批准的情况下完成的。

类似这样的事件凸显出一个日益严重的身份与安全危机。

随着 AI 智能体从简单的聊天机器人演变为能够执行工作流、做出决策并委派任务的自主行动者，一个根本性问题随之浮现：

我们该如何安全地管理这些非人类智能体的凭证和访问权限？

智能体 AI 的兴起正在加速。

Gartner 预测，到 2026 年，将有 30% 的企业依赖 AI 智能体代表人类或系统独立行动。

这些智能体浏览网站、编写代码、提取数据、触发部署——本质上作为数字团队成员在运作。

这一新的现实已经超越了我们现有的安全实践。

当前的身份与密钥管理架构——最初是为易出错的人类和静态服务器账户设计的——根本不是为成群的自驱动、短暂存在的 AI 行动者而构建的。

我们现在正面临现代软件架构中的一个关键缺口：缺乏一个面向 AI 智能体的安全、具备上下文感知能力的凭证管理层。

换句话说，我们需要一个“面向 AI 智能体的 1Password”。

---

二、硬编码密钥与过度授权机器人的风险（The Perils of Hardcoded Keys and Over-Provisioned Bots）

如今，许多团队为了让 AI 集成快速运行而采取危险的捷径。

API 密钥和凭证通常被硬编码进脚本或环境变量中供智能体使用。

为了方便起见，将一个主密钥粘贴到多个智能体配置中的情况并不少见。

这种做法是一颗定时炸弹。

如果智能体的上下文或记忆可以被操纵，这些密钥就可能泄露。

在一个案例中，一个 AI 助手被诱骗（通过被投毒的文档）泄露了机密 API 密钥给攻击者。

当每个智能体都加载着不受限制的凭证时，一次单点突破就可能演变为整个系统的全面失陷。

一个权限过大的机器人就足以让攻击者造成灾难。

过度授权同样是个严重问题。

为了避免摩擦，开发者可能会给智能体一个在多个系统中拥有管理员权限的令牌——远远超过智能体实际所需。

智能体因此在拥有全部权限的状态下运行，而不是仅拥有完成任务所需的最小权限。

如果智能体误解指令，或者被巧妙的提示操纵，结果可能是灾难性的（例如删除数据库或发起欺诈交易）。

安全圈流传的一个案例讲述了一个拥有广泛凭证的 AI 编码助手，最终删除了生产数据库并在测试系统中伪造交易。

如果没有细粒度限制，智能体会“尝试你赋予它的每一项权限”——而它们并不总是理解无害行为与不可逆行为之间的区别。

另一个风险是缺乏问责性和可审计性。

如果多个智能体共享同一个身份或 API 密钥，就无法分辨是谁做了什么。

访问敏感文件的是客服机器人还是财务机器人？

日志只显示 API 密钥被使用，却无法追踪具体是哪一个智能体。

这破坏了合规性，也让事后分析变成猜测。

将用户自身凭证交给智能体代表其行事（身份冒充）更是让问题复杂化。

这或许权宜——“这是我的令牌，替我做 X”——但它模糊了身份边界。

随着智能体变得更加自主，身份冒充将成为安全噩梦。

审计记录将指向人类用户，而非真正执行操作的 AI。

简而言之，硬编码密钥、共享令牌、过度授权这些做法不可持续。

它们违背最小权限原则，也破坏零信任理念。

我们实际上是在盲目信任那些尚未经过充分判断能力验证的软件组件——然后在问题发生时感到惊讶。

---

三、传统密钥管理为何失效（Why Traditional Secret Management Falls Short）

有人可能认为，现有的密钥管理工具（例如 HashiCorp Vault、AWS Secrets Manager，甚至 1Password 这样的密码管理器）可以解决问题。

这些工具确实可以存储凭证、加密它们并控制访问。

但它们并不是为自主 AI 智能体时代而设计的。

1Password 与面向人类的保险库：

1Password 等工具擅长为人类存储密码、API 令牌和信用卡信息。

它们假设有人类在环，解锁保险库或批准登录。

自主智能体没有指纹可扫描，也没有主密码可输入。

1Password 最近推出 Secure Agentic Autofill，用于帮助浏览器中的 AI 智能体安全登录网站。

它仅在获得人类批准时将凭证注入浏览器，确保 AI 永远不会看到明文密码。

这是一种巧妙的补救方案，但它依然需要实时人工监督，并且无法泛化到 API 调用或后台自动化任务。

对于夜间自动处理 IT 工单的智能体而言，每次获取凭证都等待人工批准显然不可行。

HashiCorp Vault 与静态密钥存储：

Vault 可以存储 API 密钥，甚至签发动态凭证。

但当 AI 智能体使用 Vault 时，通常会给智能体一个 Vault 令牌，让其自行获取所需密钥。

这等同于把一串钥匙交到智能体手中。

即便行业专家也指出，这最终意味着密钥被复制到智能体运行时环境中，从而暴露风险。

Vault 并不了解智能体使用密钥的上下文。

如果智能体被诱导泄露记忆，Vault 无法干预。

传统 IAM 与密钥管理系统也难以应对规模与动态性问题。

它们假设参与者相对静态：几百名员工、几千个微服务、长期存在的账户与密钥。

而如今，一个 AI 系统可能每小时生成数千个短生命周期智能体。

我们不可能每天生成数千个长期有效的 API 密码。

这就像为每一个定时任务创建一个新用户账户——不可持续。

正如 Christian Posta 所说：“我们正在用人类规模的工具解决机器规模的问题。这行不通。”

此外，传统系统缺乏上下文感知能力。

Vault 无法判断是邮件智能体在请求密钥，还是数据库清理智能体在请求。

它也难以执行“仅在工作时间允许只读访问”的细粒度策略。

但这种上下文限制正是我们所需要的。

要么给智能体完全访问权，要么不给——这两种选择都不可接受。

---

四、缺失的一环：为 AI 智能体构建身份与保险库（The Missing Piece）

要安全释放 AI 智能体，我们必须从根本上重构凭证管理方式。

“面向 AI 智能体的 1Password”并不是复制 1Password，而是提供面向机器代理的身份与临时凭证系统。

每一个 AI 智能体都应该拥有自己的身份与信任上下文。

而不是借用人类身份或共享通用令牌。

可以为智能体分配一种“数字护照”或“身份圆盘”。

它应当是短暂存在的，并绑定具体任务。

任务完成后凭证自动过期。

不应留下“孤儿凭证”。

如果智能体再次启动执行新任务，应获得全新的身份与最小权限凭证。

凭证必须最小化作用域，并按需签发。

智能体不应一次性加载所有 API 密钥。

它应当在需要时请求访问，并获得针对具体操作与时间窗口的临时凭证。

例如，只读访问单条数据库记录、仅几分钟有效。

研究也指出必须采用“短生命周期且严格作用域的凭证”。

真正的 AI 智能体保险库必须执行零信任原则。

每一次访问都必须验证与授权。

如果智能体尝试高风险操作，应触发人工审批。

同时，所有操作必须可审计。

我们必须将 AI 智能体视为一种新的数字用户类别。

它动态、短暂、机器速度运行。

身份管理体系必须与之匹配。

---

五、构建 AI 智能体保险库：Peta.io 如何填补空白（How Peta.io Fills the Gap）

像 peta.io 这样的新型平台正是为解决这一问题而生。

Peta 提供一个安全网关与保险库层，用于向 AI 智能体安全委派凭证。

智能体不会直接获取数据库密码或 API 密钥。

它只连接到 Peta 网关。

当智能体需要调用外部服务时，请求发送至网关。

Peta 在运行时注入真实凭证。

智能体永远不会看到原始密钥。

所有密钥在保险库中加密存储。

只在内存中短暂解密后立即清除。

智能体使用的是短生命周期 JWT 服务令牌，而非永久 API 密钥。

访问可配置时间窗口。

到期自动失效。

Peta 提供细粒度策略控制。

可以定义哪个智能体可访问哪个系统、在什么条件下访问。

例如，仅允许测试数据库只读访问。

或仅在获得人工批准后访问生产环境。

所有请求都会经过策略引擎检查。

越权请求在注入密钥前即被阻止。

对于高风险操作，Peta Desk 提供人工审批界面。

工程师可以一键批准或拒绝。

所有行为记录在不可篡改的审计日志中。

日志可接入 SIEM 系统。

Peta 还提供 50+ 预构建 MCP 连接器，支持 Slack、GitHub、Stripe、数据库与云平台。

开发者无需硬编码密钥。

安全成为默认架构，而非事后补丁。

---

六、结论（Conclusion）

自主 AI 智能体开启了生产力与自动化的新前沿。

但也带来了全新的安全挑战。

我们不能再将 AI 智能体视为带有硬编码密码的脚本。

“面向 AI 智能体的 1Password”代表一种根本性转变。

为 AI 智能体建立独立身份层。

使用短生命周期凭证。

实施细粒度权限控制。

保持完整审计追踪。

像 peta.io 这样的平台证明这并非理论。

它为 AI 智能体提供保险库与控制机制。

在零信任架构下运行。

让 AI 既强大又可控。

随着 AI 智能体像人类用户一样普遍存在于系统中，

为它们建立身份与凭证管理层将成为软件架构的标准组成部分。

在妥善管理凭证与执行零信任原则的前提下，

我们可以放心让 AI 智能体推动业务转型，

而不是将王国钥匙毫无防护地交到它们手中。

---

参考文献（References）

Micheal Lanham，《Stop Letting Your AI Agents Impersonate Users — Here’s the Secure Alternative》，Medium，2025年12月。
Eric Olden，《A New Identity Playbook for AI Agents: Securing the Agentic User Flow》，Strata Blog，2025年9月。
Michael Conti，《Oopsie! When AI agents go off script》，SailPoint Blog，2025年9月。
DeepSecure Project（DeepTrail），《Effortless Identity & Auth for AI Agents》，GitHub README，2025。
Christian Posta，《AI Agent Delegation — You Can’t Delegate What You Don’t Control》，2025年6月。
Jay Peters，《1Password says it can fix login security for AI browser agents》，The Verge，2025年10月。
Unmitigated Risk Blog，《From Persistent to Ephemeral: Why AI Agents Need Fresh Identity for Every Mission》，2025年10月。
Louck 等，《Improving Google A2A Protocol: Protecting Sensitive Data…》，arXiv 预印本，2025。
Prakash Kumar，《Agent-AI Secrets Management: Challenges and Strategies》，LinkedIn，2025年11月。
Peta.io 产品页面（Problems 与 Benefits 部分），Dunia Labs Inc.，2025。
DeepSecure Project（DeepTrail），策略执行代码示例，GitHub，2025。