What is PasskeyBridge?

PasskeyBridge is a hosted identity threat response service. Your application posts identity signals to it (a carrier SIM-swap alert, a credential-leak report, a suspicious login), and PasskeyBridge decides what happens next: it matches the signal against your playbooks, runs the response actions you configured, revokes the agent delegations and agent-to-agent negotiations that a hard signal invalidates, and stores the event.

It sits after your authentication provider and does not replace it. Sign-in stays where it is. PasskeyBridge is the layer that reacts when something about an identity changes.

Every signal is processed inside the request. Two timings are stored on the event row and shown in the Events tab: decision_ms, PasskeyBridge's own path (authenticate, resolve the organization, keyed-hash the identifier, match a playbook, decide), and response_ms, the whole request including outbound playbook actions.

Low-entropy identifiers (phone numbers, email addresses, IP addresses, CAEP subject identifiers) are hashed with keyed HMAC-SHA-256 under a server-held pepper before anything is stored, so a leaked digest column discloses equality between rows and nothing more. See Zero-PII compliance.

PasskeyBridge groups its features into three pillars. They are independent: an organization can use the first alone, and nothing in the second or third has to be configured for signal ingest to work.

Pillar I: network attestation. Post carrier and application signals to shield-ingest: SIM swap, port-out, device compromise, SS7 intercept, account takeover, credential leak, velocity and behavioral anomalies, or any custom event type you define. Carrier lookups are served through Vonage and Twilio (shield-carrier-lookup); any other provider reaches you through a plain webhook that your backend forwards to ingest. A matching playbook runs its actions: webhook callback, Slack message, email alert, audit log entry, and the internal state actions listed in Playbooks. Available on every plan.

Pillar II: verifiable credentials. Issue and verify W3C credentials with the built-in engine: JWT-VC and SD-JWT-VC, OpenID4VP presentation exchange, OID4VCI pre-authorized code flow, DID resolution (did:web, did:key), and StatusList2021 revoke, suspend and reinstate. Each organization signs with its own ECDSA key: P-256 (ES256) by default, P-384 (ES384) on the ML-DSA-87 tier, co-signed with ML-DSA (FIPS 204). Key rotation keeps the previous key valid for 24 hours so in-flight verifications still resolve.

Pillar III: biometric binding. FIDO2 and WebAuthn passkeys, either on PasskeyBridge's own relying-party origins or on your domain through the hosted relying party (shield-passkey-rp), plus social recovery through guardian approval.

What a hard signal revokes automatically. Inside the ingest request, a hard signal deactivates the organization's active agent delegates and revokes its active agent-to-agent negotiations. Passkey and credential revocation are not automatic: they happen when a playbook action or an API call asks for them. The wider four-subsystem cascade (delegates, negotiations, shadow identities, BLAST tunnels) runs from shield-cascade or from an inbound CAEP hard event, described in Cascade classification.

No plaintext personal identifier is stored, logged or emitted. Identifiers are reduced to a keyed HMAC-SHA-256 digest under a server-held pepper (_shared/identifier-hash.ts) before they reach the database. The pepper lives in the platform secret store, never in the database, and a missing pepper makes the hashing call throw rather than fall back to an unkeyed digest.

Keying matters because plain SHA-256 is not a privacy control for a small keyspace: every E.164 phone number can be enumerated, so an unkeyed digest column is reversible with a precomputed table. A keyed digest discloses only that two rows carry the same identifier.

• Raw values you send. Send phone and the server normalizes it toward E.164, keys it, and stores phone_hash with hash_version = 2. The raw number is never written.
• Pre-hashed values you send. Send phone_hash (exactly 64 hex characters) and it is keyed again under the server pepper before storage, as its own digest kind, and stamped hash_version = 2: the stored value is not the digest you sent, so a leaked column cannot be walked back to a number through the way you computed it. The callback envelope still carries the digest you sent, and a DSAR request accepts it. Rows written before 2026-09-18 hold the digest as sent at hash_version = 1; reads match both.
• Request metadata. Client IP addresses are keyed the same way before they reach the rate-limit and audit tables.
• CAEP and SSF subjects. An inbound subject identifier is keyed with its format bound into the message, so the same string under two formats yields unrelated digests.
• Anything reversible. Values that must be readable again (Slack webhook URLs, signing secrets, provider API keys, the raw inbound SET) are AES-256-GCM encrypted under the platform encryption key, never stored in the clear.

One field is deliberately stored as you send it: subject_ref, your own opaque correlation handle. It is echoed to your callback and never interpreted. The ingest validator refuses a value shaped like an email address, a phone number or a long digit run, which is a speed bump rather than a guarantee; send a handle that means nothing outside your own system.

Public traffic goes to https://api.passkeybridge.io/v1/ followed by the function name. A Cloudflare worker fronts every call and forwards only the function names on its allowlist; anything else answers 404 with x-pb-reason: unknown-function. Calling the Supabase functions host directly answers 403 "Direct access denied" for the functions that enforce the edge lock.

Routed at the public host today:

