Security & 1Password Integration
Relevant source files
The following files were used as context for generating this wiki page:
The Security & 1Password Integration framework within IDAHO-VAULT establishes a multi-layered defense mechanism designed to protect journalistic research, sensitive credentials, and personal data. Its primary purpose is to ensure that while the repository remains public, all internal secrets and private identifiers remain strictly externalized or encrypted. The system operates on the principle that "Privacy is a hard gate," employing a combination of automated scanning, secret management, and strict data classification protocols.
This integration centralizes credential management via 1Password, utilizing the 1Password CLI for both local development and GitHub Actions automation. By externalizing secrets, the project mitigates the risk of accidental exposure in git history, which is treated as an "append-only" public record where mistakes cannot be easily undone.
1Password Centralized Management
All high-entropy credentials, including API keys, tokens, SSH keys, and passwords, are managed through 1Password. This prevents secrets from being hardcoded in workflows or stored directly in GitHub Secrets, with the single exception of the OP_SERVICE_ACCOUNT_TOKEN used to bridge the environments.
Implementation Architecture
The integration utilizes different 1Password features depending on the environment:
- Developer Machines: Uses the 1Password CLI and SSH agent for local authentication and git signing.
- GitHub Actions: Employs a service account token to fetch secrets at runtime via the
op item getcommand. - Masking: Workflows are required to use
::add-mask::to prevent credentials from appearing in execution logs.
Sources: VAULT-CONVENTIONS.from-pushable-2026-05-08.md:387-410, SECRET-SCANNING-REPORT.md:12-16
Secret Inventory and Rotation
The project tracks its secret inventory and rotation schedules within specialized documentation located in the .op/ directory.
| Component | Purpose | File Reference |
|---|---|---|
| Installation Guide | Setup for developers | .op/SETUP.md |
| Secret Inventory | Schedule and inventory | .op/secrets.template.md |
| Automation | Secret fetching workflow | .github/workflows/1password-secret-template.yml |
Sources: VAULT-CONVENTIONS.from-pushable-2026-05-08.md:412-418, SECRET-SCANNING-REPORT.md:46-51
Secret Scanning Pipeline
The vault employs a "belt-and-suspenders" approach to secret scanning, running multiple tools to detect high-entropy strings and known credential patterns before they reach the main branch.
Automated Scanning Tools
The system leverages three primary scanning layers:
- Repository Script (
check_secret_patterns.py): A custom Python script that runs daily and on-demand via GitHub Actions. It reports file paths and rule names without exposing the secret values. - Third-Party Scanners:
detect-secretsandtruffleHogare used for comprehensive git history scanning and backup verification. - GitGuardian: An external service providing a secondary layer of real-time scanning.
Sources: SECRET-SCANNING-REPORT.md:20-33, Tappet.md:47-51
Data Flow for Secret Validation
The following diagram illustrates how the vault validates that no secrets enter the public record during the commit and PR process.
This diagram shows the multi-stage validation process from local commit to CI merge gates.
Sources: SECRET-SCANNING-REPORT.md:12-30, Tappet.md:47-52, Sieve.md:38-42
Privacy and Data Classification
The vault enforces a strict decoupling of identity and data residency through its Privacy Protocol. Because the repository is public, git history is treated as "permanently visible to the internet."
Data Classes
Data is strictly categorized to prevent PII (Personally Identifiable Information) from being committed:
- Ephemeral (Query-Only): Data read from external services (Gmail, Calendar, Slack) that lives only in session memory and is never written to disk.
- Persistent (Vault-Committed):
- Public-Persistent: Tracked files in git. Limited to sanitized aggregates and public-record information.
- Local-Persistent: Files in
.gitignore(e.g.,_private/,.remember/). These are used for working notes but are never pushed to GitHub.
Sources: PRIVACY.md:16-52, VAULT-CONVENTIONS.from-pushable-2026-05-08.md:493-500
Sanitization Protocol
When moving data from private sources into tracked vault files, agents must follow a four-step sanitization process:
- Strip Identity: Remove names of non-public figures.
- Strip Attribution: Paraphrase positions rather than using direct quotes.
- Strip Metadata: Remove timestamps or location details that could identify private meetings.
- Logan Reviews: The human owner must manually approve the sanitized draft.
Sources: PRIVACY.md:95-115
Vulnerability Reporting
Security vulnerabilities in automation scripts or workflows are handled through a private disclosure process rather than public GitHub issues to prevent exploitation.
- Contact: @loganfinney27
- Required Info: Description, reproduction steps, and potential impact.
- Timeline: Acknowledgment within 72 hours.
Sources: SECURITY.md:25-45
Summary
The Security & 1Password Integration serves as the vault's immune system, ensuring that journalistic sources and personal credentials are never exposed. By combining 1Password's external secret management with multi-stage CI scanning and a strict sanitization protocol, the IDAHO-VAULT maintains high operational transparency without compromising individual or source privacy.