Back to skill

Security audit

1password

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent 1Password CLI helper, but its examples encourage exposing secrets in terminal output and local files without enough safeguards.

Review before installing. This skill is not showing hidden exfiltration or destructive behavior, but users should avoid copying examples that print secrets, disable masking, capture secret-bearing terminal panes, or write keys/configs into the working directory unless they deliberately need that and apply strict file permissions and cleanup.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Error
Location
references/cli-examples.md:8
Finding
Plaintext Secret Disclosure Through Terminal Output and Insecure File Persistence## Vulnerability Details **File Location**: `references/cli-examples.md`, lines 8-21 **Vulnerability Type**: Plaintext sensitive-data exposure and insecure secret persistence **Risk Level**: High ### Vulnerable Code ```bash - `op read op://app-prod/db/password` - `op read "op://app-prod/db/one-time password?attribute=otp"` - `op read "op://app-prod/ssh key/private key?ssh-format=openssh"` - `op read --out-file ./key.pem op://app-prod/server/ssh/key.pem` ## 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 - `echo "db_password: {{ op://app-prod/db/password }}" | op inject` - `op inject -i config.yml.tpl -o config.yml` ``` ### Technical Analysis The documented examples resolve sensitive 1Password references and expose the resulting plaintext through standard output or ordinary files: - `op read` prints passwords, one-time passwords, and private keys directly to the terminal. - `op run --no-masking` explicitly disables 1Password's output masking and then prints the resolved database password. - `op read --out-file ./key.pem` writes a private key to the current directory without requiring restrictive permissions or cleanup. - `op inject -o config.yml` creates a persistent configuration file containing resolved secrets. - Piping an injected password to standard output can place it in terminal scrollback, automation output, or Agent transcripts. This behavior conflicts with the guardrails in `SKILL.md`, particularly the instructions not to place secrets in logs or chat and to prefer mechanisms that avoid writing secrets to disk. The required tmux workflow also uses `capture-pane`; if a secret-producing example is executed before pane capture, the plaintext can be copied into tool output or an Agent-visible transcript. ### Attack Path 1. The Agent follows one of the documented read, run, ...[truncated 1311 chars]
Remediation
## Remediation Suggestions 1. Remove examples that print resolved passwords, OTPs, or private keys to standard output. 2. Remove `--no-masking`; retain 1Password's default masking protection. 3. Demonstrate `op run` by passing secret-backed environment variables directly to a trusted application rather than using `printenv`, `echo`, or similar output commands. 4. Do not capture tmux panes after commands that may emit secrets. Separate authentication verification from secret-consuming operations and capture only known non-sensitive output. 5. Avoid persistent output files wherever possible. Prefer passing injected data directly to the intended process through standard input or an ephemeral protected channel. 6. If writing a secret-bearing file is operationally necessary: - Obtain explicit user confirmation. - Use a user-selected safe destination. - Set `umask 077` before creation. - Enforce file mode `0600`. - Avoid shared or predictable temporary paths. - Document secure deletion and perform cleanup immediately after use. 7. Warn users that generated configuration files, private keys, shell output, terminal scrollback, and automation logs may contain plaintext secrets. 8. Add a validation rule prohibiting secret-producing commands from being combined with `capture-pane`, logging, debugging output, or transcript collection.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (5)

Env Variable Harvesting

High
Category
Data Exfiltration
Content
## 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
Confidence
98% confidence
Finding
`op run --no-masking -- printenv DB_PASSWORD` intentionally prints the resolved secret value to stdout with masking disabled, which can expose credentials in terminal scrollback, logs, CI output, shell history capture, or monitoring systems. In the context of a 1Password CLI skill, this is especially dangerous because it normalizes revealing secret material as a usage example.

Env Variable Harvesting

High
Category
Data Exfiltration
Content
- `export DB_PASSWORD="op://app-prod/db/password"`
- `op run --no-masking -- printenv DB_PASSWORD`
- `op run --env-file="./.env" -- printenv DB_PASSWORD`

## Inject
Confidence
90% confidence
Finding
`op run --env-file="./.env" -- printenv DB_PASSWORD` demonstrates printing a secret-loaded environment variable to stdout, which can leak credentials to logs, terminal history, or CI output even without `--no-masking`. Although this appears instructional rather than malicious, it still encourages direct disclosure of secrets.

Credential Access

High
Category
Privilege Escalation
Content
- `export DB_PASSWORD="op://app-prod/db/password"`
- `op run --no-masking -- printenv DB_PASSWORD`
- `op run --env-file="./.env" -- printenv DB_PASSWORD`

## Inject
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The examples show secrets being written or rendered into local files, such as exporting a private key to ./key.pem and injecting secrets into config.yml, without any warning about filesystem exposure, permissions, cleanup, or accidental commits. In a secrets-management skill, this is risky because users may copy these commands verbatim and persist sensitive material in plaintext on disk.

Unrestricted Tool Access

Medium
Category
Excessive Agency
Content
- 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`.
Confidence
80% confidence
Finding
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.

Static analysis

No suspicious patterns detected.