Ask HN: 你们用 AI 助手管理密钥的方式是怎样的？
2 分•作者: m-hodges•9 天前
目前来看，使用 Agent 进行密钥管理似乎存在缺失。Agent 需要 API 密钥来调用外部服务，但在这种情况下，通常的模式感觉行不通。在编写 Agent Skills 时，这一点尤为明显。
环境变量：Agent 具有 shell 访问权限。它可以运行 `env` 或 `echo $API_KEY` 并访问密钥，无论是通过提示注入，还是通过探索或调试。
.env 文件：同样的问题。Agent 可以 `cat .env`。该文件就在文件系统上，等待着好奇的 `print()` 语句。
代理进程 / 包装器：您可以启动一个单独的进程来保存密钥并代理请求。Agent 调用 localhost，永远看不到密钥。这可行，但会带来大量的运维开销。现在，您正在运行基础设施，仅仅是为了对您自己的工具隐藏一个字符串。这感觉像是重新发明 MCP。
我一直在尝试的方案：
1. 带有凭证助手的操作系统钥匙串：捆绑或生成的脚本在运行时调用系统钥匙串（macOS 钥匙串、Windows 凭证管理器等）。Agent 可以调用该脚本，但不能直接查询钥匙串。像 Python 的 `keyring` 这样的库抽象了操作系统钥匙串，并使其具有一定的可移植性，但这都假设了特定的运行时环境，并且需要用户通过操作系统进行交互。
2. 凭证命令逃生舱口：脚本接受一个 `--credential-cmd` 标志，该标志运行一个任意的 shell 命令来获取密钥（`pass show`、`op read`、`vault kv get` 等）。虽然很灵活，但 Agent 可能会检查正在运行的命令，并尝试迭代以访问它。
这两种方案都不像是真正的解决方案。Agent 可能会探测凭证。
其他人是如何在 Agent 工作流程中处理密钥的？有人正在构建具有适当密钥隔离的 Agent 运行时吗？这似乎是官方 Agent 工具需要解决并随附的问题。
查看原文
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.