Skip to Content
Overview

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-proxySquidmitmproxyEnvoy
Primary use caseEgress control for untrusted workloadsWeb caching / access controlTraffic inspection / debuggingService mesh / L7 routing
Default-deny egressBuilt-inRequires complex ACL configRequires custom scriptingRequires RBAC/filter config
Secret injectionBuilt-in
Audit loggingStructured JSON with per-transform tracesBasic access logsPlugin-basedConfigurable access logs
SetupSingle binary + YAMLExtensive config languagePython scriptingComplex YAML or control plane
Last updated on