---
name: avizmarlon/secure-secret-input
source: https://app.decimal.ai/s/avizmarlon-secure-secret-input@1/SKILL.md
source_sha256: db69831defb6
---

# 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.

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

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

4. **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

5. **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.**

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

7. **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.