Files
claudetools/.claude/memory/feedback_1password_service_token.md
Mike Swanson 7128b9e57d Session log: cPanel CVE-2026-41940 IOC scan + remediation on IX/WebSvr
Both servers were already patched (11.110.0.97 and 11.134.0.20) via
daily auto-update. IOC scan found 16 flagged sessions across both
plus 4 uncommented SSH keys on IX.

Critical remediation:
- Forensic evidence preserved before any deletion
- 4 uncommented SSH keys removed from IX (server-side backup retained)
- 16 flagged sessions purged across both servers
- Root passwords rotated via chpasswd
- New WHM API tokens created; 3 stale transfer-* tokens revoked
- Vault entries + 1Password Infrastructure items updated

Forensic deep-dive verdict: patch held. All 7 actual CVE exploit
attempts (botnet IPs hitting /json-api/version) returned HTTP 403.
The "multi-line pass" IOC hits on user sessions were false positives.
Unidentified 76.18.103.222 root session traced to routine SSL
maintenance (zero sensitive endpoints touched).

Skill hardening:
- Added MANDATORY service-token directive to .claude/commands/1password.md
  enforcing OP_SERVICE_ACCOUNT_TOKEN from SOPS for all op CLI calls
- Per Mike: memory files alone don't reliably bind agent behavior;
  baking governance into skill content loaded at moment of use.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-30 07:22:52 -07:00

1.6 KiB

name, description, type
name description type
1Password — always use service account token Use the SOPS-vaulted OP_SERVICE_ACCOUNT_TOKEN for all op CLI calls; the desktop-app integration prompts are unacceptable in agent flows feedback

For every op CLI invocation, source OP_SERVICE_ACCOUNT_TOKEN from infrastructure/1password-service-account.sops.yaml first. Without it, op falls back to the desktop-app integration which interrupts the workflow with "unlock the app" prompts.

Why: Mike confirmed 2026-04-30 — "the prompts are infuriating." Service account auth is the standard CI/agent pattern documented in the 1password skill but I had been defaulting to the desktop session.

How to apply:

SVC_TOKEN=$(sops -d /c/Users/guru/vault/infrastructure/1password-service-account.sops.yaml 2>/dev/null \
  | grep -E '^\s*credential:' | sed -E 's/^\s*credential:\s*//' | head -1)

# Pass through env var to every op call
OP_SERVICE_ACCOUNT_TOKEN="$SVC_TOKEN" op item get ...
# Or export once at the top of a script
export OP_SERVICE_ACCOUNT_TOKEN="$SVC_TOKEN"

The vault.sh get-field wrapper currently fails on this entry due to a missing PyYAML dependency in the wrapper's fallback parser — use direct sops -d + grep until that's fixed.

Vaults the service account can see (per 2026-04-30 test): Clients, Infrastructure, Internal Sites, Managed Websites, MSP Tools, Projects, Sorting. (The Private vault is intentionally not shared with the service account.)

When to skip: Never. If the desktop session also happens to be authed, that's fine, but the service token path must be the one the agent reaches for.