请问HN：你们是如何与AI代理管理机密信息的？
今天，使用代理进行秘密管理似乎缺乏有效性。代理需要 API 密钥来调用外部服务，但在这种情况下，常见的模式似乎失效了。在编写代理技能时，这一点尤为明显。
环境变量：代理具有 shell 访问权限。它可以运行 `env` 或 `echo $API_KEY` 来访问秘密，无论是通过提示注入，还是通过探索或调试。
.env 文件：同样的问题。代理可以执行 `cat .env`。该文件就在文件系统上，等待好奇的 `print()` 语句去读取。
代理进程/包装器：您可以启动一个单独的进程来保存秘密并代理请求。代理调用本地地址，从未看到密钥。这种方法有效，但带来了很大的操作开销。现在您需要运行基础设施，仅仅是为了将一个字符串隐藏在自己的工具之外。这也感觉像是在重新发明 MCP。
我一直在尝试的方案：
1. 使用凭据助手的操作系统钥匙串：捆绑或生成的脚本在运行时调用系统钥匙串（macOS 钥匙串、Windows 凭据管理器等）。代理可以调用该脚本，但无法直接查询钥匙串。像 Python 的 `keyring` 这样的库对操作系统钥匙串进行了抽象，使其在一定程度上可移植，但这都假设了特定的运行时环境，并需要用户通过操作系统进行交互。
2. 凭据命令逃生口：脚本接受 `--credential-cmd` 标志，运行任意 shell 命令以获取秘密（如 `pass show`、`op read`、`vault kv get` 等）。这种方法灵活，但代理可能会检查正在运行的命令并尝试访问它。
这两种方法都不算是真正的解决方案。代理可能会探测凭据。
其他人在代理工作流中是如何处理秘密的？是否有人在构建具有适当秘密隔离的代理运行时？这似乎是官方代理工具需要解决并交付的内容。
查看原文
Secrets management with Agents feels absent today. The agent needs API keys to call external services, but the usual patterns feel broken in this context. You see this clearly when writing Agent Skills.<p>Environment variables: The agent has shell access. It can run `env` or `echo $API_KEY` and access the secret, either through prompt injection or just by exploring or debugging.<p>.env files: Same problem. The agent can `cat .env`. The file is right there on the filesystem waiting for curious `print()` statements.<p>Proxy process / wrapper: You can stand up a separate process that holds the secret and proxies requests. The agent calls localhost, never sees the key. This works, but it's a lot of operational overhead. Now you're running infrastructure just to hide a string from your own tools. It also feels close to reinventing MCP.<p>What I've been experimenting with:<p>1. OS keychain with credential helper: The bundled or generated script calls out to the system keychain (macOS Keychain, Windows Credential Manager, etc.) at runtime. The agent can invoke the script, but can't directly query the keychain. Libraries like Python's `keyring` abstract over OS keychains and make it somewhat portable, but this all assumes certain runtime environments and requires user interaction via the OS.<p>2. Credential command escape hatch: Scripts accept a `--credential-cmd` flag that runs an arbitrary shell command to fetch the secret (`pass show`, `op read`, `vault kv get`, etc.). Flexible, but the agent could potentially inspect what command is being run and iterate to try to access it anyway.<p>Neither of these feel like a real solution. An agent could probe for credentials.<p>How are others handling secrets in agent workflows? Is anyone building agent runtimes with proper secrets isolation? Seems like something the official agent harnesses need to figure out and ship with.