1Password as the Trust Anchor for an Agent Auth Chain

#ainative #infrastructure #patterns #buildlog

TL;DR

1Password is the trust anchor, not just the store — M2M client secrets, TOTP seeds, and downstream API keys all originate in the vault and flow outward; nothing flows back in.
The agent acquires time-limited JWTs by reading the M2M secret from the vault at runtime; the secret is in memory for milliseconds, never written to disk.
TOTP enrollment is fully automatable: capture the raw secret via the IdP's "can't scan" fallback, store it as an OTP field, generate live codes with op item get --otp.
The human does three things: Touch ID at session start, approve tool calls with side effects, handle the few IdP UI steps that remain.
Use OIDC for AWS; use this chain for everything else.

The previous three posts in this series covered what 1Password replaces in a builder setup, what an agent can do operating the vault directly, and how service accounts work as credential infrastructure for autonomous workflows. This post is different. It's not about what the vault stores. It's about what the vault does — in a running system, at runtime, as an active participant in an authentication chain.

The specific chain: an agent session that needs to call a protected API, acquire time-limited tokens, handle MFA enrollment programmatically, and operate without any human credential-passing at any point. Every credential originates in 1Password. Every credential operation goes through the vault. The human approves the agent's tool calls — Touch ID, once, at session start — and then steps back.

This is the pattern. Here's how the vault fits in.

The setup

Any agent auth chain has the same three layers:

Credential store — where secrets live (1Password)
Authorization plane — where tokens are issued (OAuth/OIDC provider, e.g. Auth0)
Protected resource — the API or tool the agent calls

Typical credential surfaces in that stack:

M2M client secret — the agent needs this to acquire a bearer token
TOTP secret — enrolled during setup, needed to authenticate admin or break-glass accounts
Downstream API keys — seeded from the vault into whatever runtime store the service uses (Secrets Manager, env injection, etc.)

None of these should exist as plaintext files. None should be baked into the shell profile. They live in the vault and are resolved at runtime via op read, the 1Password SDK, or op run wrapping the process.

The auth chain, step by step

When an agent needs to call a protected API, this is what happens:

Step 1: Token acquisition

Code that actively manages its own credential lifecycle reads the M2M secret from the vault at runtime:

client_secret = subprocess.check_output(
    ["op", "read", "op://ACL/Auth0 M2M — my-agent/credential"]
).decode().strip()

Then it calls the provider's client-credentials endpoint, gets a JWT, caches it until expiry. The secret is in memory for milliseconds. It's never written to disk.

Alternatively, op run resolves the secret into the environment before the process starts — the tool reads os.environ["CLIENT_SECRET"] and never imports op.

Step 2: Authorization

The protected API receives the JWT. It validates issuer, audience, and whatever custom claims you stamped at token issuance (owner, agent_type, scopes). If validation passes, the request proceeds.

Step 3: Downstream secrets

Services that run in their own runtime (Lambda, containers, managed APIs) should not call 1Password on every request. Seed their secrets from the vault once, then let the service read from its native store:

API_KEY=$(op read "op://Personal/Some API/credential")
aws secretsmanager put-secret-value \
  --secret-id "$SECRET_ARN" \
  --secret-string "$API_KEY"

One-way flow: vault → runtime store. The running service never touches 1Password directly. 1Password stays the source of truth; the runtime store is a cache.

MFA enrollment without a human in the loop

During setup, many IdPs require MFA enrollment for admin accounts. The standard path: show a QR code, user scans it with an authenticator app, confirms with a code. Human-mediated, manual, one-time.

The AI-native path: the IdP offers a "can't scan" fallback that exposes the raw TOTP secret. The agent stores it in 1Password as an OTP field and generates codes on demand:

# Store the secret
op item edit "Auth0 — user@example.com" \
  "one-time password[otp]=otpauth://totp/Auth0:user%40example.com?secret=<SECRET>&issuer=Auth0"

# Generate a live code whenever needed
op item get "Auth0 — user@example.com" --otp

The --otp flag returns a valid 6-digit code, rotating every 30 seconds, computed from the stored TOTP secret. No phone. No separate authenticator app. The vault is the authenticator.

The human approves the agent storing the secret once. After that, the agent can satisfy MFA for that account without further involvement — as long as your policy allows it.

The break-glass account

The admin account (admin@yourdomain.com) exists for one reason: if the primary login path becomes unavailable, there needs to be a way in. The account has a generated password and its own TOTP enrollment, both stored in 1Password.

The agent-friendly workflow:

Generate a strong password using op item create --generate-password — the password originates in 1Password, never in the agent's context
Create the IdP user with that password, reading it back via op item get --reveal
When TOTP enrollment occurs, capture the secret and store it as an OTP field in the same vault item

The pattern: credentials are born in the vault. They flow outward to services. They never flow the other direction — services don't generate credentials that then get stored in 1Password as an afterthought. The vault is the source.

What the human actually does

Three things, all intentional:

Touch ID — approves the agent's access to the vault at session start. Once per session.
Tool call approvals — each agent tool call that has side effects gets an approval prompt.
IdP dashboard steps — some admin operations still require the provider's web UI. The agent can open the page; the human makes the clicks.

Everything else — token acquisition, credential reading, MFA code generation, secret seeding to runtime stores, vault organization — can run without interruption once policy is set.

The human is the policy layer. The agent is the execution layer. 1Password is the trust boundary between them.

The pattern that generalizes

This chain — agent → M2M token → protected API, with vault-sourced secrets and OTP-backed MFA — generalizes to any system where:

An agent needs to call APIs that require credentials
Those credentials need to be rotated, audited, or revoked independently of the workflows using them
MFA is required at setup but shouldn't require physical presence at every authentication

In all of these cases: vault holds the credentials, agent reads them at runtime (or op run injects them at launch), MFA secrets live as OTP fields, the human approves at the policy level not the execution level.

The alternative is credentials scattered across environment files, CI secrets stores, .env files in repos, and chat threads. Every SaaS API you add is another place where a credential lives outside the vault, outside the audit trail, outside the revocation path.

So what

The previous post ended with: OIDC for AWS, 1Password service account for everything else.

This post covers the auth chain role: 1Password is the trust anchor, your IdP is the authorization plane, and protected APIs are the resource layer. The agent doesn't carry credentials. It carries references. The vault is the one thing that requires human approval — Touch ID, once — and after that, the agent can authenticate to anything the vault covers.

That's the AI-native credential model. The next post covers what changes when you add people — and the one after that covers op run, which keeps the vault invisible to tools you didn't write.

This is the fourth post in a six-post series on 1Password as infrastructure. The fifth covers how the same pattern scales from solo builder to enterprise. The sixth covers op run — making any tool vault-transparent. Start from the first post.