SecretProxy’s first forwarding prototype
A small Worker experiment forwards requests to an explicit set of destinations and pairs that request path with key-value storage.
Put an explicit boundary in the request path
We have a first forwarding prototype for SecretProxy. The Worker reads the requested upstream destination from the path, checks it against an explicit allowlist, and forwards allowed traffic. Requests outside that set are rejected.
The experiment gives us a controlled point between a caller and an external service. Instead of treating a proxy as a universal tunnel, we can ask what it should know about the destination before making a request on someone else’s behalf.
Preserve the request while constraining its destination
For an allowed destination, the prototype constructs the upstream URL from the path and query, forwards the request, and returns the upstream response. This keeps the first implementation small enough to examine the forwarding behavior directly.
A key-value binding provides a separate storage experiment in the same Worker. At this stage, storage and forwarding are basic primitives. The prototype does not yet resolve application placeholders into credentials or define a complete credential-management workflow.
Use the prototype to define the next boundary
The next questions concern authorization and policy: which caller may reach a destination, which request fields may change, and how a stored value could be used without distributing it across applications. Those decisions need explicit rules before the forwarding path can carry sensitive material.
This is an internal engineering prototype. Its purpose is to make the request boundary concrete and give the next iteration a small mechanism to build on.