End-to-End Client Continuity from the First Request

Works with your existing authentication stack. Enforces continuity at the service boundary.

No IdP changes · No token changes · No application code changes

Same client context for any authentication material · Authorized requests only from the client context that authenticated

The problem

Portability Is the Weakness

Bearer authentication is portable by design. Cookies and JWTs grant access to whoever presents them. Strong authentication — MFA, passkeys — verifies identity at login. It does not change what happens to the credential after issuance.

Session replay — reuse of valid authentication materials outside the origin that established them — is a recognized class of risk, with dedicated standards addressing sender-constrained authorization:

Sender-constrained approaches exist. Adopting them requires identity provider cooperation and token format changes — which is why most deployed systems continue to rely on portable bearer semantics despite the documented guidance.

The gap

Authentication Proves Identity.
It Does Not Constrain Origin.

Existing controls protect the authentication flow. Plumbus protects the credential after authentication completes.

Control What it enforces Prevents credential replay?
MFA Identity at login No
Passkeys / FIDO2 Phishing-resistant identity at login No
WAF / Anomaly Detection Probabilistic signal analysis No — heuristic, not deterministic
Plumbus Deterministic origin enforcement per request Yes
The scenario: A valid session credential is exfiltrated after a user authenticates with MFA. An attacker replays it from a different origin. The credential is valid. The identity provider has no signal. MFA already ran — it does not re-run. The origin differs. Plumbus rejects the request before it reaches application logic.

The change

Authentication Materials Become Non-Portable

Without Plumbus

Authentication materials function as bearer tickets. Whoever holds them can use them from any origin. Exfiltration equals access.
With Plumbus

Authentication materials are bound to the origin that established authentication. Requests from outside that origin are rejected before reaching application logic.
  • Exfiltrated credentials cannot be replayed from a different origin
  • Proof of possession is verified on every protected request — not only at login
  • Enforcement is deterministic: cryptographic verification, not behavioral heuristics
  • Works with existing tokens, cookies, and proprietary credentials as-is

Authentication proves identity.
Plumbus enforces origin continuity.

Standards alignment

Two Standards Define the Right Guarantee.
Plumbus Delivers Both Without Infrastructure Changes.

RFC 9449 (DPoP) is the published standard for sender-constrained token binding. RFC 9700 explicitly recommends it. Plumbus implements it.

Standard DPoP requires your identity provider to embed a public-key thumbprint in issued tokens and resource servers to validate that claim on every request. DPoP is also JWT-centric — systems using cookies or proprietary credentials must rework token issuance to participate.

Plumbus enforces the same cryptographic guarantee at the service boundary, treating existing authentication materials as opaque. The identity provider is never involved. Nothing in your authentication stack changes. It is a layered control, not a replacement.

RFC 8705 (Mutual TLS) is the certificate-based counterpart — sender constraint via client certificates rather than proof-of-possession tokens. Both are published standards. Both require infrastructure that most deployed systems do not have. Plumbus enforces the equivalent guarantee at the service boundary without either.

Deployment

One Sidecar. One Config File.

Plumbus is a reverse-proxy sidecar. It runs alongside your existing services — no application refactoring, no identity provider changes, no token format migration.

  • One container — pull and run. Plumbus proxies traffic between clients and your backend.
  • JSON configuration — specify which routes are enforced, the mode (Enforce / Monitor / Passthrough), and the signing key source.
  • Secrets integration — reads signing keys from AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault.
  • Gradual rollout — start in Monitor mode to observe without affecting traffic. Promote to Enforce per route. Revert by changing one config field.

Typical proof of concept: two weeks.

Run the demo locally →

Where it matters

Any Endpoint Where "The Token Was Valid"
Is Not an Acceptable Incident Report

  • Administrative consoles and privileged access
  • Financial transactions — withdrawals, transfers, billing
  • API key issuance and credential management
  • Actions that are irreversible or externally visible
  • Any surface where WAF heuristics are insufficient and deterministic enforcement is required

Plumbus does not replace application authorization. It enforces that requests come from the authenticated origin before any application logic runs.

Scope

Plumbus Adds One Property.
Everything Else Is Unchanged.

  • Not an identity provider or authorization server
  • Not a replacement for MFA, passkeys, or SSO
  • Does not issue, inspect, or modify authentication materials
  • Does not introduce fingerprinting, device tracking, or behavioral profiling
  • Does not alter application-level authentication or authorization logic
  • Does not store session state or authentication materials server-side

Authentication proves identity.
Plumbus enforces origin continuity.

If you are evaluating whether Plumbus fits your stack — or have questions about threat model coverage, deployment architecture, or compliance posture — reach out directly.

contact@plumbus.dev

Or run the demo locally — see enforcement in action before anything else.