Egress proxy internals
Egress proxy internals
Start with meaning, then move to detail.
This lesson explains Egress proxy internals as part of Hermes internals and extension points. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect Module layout, Lifecycle, Security invariants, then verify failure modes and version compatibility.
Know Python, Git, and basic project structure before changing code.
A clear outcome before you read.
- Understand Egress proxy internals without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
Short definitions before the details.
- Approval & sandbox
- Approval pauses a sensitive action before execution; sandboxing limits impact if something goes wrong.
How the iron-proxy egress firewall integrates with Hermes — module layout, lifecycle, security invariants, and extension points
What does the source say, and in what order?
- 01Module layout
Start here to understand the core idea or structure.
- 02Lifecycle
Read this after the foundation, then connect it to the previous step.
- 03Security invariants
Read this after the foundation, then connect it to the previous step.
- 04Filesystem perms
Read this after the foundation, then connect it to the previous step.
- 05Subprocess env minimisation
Read this after the foundation, then connect it to the previous step.
- 06Bind policy
Read this after the foundation, then connect it to the previous step.
- 07Metrics port collision
Read this after the foundation, then connect it to the previous step.
- 08Default deny CIDRs
Read this after the foundation, then connect it to the previous step.
- 09Audit log fail-loud
Read this after the foundation, then connect it to the previous step.
- 10Bitwarden mode fail-loud
Finish here to verify the result and special cases.
Copy only after you understand the effect.
agent/proxy_sources/iron_proxy.py Core: binary install, CA gen, config build,
subprocess lifecycle, mappings I/O, PID/nonce
defense. Pure-function surface where possible.
hermes_cli/proxy_cli.py Wizard + slash command handlers.
`hermes egress {install,setup,start,stop,
status,disable,config}`. Wires the
core module into argparse.
hermes_cli/main.py:_dispatch_egress Top-level subhermes egress install
-> agent.proxy_sources.iron_proxy.install_iron_proxy(force=...)
Downloads pinned tarball + checksums.txt from GitHub Releases.
SHA-256 verification before extraction.
tarfile.extract(..., filter="data") on Python 3.12+ (PEP 706);
falls back to plain extract on older Python with member-name
sanitisation via _pick_tar_member.
Stage into ~/.hermes/bin/.iron-proxy_XXXX, chmod 755, os.replace
to ~/.hermes/bin/iron-proxy (atomic).
_VERSION_CACHE.pop(target) so a forced reinstall re-probes
--version on nextAlso update `_DEFAULT_ALLOWED_HOSTS` so the proxy allows the upstream by default. Run `test_discover_provider_mappings_*` to confirm.
### Adding a new header-token provider (x-api-key family)
If the provider authenticates with a static NON-Authorization header (like Anthropic's `x-api-key`, Azure's `api-key`, or Gemini's `x-goog-api-key`), add it to `_HEADER_AUTH_PROVIDERS` — iron-proxy's `secrets.replace.match_headers` targets arbitrary header names, so these are first-class swapped providers:Read the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.