SecretProxy.
An outbound boundary for agents. A separate home for credentials.
What should an agent be allowed to reach?
An agent may need to query a service, read a repository, or act on a business system. That does not mean it should hold the credentials for those systems—or have unrestricted access to the network. SecretProxy is evolving into the egress proxy for AI agents.
The credential proxy is available today. Agent-specific policies and enforced egress are in development.
Separate the agent from the credential
Today, a trusted tool adapter can send an HTTP request through SecretProxy. Source access and target bindings determine where a credential can be injected. The proxy resolves the selected secret version and forwards an authenticated request to the upstream API.
The adapter must run outside the agent’s control. A SecretProxy reference contains sensitive key material: it belongs in protected adapter configuration, not in prompts, agent-readable files, or an agent’s shell. The adapter validates tool actions and controls the response returned to the model.
Our next step is agent-aware egress: explicit outbound permissions, policies for individual agents and tasks, and visibility into their requests. Enforcing that boundary also requires a runtime or network configuration that prevents agents from bypassing the proxy. These controls are the product direction, not capabilities of the current quick start.
The questions we’re working on
A destination is not an action
Permission to reach an API is broader than permission to perform a particular operation. We want outbound policy to express which actions an agent may take, not just which host receives the request.
Credentials outside the runtime
Both the upstream secret and the reference must stay outside the agent’s control. The proxy remains a trusted component; response filtering and least-privilege upstream credentials are still necessary.
Access with an owner and an end
UltraNow’s direction is to manage access grants and their lifetime. SecretProxy’s direction is to enforce outbound requests and credential use. Connecting those responsibilities is part of our future work.
Explore the project
Explore the agent egress direction and the integration you can use today. The docs distinguish existing proxy behavior from planned agent controls.
Publications
Verify credential-key ownership before forwarding
A new request check verifies the key material in a credential reference before the proxy uses the stored secret, alongside the existing IP controls.
SecretProxyVersioned credentials and deliberate rotation
Secret versions and binding promotion make credential changes explicit, with checks that preserve tenant ownership and secret lineage.
SecretProxyEncrypted secret storage for SecretProxy
The secrets API now encrypts new credential values with AES-256-GCM, while the proxy recovers them only when preparing the outbound request.
SecretProxyCredentials at the point of egress
SecretProxy now resolves application placeholders into target-bound credentials, with a management interface connected to the request path.
SecretProxySecretProxy’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.
SecretProxy