Credentials at the point of egress

Refer to a credential without embedding it

SecretProxy now has an end-to-end credential-injection path. An application sends a request containing a placeholder. The proxy resolves that reference for the registered target, inserts the credential in the allowed location, and forwards the request upstream.

This moves credential resolution into the outbound request path. Application code can express which credential it needs without storing the upstream value in every component that makes the request. The proxy becomes responsible for applying the binding correctly.

Targets, secrets, and bindings

The management model separates three objects. A target identifies the upstream destination. A secret stores a credential value. A binding connects a secret version to a target and defines how the value may be inserted.

Bindings distinguish header and body injection and can constrain the header name or apply a header template. The request path checks those rules when it resolves a placeholder. A credential intended for one part of a request should not silently become available in another.

Separate management from forwarding

The dashboard is now connected to the management API and the real proxy engine. The forwarding path runs in its own Worker, while the management API handles changes to the stored configuration. They share the data model but have different responsibilities.

Body substitution also needs care. Binary or encoded content cannot be treated as arbitrary text without risking corruption. The proxy limits the content it scans and preserves the payload when substitution does not apply.

The responsibility that moves with the credential

The proxy handles the real credential while preparing an authorized upstream request. That makes its access rules, diagnostics, and configuration part of the application’s security boundary. This release establishes the injection mechanism and the management path; further credential-lifecycle controls build on those foundations.