T09 · Insecure Skill Coding Practices
- Location
references/cli-examples.md:8- Finding
Secret Disclosure Through Unsafe 1Password CLI Examples
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is for 1Password CLI use, but some included examples can expose real vault secrets in terminal output or plaintext files.
Review this skill carefully before installing. It is not evidence of a backdoor, but do not copy examples that print secrets, use `--no-masking`, capture secret output in tmux, or write keys/configs to ordinary working-directory files unless you have strict permissions and cleanup in place.
references/cli-examples.md:8Secret Disclosure Through Unsafe 1Password CLI Examples
op run --no-masking -- printenv DB_PASSWORD resolves a secret and then deliberately prints it, which is a direct secret disclosure pattern. The added --no-masking makes the example more dangerous by disabling a protective control and normalizing secret exposure during routine usage.
## Run
- `export DB_PASSWORD="op://app-prod/db/password"`
- `op run --no-masking -- printenv DB_PASSWORD`
- `op run --env-file="./.env" -- printenv DB_PASSWORD`
## Inject
These examples explicitly print a secret-derived environment variable, and one disables masking with --no-masking, making disclosure to the terminal, logs, CI output, shell history capture tools, or other observers much more likely. In the context of a 1Password CLI skill, demonstrating secret exfiltration to stdout without warning is especially risky because users may copy the pattern into automation.
op run --env-file="./.env" -- printenv DB_PASSWORD demonstrates harvesting a secret from the runtime environment and printing it to stdout. Even without --no-masking, showing printenv against a secret variable encourages a disclosure workflow that can leak credentials in terminals, CI logs, and recorded sessions.
- `export DB_PASSWORD="op://app-prod/db/password"`
- `op run --no-masking -- printenv DB_PASSWORD`
- `op run --env-file="./.env" -- printenv DB_PASSWORD`
## Inject
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
- `export DB_PASSWORD="op://app-prod/db/password"`
- `op run --no-masking -- printenv DB_PASSWORD`
- `op run --env-file="./.env" -- printenv DB_PASSWORD`
## Inject
The example writes secret material directly to a local file (--out-file ./key.pem) without any warning about filesystem exposure, permissions, shell history, backups, or cleanup. In a secrets-management skill, omitting handling guidance can lead users to persist sensitive keys in insecure locations or with overly broad permissions.
The inject examples produce secret-populated output either to stdout or to a concrete config file, but provide no warning that the resulting data is now plaintext secret material. That can cause accidental exposure through terminal logs, insecure file permissions, source control, artifact uploads, or long-lived config files.
Skill grants unrestricted tool access without appropriate constraints. An agent with unfettered tool access can perform arbitrary actions including file modification, network requests, and code execution.
- macOS: Settings > Developer > Integrate with 1Password CLI (Touch ID optional).
- Windows: turn on Windows Hello, then Settings > Developer > Integrate.
- Linux: Settings > Security > Unlock using system authentication, then Settings > Developer > Integrate.
- After integration, run any command to sign in (example in docs: `op vault list`).
- If multiple accounts: use `op signin` to pick one, or `--account` / `OP_ACCOUNT`.
- For non-integration auth, use `op account add`.
No suspicious patterns detected.