KeyZero with 1Password

1Password is one of the most widely adopted credential managers for development teams. KeyZero integrates directly with 1Password through the op CLI, letting you reference secrets stored in 1Password vaults and resolve them at runtime -- without copying values into .env files or hardcoding them in config.

Why Use KeyZero on Top of 1Password

1Password already provides secure storage and team sharing. KeyZero adds a runtime layer that makes 1Password secrets usable in contexts where the op CLI alone falls short:

• Blind mode for AI agents: When running LLM-based agents, KeyZero injects opaque tokens instead of real secrets. A local MITM proxy swaps tokens for real 1Password credentials at the network edge, so the agent process never sees the actual value. See blind mode explained for the full mechanics.
• Policy-based access control: KeyZero's PDP server evaluates CEL policies against JWT-verified identities before resolving any secret. You can restrict which services, environments, or CI jobs can access specific 1Password items.
• Multi-backend unification: Teams often use 1Password for shared credentials alongside AWS Secrets Manager for infrastructure secrets and Vault for service tokens. A single .keyzero.toml maps all of them into one resolution flow.
• Shell hooks: KeyZero auto-loads secrets when you cd into a project directory, so developers get 1Password secrets without running op run or eval $(op signin) manually.

Prerequisites

Install the 1Password CLI (op) and KeyZero:

# 1Password CLI
brew install 1password-cli

# KeyZero
brew install getkeyzero/tap/keyzero

Authenticate the CLI. For interactive developer use:

op signin

For CI/CD and non-interactive environments, set a service account token:

export OP_SERVICE_ACCOUNT_TOKEN="your-service-account-token"

Verify the CLI works:

op item list --vault Engineering

Bundle Configuration

Define a 1Password backend in your KeyZero bundle and attach resolvers to it. The backend type is onepassword_cli, and each resolver references an item name and field within 1Password.

backends:
  team-vault:
    type: onepassword_cli
    vault: Engineering

resolvers:
  - name: openai-key
    mode: direct
    backend: team-vault
    path: "OpenAI API Key"
    field: credential

  - name: db-password
    mode: direct
    backend: team-vault
    path: "Production Database"
    field: password

The vault field on the backend is optional. If set, KeyZero adds --vault Engineering to every op item get call. If omitted, op searches across all vaults the authenticated identity can access.

How Resolution Works

When you run kz run -- node server.js, KeyZero executes:

op item get "OpenAI API Key" --vault Engineering --fields credential --format json

It extracts the value from the JSON response and injects it as the mapped environment variable. The op process runs locally -- credentials never pass through a KeyZero-hosted service.

Team Workflows

Developer Machines

Each developer signs in with their own 1Password account. Because KeyZero calls op locally, each person resolves secrets through their own permissions. No shared tokens, no service accounts on laptops.

# One-time setup
op signin
# Then just use kz
kz run -- npm start

CI/CD Pipelines

Use a 1Password service account token scoped to the vaults your pipeline needs:

# GitHub Actions example
env:
  OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}

steps:
  - run: kz run -- npm test

Service account tokens are scoped to specific vaults and have their own audit trail in 1Password, which pairs well with KeyZero's policy layer for defense-in-depth.

AI Agent Workloads

For AI agents that need access to authenticated APIs, combine 1Password with blind mode:

kz run --blind -- python agent.py

The agent receives kz_masked_7f3a9b... instead of the real API key. Outbound HTTP requests pass through KeyZero's local proxy, which replaces the masked token with the actual 1Password-sourced credential. The agent never holds the real value in memory.

Migrating From op run

If you already use op run to inject secrets:

# Before
op run --env-file=.env -- node server.js

# After
kz run -- node server.js

The KeyZero approach adds blind mode support, policy enforcement, and the ability to mix 1Password secrets with secrets from other backends in a single command. Your existing 1Password vault structure stays unchanged -- KeyZero reads from it, never writes. This migration path is part of the broader journey from hardcoded secrets to zero-knowledge.

When to Use This Integration

Use KeyZero with 1Password when you need any of the following: AI agent secret isolation via blind mode, CEL-based access policies across team members and CI, unified configuration that spans 1Password alongside cloud-native secret stores, or shell hooks that auto-resolve secrets per project directory. If you only need basic secret injection for a single developer, op run by itself works fine. For an even simpler local-only alternative, see the macOS Keychain integration. To understand how KeyZero resolves secrets at runtime instead of relying on static files, read about runtime secret resolution vs. env files.