Secure Secret Input

Use this skill when an AI agent needs a user to provide any sensitive or private value such as API keys, tokens, cookies, session IDs, passwords, app IDs, client secrets, or recovery codes.

Rule

Never ask the user to paste a secret into chat. Instead, open a visible local terminal or secure prompt window with clear labeling.

Default flow:

1. Check first — does the value already exist in credential storage, environment variables, local configuration files, or an authenticated API? If yes, use it programmatically and do not ask the user.

1. If the user must provide it, open a visible local window or terminal with a clear title and purpose.

1. Mask input — use masked input when supported (e.g., PowerShell's Read-Host -AsSecureString on Windows, or read -s in bash on Unix).

1. Write directly to destination — store the value directly to where it will be used:

• Project runtime: .env file (excluded from version control)
• Long-lived credential: credential manager (1Password, Bitwarden, OS keychain, etc.)
• One-shot use: process-local memory only
• Application integration: native OS credential store

1. Print only safe metadata — after collection, output only:

• Status (success / failure)
• Destination path (e.g., env-var name, credential store item name)
• Boolean confirmation

Never print the actual value.

1. Clean up — delete temporary files, markers, or helper scripts that could contain the value.

1. Update documentation — record only the secret's logical name, purpose, and storage location in any inventory or documentation. Never record the value itself.

Window Text Example

When opening a local input window, make the purpose unambiguous. The user may see it out of context.

Title:

Secure Input - API_KEY_NAME

Body:

An AI assistant needs a sensitive value.

Label: API_KEY_NAME
Purpose: Authentication with service XYZ
Destination: Project .env and credential vault

Type or paste it here, not in the chat.
The value will not be printed or logged.

Storage Targets

Choose the narrowest, most durable storage that fits the use case:

| Use Case | Storage | Notes | |----------|---------|-------| | Project runtime secret | .env file + ignore in git | Simple, local, secure if .gitignore is enforced | | Long-lived credential | Credential manager (Bitwarden, 1Password, macOS Keychain, Windows Credential Manager, etc.) | Encrypted, shareable, centralized | | One-shot command/session secret | Process-local memory only | Discarded when process exits | | CI/CD pipeline secret | Platform secret store (GitHub Secrets, GitLab CI Variables, etc.) | Never in .env or repo files |

Do NOT store raw secrets in:

• Repo files or documentation
• Chat history or logs
• Screenshots or recordings
• Memory files or handoff documents
• Generated code or config exports
• Plaintext JSON/YAML/CSV files

Exposure Response

If a raw secret is accidentally exposed (pasted in chat, logged to file, stored in docs, etc.):

1. Stop using it immediately.
2. Mark it for rotation — revoke it in the service's settings if possible.
3. Remove it from logs and files when safe to do so (use file deletion/editing, not just masking).
4. Create a replacement — collect a new secret through the secure input flow.
5. Update records — update any inventory or documentation with the new safe metadata.

Decision Tree: Ask in Chat, or Use Local Input?

Does the user need to provide a new credential/secret?
├─ NO → use it from storage, don't ask
└─ YES
   ├─ Is this a one-shot test or demo? → local input (process memory only)
   ├─ Will it be reused across sessions? → local input + persistent storage
   ├─ Is it part of initial setup (e.g., first-time credential creation)?
      ├─ Can the service generate it and display it once? → user sees it in browser, AI collects via local input
      ├─ Can the user generate it offline? → user provides via local input
      └─ Does it require user's real password or MFA? → acknowledge user must go to web UI first, then collect result via local input (not in chat)
   └─ Could the user reasonably enter it via local prompt? (most API keys, auth tokens, recovery codes → YES)
       → Use secure local input. Never ask for chat entry.

Common Patterns

Pattern 1: Collect API Key for a Service

Purpose: User wants to configure a service (e.g., OpenAI, Stripe, etc.)
Flow:
  1. Check: Does .env already have OPENAI_API_KEY? If yes, use it.
  2. If not: Open a local prompt titled "Secure Input - OPENAI_API_KEY"
  3. User pastes their key (masked).
  4. Write to .env: OPENAI_API_KEY=<value>
  5. Write to credential manager if long-term: item named "OpenAI API Key" with the value.
  6. Print: "✓ API key configured. Using local environment variable OPENAI_API_KEY."
  7. Do not print the key itself.

Pattern 2: Unlock a Credential Manager

Purpose: AI needs to access stored secrets (e.g., Bitwarden, 1Password) but the vault is locked.
Flow:
  1. Open a secure prompt or unlock window (native to the credential manager).
  2. Collect the master password or passphrase (masked).
  3. Authenticate to the vault (process-local, no chat).
  4. Proceed with downstream access.
  5. Print: "✓ Vault unlocked. You have N credentials available."
  6. Do not print the master password.

Pattern 3: Collect a Recovery Code

Purpose: User needs to save a recovery code or MFA backup.
Flow:
  1. Explain: "I can store your recovery code securely in your credential manager."
  2. Open a local prompt titled "Secure Input - Recovery Code"
  3. User pastes the code (masked in entry, but visible as bullets/dots).
  4. Write to credential manager with a clear label (e.g., "Service XYZ Recovery Code - YYYY-MM-DD").
  5. Print: "✓ Recovery code saved to your credential vault under 'Service XYZ Recovery Code'."
  6. Do not print the code itself in chat or logs.

Implementation Notes

• Cross-platform: PowerShell (Read-Host -AsSecureString) on Windows, read -s in bash on Unix/macOS, native prompts in applications.
• Avoid assumptions: Do not assume the value already exists; verify first. Do not assume which credential manager the user prefers; ask or check their setup.
• Privacy by default: Every secret collection should feel intentional and secure to the user. If they see a local prompt pop up, they should immediately understand why.
• Audit trail: Log the collection event (e.g., "collected API key for service X on YYYY-MM-DD") without logging the value. Use metadata only.

Related Concepts

• Token and credential rotation — periodic updates to API keys and authentication secrets to reduce exposure risk.
• Credential manager setup — initializing and configuring password managers (Bitwarden, 1Password, KeePass, macOS Keychain, Windows Credential Manager) to store and retrieve secrets securely.