Human approval
Passkeys gate the operator surface. No shared password. No magic link.
00 / CLI and MCP credential handles
BitterPass is for teams whose agents and MCP tools 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, revocation, and receipts.
Passkeys gate humans. Ed25519 identities gate CLI and MCP runners. The approved onboarding path proves the custody boundary before a runner receives production credential material.
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 receipts
Approvals, scoped pulls, expiry, and revocation leave receipts an operator can review 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.
Custody proof before use
The public contract is sealed state, metadata, and audit. Approved onboarding must prove which material stays operator-held before a runner uses it.
02 / How the trust works
The product contract is not "trust the marketing page." It is a bounded onboarding proof: operator approval, runner identity, scoped material, and receipts before the first production pull.
01
WebAuthn gates the human console. A successful ceremony returns an HttpOnly session and nothing reusable in a URL.
02
Public marketing keeps the claim narrow: BitterPass is built around sealed state, metadata, and audit. The approved onboarding path proves which material is operator-held before any runner receives a bundle.
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
Sealed state, metadata, audit receipts, and an onboarding proof for what the service can and cannot hold.
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. A custody proof before production credential material enters a pilot.
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.