密钥自动化
NetVar13372026-10-27查看 1596复制 404
用于设置无人值守的机密访问(服务账户、vault 作用域、非回显令牌)。
📘如何使用这个技能
- 1复制技能内容·点击上方「Copy SKILL.md」复制全部内容,或 Download 下载到本地
- 2打开你的 AI 客户端·支持 Claude Code、Trae、Cursor、ChatGPT、DeepSeek、Kimi 等任意 AI 助手
- 3粘贴为系统提示/知识文件·Claude Code:放入 .claude/skills/ 目录;普通对话:作为首条消息发送并说「请严格按这份技能文档执行」
- 4直接提出你的需求·AI 会按技能定义的工作流、格式和约束来处理,无需再解释背景
💡 提示:技能生效后,每次对话只需一句需求,AI 会按 SKILL.md 的流程执行。
SKILL.md5279 chars
--- name: secrets-automation description: "Use when setting up unattended secret access (service accounts, vault scoping, non-echoing tokens)." version: 1.0.0 license: MIT metadata: package: unleash-skills author: NetVar1337/unleash category: imported upstream: C:\Users\Admin\.agents\skills\secrets-automation\SKILL.md --- > Bundled with Unleash skills pack. Source: C:\Users\Admin\.agents\skills\secrets-automation\SKILL.md # Secrets Automation Use dedicated machine identities for unattended access. Never turn a human account password into an automation credential. ## Security invariants - Never save, echo, log, memorize, script, or place a human vault password in command arguments, environment variables, hooks, shell history, or source control. - Treat any password or token pasted into chat as exposed. Recommend rotation and do not repeat it. - Prefer a dedicated service account restricted to a dedicated vault and only the required operations. - Capture generated tokens without printing them. Prefer direct process capture, a concealed prompt, or a local clipboard-to-file transfer followed immediately by clipboard clearing. - Do not claim success until a real secret-manager API operation works under the machine identity. - If validation fails, remove the credential from the agent's active environment so it does not override a working interactive integration. ## Standard workflow 1. **Discover the supported automation identity.** Prefer service accounts, Connect-style servers, workload identity, or the vendor's supported SDK/MCP. Do not automate a master password. 2. **Create a dedicated vault or namespace.** Use a descriptive name such as `Hermes`; do not grant Personal/Private vault access by default. 3. **Grant least privilege.** Start with read-only. Add write access only when the agent must create or rotate items. 4. **Generate the token once.** Capture stdout or clipboard without displaying the value in tool output. Clear temporary files and clipboard content immediately. 5. **Store through the host's secret channel.** For Hermes skill credentials, use the Hermes secret environment path rather than project files. Preserve unrelated entries with an atomic targeted update. 6. **Verify the identity, state, and intended operation.** Use the vendor-supported identity command, then perform a harmless read. If write access is required, create and remove a non-secret verification item. 7. **Apply to long-running processes.** Restart only the relevant gateway/agent process after successful verification. 8. **Document scope, not secrets.** Report the identity name, vault scope, permissions, and verification status—never token contents. ## 1Password-specific rules - `OP_SERVICE_ACCOUNT_TOKEN` is the supported non-interactive CLI credential. - Verify service-account authentication with `op user get --me` and confirm `Type: SERVICE_ACCOUNT` and `State: ACTIVE`. - `op service-account ratelimit` is a useful second server-side verification. - Do not use `op vault list` as the primary service-account authentication check; it is not in the documented supported-command set. - Desktop-app integration is intentionally interactive. On Windows, authorization is process/session scoped, expires after inactivity, has a hard lifetime, and uses Windows Hello. It cannot provide a supported guarantee of never prompting. - If Connect variables are present, `OP_CONNECT_HOST` and `OP_CONNECT_TOKEN` take precedence over `OP_SERVICE_ACCOUNT_TOKEN`; inspect variable names without printing values. - A locally decodable `op whoami` result is not sufficient proof that server-side service-account authentication works. Require `op user get --me` or another supported server request. ## Safe token handling pattern - Keep the token out of command-line arguments. - When a web UI offers only a Copy button, click it locally, read the clipboard inside a short-lived process, validate only the prefix/shape, atomically write the secret destination, and clear the clipboard. - Never send a screenshot containing a generated token to vision or OCR output. If local OCR is needed to locate controls, redact long token-like strings before returning text and use accessibility labels such as “Copy … token” when available. - Delete screenshots or temporary artifacts that could contain token pixels after setup. ## Failure handling - Separate **identity creation** from **authentication verification**. An admin console showing Active and expected permissions does not prove that the captured token authenticates. - Retry briefly for eventual consistency, then stop. Do not rotate repeatedly or create multiple service accounts without evidence. - Test precedence conflicts and interactive-app interference without persisting extra credentials. - Preserve the last securely backed-up token, but remove a non-working token from the active agent environment to avoid breaking other authentication paths. - Escalate to the vendor/admin console with sanitized facts: CLI version, identity state, permission scope, supported verification command, and exit code—never the token. ## References - See `references/1password-service-accounts.md` for authoritative command support, Windows prompt behavior, and a concise verification checklist.