sop_id: SOP-OPS-credential-management version: v1.0 status: Draft owner: security.ops executive_sponsor: coo effective: TBD (pending COO approval) approved_by: pending department: operations priority: P2 references: - security/credential-rotation-guide-v1.0.md (operational how-to) - CLAUDE.md Section 10 (SOP Governance) - CLAUDE.md Section 11 (Escalation Framework) - CLAUDE.md Section 6E (SOP Delta / Incident Report) - 1Password vaults: Development + Production ratified_policy: "1Password only / no plaintext credentials" — CEO Rick Hartley, 2026-04-20 tags: [sop, operations, credentials, security, 1password, governance]
SOP-OPS-credential-management-v1.0¶
1. Purpose¶
Establish governance rules for how credentials and API tokens are stored, accessed, rotated, and audited across the eco|monetize™ operating system. This SOP codifies the 1Password-only / no plaintext credentials policy ratified by CEO on 2026-04-20.
Relationship to the credential rotation guide: This SOP governs the what and who — what must be in 1Password, who owns it, what auditing runs. The operational how-to-rotate procedure lives in /Claude/system/sops/security/credential-rotation-guide-v1.0.md and is cross-referenced here, not duplicated.
2. The 1Password-Only Policy¶
Policy (CEO-ratified 2026-04-20): All credentials, API keys, tokens, secrets, and passwords used by any eco|monetize™ agent, script, or integration must be stored in 1Password. Plaintext storage in files, environment variables not sourced from 1Password, or any other mechanism is prohibited.
What counts as a credential¶
- API keys and tokens (all vendors)
- OAuth client secrets
- Database passwords and connection strings
- SSH private keys
- Service account credentials
- Webhook secrets
- Any value that authenticates a system or authorizes access
What does NOT require 1Password storage¶
- Public keys, public client IDs, anon keys (non-secret by design)
- Internal-only config values that carry no auth weight (e.g., a local port number)
- Values already governed by platform-native secret stores (e.g., Supabase anon key tied to project JWT — rotated by Supabase, not stored redundantly)
3. Vault Structure¶
| Vault | Purpose | Who has access |
|---|---|---|
| Development | All non-production credentials and test tokens | Rick + active agent sessions via op CLI |
| Production | Production-only credentials (when production systems go live) | Rick only until production access policy is defined |
All agents access credentials via the op CLI: op read "op://VAULT/ITEM_NAME/credential" or op run --env-file.
No agent stores a credential value in its session context, memory file, or any vault artifact. Agents invoke op read at runtime; they do not cache the returned value.
4. Credential Ownership¶
Each credential has a named owner responsible for rotation and audit:
| Owner | Credential scope |
|---|---|
| security.ops | All API keys, tokens, and secrets used by scripts and integrations |
| coo (Morgan) | Vendor contract credentials (Salesforce, legal tools) |
| cdo (Dave) | Platform infrastructure credentials (Supabase, GitHub org tokens) |
| CEO (Rick) | Personal OAuth clients, SSH keys, anything requiring individual account access |
When a credential owner changes agents (e.g., after role restructuring), the outgoing agent files a Section 6C Handoff Report naming the credential items being transferred, and the receiving agent verifies op read access before the handoff is closed.
5. Rotation Schedule¶
Rotation cadence is defined in security/credential-rotation-guide-v1.0.md. Summary:
| Cycle | Scope |
|---|---|
| 90 days | All rotatable API keys and tokens (Airtable, Anthropic, OpenRouter, OpenAI, GitHub PAT, Make.com, Apollo, Supabase service token + password) |
| On compromise | Immediate rotation of any credential suspected or confirmed leaked |
| Never (permanent) | Salesforce Connected Apps, Google OAuth clients, Supabase anon key, SSH key — rotate only on compromise |
Rotation trigger authority: security.ops initiates scheduled rotations. CEO or COO can trigger an emergency rotation for any credential at any time.
6. Compliance Auditing¶
Quarterly audit (security.ops)¶
Every quarter, security.ops runs a credential hygiene sweep:
- Plaintext scan — grep the vault for known credential patterns (key formats, token prefixes) to detect any that escaped 1Password. Commands defined in
credential-rotation-guide-v1.0.md"Hardcoded Credentials to Remove" section. - 1Password inventory check — confirm all credentials tracked in
Airtable → Operations Intelligence Hub → Credential_Registryhave a corresponding 1Password item. - Rotation currency — confirm no credential is past its rotation due date.
- Access review — confirm no retired agents or scripts retain active credentials.
Quarterly audit report filed to /Claude/operations/reports/security/credential-audit-{YYYY-QN}.md.
Post-rotation verification¶
After every rotation cycle, the checklist in credential-rotation-guide-v1.0.md "After Rotation Checklist" is completed and a one-line log entry added to Airtable → Credential_Registry (Last Rotated field).
7. Incident Response¶
| Scenario | Action |
|---|---|
| Credential exposed in plaintext (found in file, log, or agent output) | Immediate rotation + Section 6E Incident (SEV2) + scrub audit |
| Credential confirmed leaked (external exposure) | Immediate rotation + Section 6E Incident (SEV1) + CEO notification + vendor notification if required |
| Rotation overdue >7 days | security.ops self-files SEV3, escalates to COO |
| Agent found caching credential in session context | Section 6E Incident (SEV2), chief.staff review of agent contract |
All incidents route through CLAUDE.md Section 11 Escalation Framework.
8. New Credential Onboarding¶
When a new integration or vendor requires credentials:
- security.ops creates the 1Password item before the credential is issued
- Credential issued directly into 1Password — never to a plaintext file
Airtable → Credential_Registryrecord created with: vendor, vault, item name, owner, rotation cycle, date created- Agent or script updated to use
op read/op run— never hardcoded reference
No integration goes live without confirmed 1Password storage.
Change Log¶
| Version | Date | Change |
|---|---|---|
| v1.0 | 2026-04-21 | Initial draft — sop.manager. Codifies CEO-ratified 1Password-only policy (2026-04-20). Cross-references credential-rotation-guide-v1.0.md for operational how-to. |
Owner: security.ops Executive sponsor: coo Drafted by: sop.manager Status: Draft — pending security.ops review + COO approval Version: v1.0