Human approval
Passkeys gate the operator surface. No shared password. No magic link.
00 / Operator-approved credentials for agents
BitterPass is for teams whose agents touch production APIs, cloud consoles, billing systems, and internal control planes. It replaces broad service accounts, copied env vars, and unauditable bot access with human approval, per-run scope, and replayable audit.
Passkeys gate humans. Ed25519 identities gate runners. The service stores ciphertext, metadata, and audit instead of a vendor-held root secret.
Human approval
Passkeys gate the operator surface. No shared password. No magic link.
Runner isolation
Each runner uses its own Ed25519 identity and receives one scoped bundle per run.
Replayable audit
Reads, writes, and rotations land in a hash-linked chain you can inspect later.
01 / Operating contract
If you are looking for a generic secret manager, this is the wrong shape. BitterPass is for operators who need a human to approve access and a runner to receive only what that run should see.
Operator in the loop
BitterPass is for environments where a human still needs to approve access, even if an agent does the work afterward.
Scoped machine access
A runner receives the material for that run, not a permanent token that quietly becomes infrastructure.
Ciphertext on the service
The service stores envelopes, metadata, and audit. The root secret stays with the operator, not the vendor.
02 / How the trust works
The plaintext lives only between the operator-controlled secret material and the run that needs it. Everything in between is passkeys, signatures, ciphertext, and audit.
01
WebAuthn gates the human console. A successful ceremony returns an HttpOnly session and nothing reusable in a URL.
02
Records arrive as ciphertext envelopes with audit metadata. Storage and sync work without asking the service to hold plaintext.
03
A runner authenticates with its own Ed25519 identity and receives only what that run should see.
03 / System surface
The primitives should feel familiar. The product discipline shows up in the split between operator access, runner access, and what the service is allowed to hold.
Operator console
Passkey auth, pairing approval, audit review, and metadata-only visibility.
Runner surface
Signed requests from enrolled runner identities instead of a shared bearer token.
Service posture
Ciphertext, metadata, and recovery artifacts only. No vendor-held root secret.
04 / Who this is for
The audience is not “anyone with secrets.” It is operators and technical teams who already know that env vars, copied tokens, and broad service accounts were only a temporary truce.
Agent operator
You need a narrower credential surface than env vars, shell history, and one service account that quietly becomes immortal.
Platform or security team
The operator approves the pairing and the runner gets a scoped bundle. That is a different control model than generic app config.
Small technical team
Passkeys for people. Ed25519 identities for runners. Recovery that does not depend on a vendor holding the root of trust.
05 / FAQ
BitterPass is the authority surface for agent credential lifecycle receipts. Other systems can observe or link to those receipts, but they do not become the source of truth for issuance, expiry, revocation, or audit state.
No. BitterPass is for operator-approved agent access: scoped bundles, expiry, revocation, and receipts for runs that touch real systems.
No. Enrolled runner identities request scoped material for a run. Access is bounded by the operator-approved scope and lifecycle state.
BitterPass owns approval, issuance, expiry, revocation, and audit receipts. Factory, Grid, Hub, and marketing surfaces can link to that truth but do not become the authority.
The marketing site explains the contract. Detailed CLI commands, pairing steps, and recovery material travel only with approved invitations.
05 / Access
Tell us what your agents touch, what approval step still needs a human in the loop, and what credential pattern you are trying to replace.
Good fit
Your agents touch production APIs, cloud consoles, billing systems, or internal control planes.
You are replacing
Broad service accounts, copied env files, or a CI secret surface that has outgrown its original trust assumptions.
You care about
Human approval, narrower runner scope, and a replayable audit trail for what an agent actually touched.
What happens next
01
Fit review
The request is manual on purpose. We want to know what your agents touch, which approval step still needs a human, and what credential pattern you are trying to replace.
02
Invitation path
The invitation carries the console URL, the current CLI setup path, pairing steps, and the runner-enrollment walkthrough. Public marketing stays high-level by design.
03
Request and support route
Use BitterDesk for the first request and for follow-up if the invite never lands or the first pairing run stalls. An operator can look at the request and the onboarding state.