T09 · Insecure Skill Coding Practices
- Location
references/cli-examples.md:18- Finding
Plaintext Secret Disclosure Through Disabled Output Masking
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent 1Password CLI helper, but some examples can expose passwords, OTPs, or keys in terminal output, so it needs review before installation.
Install only if you are comfortable letting the agent operate an authenticated 1Password CLI session. Treat the reference examples as unsafe: do not print secret values, disable masking, capture panes containing secrets, or write private keys/configs to ordinary files unless you have explicitly requested it and can protect the output. Prefer commands that pass secrets directly to the consuming program and confirm each secret read or injection target.
references/cli-examples.md:18Plaintext Secret Disclosure Through Disabled Output Masking
The example op run --no-masking -- printenv DB_PASSWORD intentionally causes a resolved secret to be emitted in plaintext to stdout, and --no-masking removes a key safety control designed to reduce accidental disclosure. In practice, this can expose credentials to terminal scrollback, CI logs, shell recording, monitoring tools, or other users on shared systems.
## 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
The example op run --env-file="./.env" -- printenv DB_PASSWORD demonstrates resolving a secret into an environment variable and then printing it, which directly discloses sensitive material. Even without --no-masking, teaching users to echo secret-bearing environment variables normalizes a leakage pattern that is especially risky in CI/CD, shared shells, and audited environments.
- `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 examples explicitly show secrets being read to stdout and written to local files without any cautionary guidance, including plaintext output of passwords, OTPs, SSH keys, and key material written to disk. In a secrets-management skill, this is dangerous because users commonly copy examples verbatim, which can leak credentials into terminals, shell history, logs, process capture, or insecure filesystem locations.
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.