Summary
Kits already seem like the right place to declare tools, network rules, environment variables, files, startup behavior, and credential injection.
This proposal is to make the outbound/credential injection part of kits programmable.
Today, the model appears to be mostly static:
match outbound traffic by destination/domain
-> inject or replace a configured credential/header
That is useful, but there are enterprise and AI-agent use cases where the host/control-plane needs to run logic for outbound requests, not only substitute a credential.
Proposed model
Allow kits to define a programmable outbound handler for HTTP/HTTPS traffic.
Conceptually:
sandbox outbound request
-> kit-defined outbound handler
-> policy check / credential selection / request transformation
-> destination API
<- optional response filtering / audit logging
The real credential would still stay outside the sandbox.
The handler could decide, at request time:
- whether the request should be allowed
- which credential should be used
- how headers/body/query params should be transformed
- whether the destination should be rewritten
- what should be logged
- whether the response should be redacted or truncated
Why static header injection is not always enough
Many enterprise and AI-agent use cases are not simply “inject this header for this domain.”
Examples:
- enterprise AI gateways
- internal APIs with application-specific authorization
- MCP gateways / tool calls
- OAuth flows
- AWS/GCP credential chains and SSO flows
- service account JSONs
- mTLS
- SaaS APIs that require request signing or non-header credentials
- audit logging and response sanitization
Related prior art
Cloudflare’s Sandbox / Containers Outbound Workers seem like useful prior art.
My understanding is that Cloudflare outbound handlers are programmable egress proxies for sandbox/container outbound HTTP/HTTPS traffic. They can intercept outbound traffic, inject credentials, enforce dynamic egress policies, and run Worker logic without exposing raw credentials to the sandbox.
Docker Sandboxes already has a strong foundation by keeping raw secrets out of the sandbox. Making kit-defined outbound handling programmable would preserve that model while making it more expressive for enterprise and AI-agent workloads.
Summary
Kits already seem like the right place to declare tools, network rules, environment variables, files, startup behavior, and credential injection.
This proposal is to make the outbound/credential injection part of kits programmable.
Today, the model appears to be mostly static:
That is useful, but there are enterprise and AI-agent use cases where the host/control-plane needs to run logic for outbound requests, not only substitute a credential.
Proposed model
Allow kits to define a programmable outbound handler for HTTP/HTTPS traffic.
Conceptually:
The real credential would still stay outside the sandbox.
The handler could decide, at request time:
Why static header injection is not always enough
Many enterprise and AI-agent use cases are not simply “inject this header for this domain.”
Examples:
Related prior art
Cloudflare’s Sandbox / Containers Outbound Workers seem like useful prior art.
My understanding is that Cloudflare outbound handlers are programmable egress proxies for sandbox/container outbound HTTP/HTTPS traffic. They can intercept outbound traffic, inject credentials, enforce dynamic egress policies, and run Worker logic without exposing raw credentials to the sandbox.
Docker Sandboxes already has a strong foundation by keeping raw secrets out of the sandbox. Making kit-defined outbound handling programmable would preserve that model while making it more expressive for enterprise and AI-agent workloads.