T09 · Insecure Skill Coding Practices
- Location
references/auth-setup.md:23- Finding
Insecure API Credential Acquisition and Storage Workflow
- Content
View full analysis
Vulnerability Details
File Location:
references/auth-setup.md:23-24,references/auth-setup.md:60-62,references/auth-setup.md:109-110, andreferences/auth-setup.md:162-169
Vulnerability Type: Insecure handling and persistence of sensitive credentials
Risk Level: MediumVulnerable Code Snippets
references/auth-setup.md:23-24:text > Do you have a TranscriptOut key already? Paste it and I'll wire it up. If not, give me an email > address and I'll open a free account for you: 100 credits included, no card asked.references/auth-setup.md:60-62:text **Pipe the response into a temporary file and build the next request by reading the token out of that file. Never echo the token on its own.** Several agent runtimes scrub anything shaped like `access_token` or a bearer token from tool output before the model sees it, so a printed tokenreferences/auth-setup.md:109-110:text Same discipline as before: **response into a file, key read out of the file**, because `sk_`-prefixed values get scrubbed from tool output by the same runtimes.references/auth-setup.md:162-169:text Store it persistently using whatever method is correct for this environment (which you determined in Step 0). Make sure it will be available in future sessions, including non-interactive shells, without any manual sourcing step from the user. Once stored, verify it is accessible in the current session. If the session needs a reload or restart to pick up the new value, do that or tell the user to do it. Delete the temporary files this process created.Technical Analysis
The setup workflow instructs the user to paste a long-lived API key into the ordinary conversation channel. This exposes the credential to any systems that retain or process conversation history and bypasses secure secret-entry mechanisms that may be available in the Agent runtime.
During account registration and verification, raw HTTP responses containing a ...[truncated 3225 chars]
- Remediation
View remediation
Remediation Suggestions
-
Use a dedicated secret-entry mechanism
- Prefer the Agent runtime’s protected environment-variable or secret-input interface.
- Do not ask users to paste API keys into ordinary chat when protected input is available.
- Recommend browser-based account creation and key management where the runtime cannot securely capture secrets.
-
Require an approved secret store
- Persist the key only in an operating-system keychain, encrypted credential manager, or runtime-managed secret store.
- Explicitly prohibit storage in shell history, command-line arguments, ordinary project files, world-readable configuration files, and plaintext shell profiles.
- Grant access only to the user and runtime identity that need the credential.
-
Harden temporary-file handling
- Avoid storing complete token-bearing responses when direct protected parsing is possible.
- If a temporary file is unavoidable, create a private directory with permission
0700and files with permission0600. - Use an atomic secure temporary-file API that generates unpredictable names and refuses symbolic links.
- Set a restrictive
umask, such as077, before file creation. - Register cleanup traps before making network requests so files are removed on success, failure, interruption, and cancellation.
- Store only the minimum required field rather than the complete HTTP response.
-
Prevent secondary disclosure
- Disable command tracing while handling credentials.
- Ensure secrets are not written to logs, diagnostic output, shell history, telemetry, backups, or synchronized folders.
- Never print the API key or access token during verification.
- Redact credentials from errors and support artifacts.
-
Limit credential lifetime and authority
- Use narrowly scoped keys if the service supports scopes.
- Document key rotation and immediate revocation procedures.
- Avoid indefinite persistence where session ...[truncated 398 chars]
-