openapi-spec, shield-a2a-handshake, shield-agent-delegate, shield-agent-trust, shield-blast, shield-cached-proof, shield-carrier-lookup, shield-cascade, shield-chain-checkpoint, shield-client-errors, shield-cross-reference, shield-did-resolve, shield-dpop, shield-entropy-receipt, shield-health, shield-ingest, shield-ntp, shield-okta-hooks, shield-passkey-rp, shield-predict, shield-scim, shield-sdk-attestation, shield-shadow-proxy, shield-spatial-bind, shield-sse-caep, shield-supply-chain, shield-vc-issue, shield-vc-oid4vci, shield-vc-present, shield-vc-status, shield-vc-verify, plus stripe-webhook for Stripe and /v1/_debug/echo, which echoes back which headers reached the edge.

Everything else in the platform (the admin mutations behind the dashboard, the PII vault, DSAR, breakglass, the cron workers) is console-only: the dashboard calls it with your signed-in session, and it is not reachable at api.passkeybridge.io.

Authentication. Three lanes, per function:

A few endpoints need no credential at all: shield-did-resolve, shield-ntp, shield-health, openapi-spec and the public status reads.

Rate limiting. Per organization, per minute, from the plan: Starter 60, Pro 300, Enterprise 600. A specific number can be pinned on the organization row by support; left at 0 it takes the plan default. Over the limit the answer is 429 with X-RateLimit-Limit and X-RateLimit-Layer.

The machine-readable specification is at https://api.passkeybridge.io/v1/openapi-spec (OpenAPI 3.1, info.version 2.1.0).

These are gated to the Enterprise plan, either by a plan check in the function or by an Enterprise-only dashboard tab. The guide for each names which.

Agentic delegation. Scoped delegates for AI agents, each carrying a trust score between 0 and 1. Behavioral evaluation narrows scopes as the score falls and recommends revocation below the delegate's floor; a hard signal bypasses the score and revokes outright. Two delegates can negotiate bilateral trust over the A2A handshake.

BLAST tunnels. Encrypted transit for signals: X25519 key agreement, HKDF-SHA-256 derivation, AES-256-GCM payloads, with the salt drawn from a quantum entropy source and a database-backed session that can be torn down.

Post-quantum signing. ML-DSA-65 (level 3) by default and ML-DSA-87 (level 5) as an add-on, each paired with a classical ECDSA signature: P-256 with ML-DSA-65, P-384 with ML-DSA-87 so the pair matches CNSA 2.0. The tier is set per organization on the pqc_level column. This runs in production.

Provenance Guard. Three-channel device provenance: a sensor-derived atomic fingerprint, a kinematic check against orbital or carrier expectations, and a proximity quorum whose attestation carries an ML-DSA signature.

Cascade. Deterministic signal classification plus the four-subsystem parallel revocation, with a dry-run mode that counts what a signal would revoke.

Also Enterprise: shadow identity proxy, cached trust proofs for offline verification, deterministic cross-reference binding, AI threat intelligence with human review, identity posture scans across connected providers, entropy provenance receipts, supply-chain attestation, threat sharing, insider-threat analytics, the PII vault, SCIM provisioning and breakglass access.

PasskeyBridge has sixteen patent filings on file with the USPTO. All sixteen are applications. None has been granted, and nothing on this site should be read as claiming an issued patent.

Non-provisional utility applications (6), pending examination:

• 19/553,357 Deterministic multi-factor identity orchestration (the base filing).
• 19/561,964 Autonomous inter-agent trust negotiation (the A2A protocol).
• 19/564,338 Hardware-anchored identity orchestration for non-terrestrial networks.
• 19/567,418 Recursive entropy chaining.
• 19/570,722 Relativistic kinematic space-time authentication.
• 19/576,127 Topological virtual authenticator (continuation-in-part of 19/553,357).

Provisional applications (10), inside their 12-month window:

• 63/998,217 Graduated agentic trust scoring.
• 63/998,218 Hybrid post-quantum cryptographic identity.
• 63/998,223 Quantum-seeded entropy generation.
• 63/998,671 Spatially-bound identity attestation.
• 63/999,157 Predictive cybersecurity threat prosecution.
• 64/006,808 Biometric-linked asymmetric session tunneling.
• 64/006,812 Cross-pillar parametric revocation cascade.
• 64/006,816 Hardware-anchored provenance guard.
• 64/006,819 Physics-anchored identity settlement tokens.
• 64/014,323 Purpose-bound PII vault.

PasskeyBridge is a managed service. There is no self-hosted build, and there is no separate sandbox host: sandbox traffic is distinguished by the API key you use, against the same api.passkeybridge.io.

Pro adds the credential engine, passkeys, ten playbooks and the test simulator. Enterprise adds the capabilities listed above. Both paid plans start with a 7-day trial. growth appears in older rows as the former name of Pro. A fourth tier, enterprise_dedicated, exists in the rate-limit table but cannot be bought.

A note on retention. The plans are described with 7-day, 90-day and 2-year event retention. That is the entitlement, and no job deletes old events today. The only scheduled deletion that runs is in the audit log, where the IP and user-agent digests on a row are nulled 90 days after it is written; a data subject request deletes on demand through the DSAR pipeline. Treat the plan figures as what you are entitled to ask for rather than as an automatic purge.