Overview
CI jobs, AI coding agents, and sandboxed containers already have network access and real credentials. A compromised dependency, a prompt injection, or a malicious build step can exfiltrate secrets, phone home, or open a reverse shell. Today, most setups give you zero visibility into whether that’s happening.
iron-proxy is the boundary that stops it. It’s a single-binary egress firewall that intercepts all outbound traffic from untrusted workloads, checks every request against policy, and injects secrets at the network edge so workloads never see real credentials. Every request is logged with full detail on what was allowed, blocked, and transformed.
How It Works
iron-proxy sits between your containers and the internet. All outbound traffic is intercepted, checked against your policy, and either transformed and forwarded or blocked. Nothing leaves unless explicitly allowed.
Container → iron-proxy → policy check → transform pipeline → upstream (or reject)For details on DNS interception, TLS termination, certificate minting, and the transform pipeline internals, see Architecture.
Key Capabilities
Default-deny egress. Nothing leaves unless you allow it. Allowlists support domain globs (*.anthropic.com) and CIDRs (10.0.0.0/8), with an optional warn mode for auditing before enforcement.
Secret injection at the boundary. Workloads never see real credentials. They only hold proxy tokens. iron-proxy swaps in real values at the network edge before forwarding. If a workload is compromised, there are no real secrets to exfiltrate.
Full audit trail. Every request is logged as structured JSON with host, method, path, status, and duration. Logs include per-transform annotations: which secrets were injected, where, and which policy allowed or rejected the request.
Streaming-aware. WebSocket upgrades and Server-Sent Events are proxied natively.
Who It’s For
If you run untrusted code that has network access and credentials, you need iron-proxy. That includes CI pipelines with third-party build steps, AI coding agents calling APIs, container platforms executing user-submitted code, or any workload where a compromise could mean silent data exfiltration.
Open Source and Managed Offering
iron-proxy is open source and fully functional standalone. Run it anywhere: Docker, Kubernetes, bare metal, CI runners.
When you’re operating more than a handful of proxy instances, managing policies, secrets, and audit logs per-instance stops scaling. We’re building a managed control plane that centralizes policy enforcement, secrets management, and audit aggregation across your fleet. Get in touch if you’re interested.
Comparison With Alternatives
iron-proxy is purpose-built for controlling and observing untrusted workloads. General-purpose proxies can be configured toward similar goals, but they weren’t designed for this problem and lack built-in primitives for it.
| iron-proxy | Squid | mitmproxy | Envoy | |
|---|---|---|---|---|
| Primary use case | Egress control for untrusted workloads | Web caching / access control | Traffic inspection / debugging | Service mesh / L7 routing |
| Default-deny egress | Built-in | Requires complex ACL config | Requires custom scripting | Requires RBAC/filter config |
| Secret injection | Built-in | — | — | — |
| Audit logging | Structured JSON with per-transform traces | Basic access logs | Plugin-based | Configurable access logs |
| Setup | Single binary + YAML | Extensive config language | Python scripting | Complex YAML or control plane |