Secrets Automation

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.