Built to keep your secrets secret.
A self-hosted gateway that inspects and controls what your network sends to the web.
Polymux™ sits between your network and the internet. Every HTTP or HTTPS request that reaches Polymux is inspected, then forwarded, or stopped and recorded. Replies come back with the real values restored.
- Inspect. Finds credentials, personal data and internal names, and swaps them for tokens.
- Decide. Checks each destination and tool call against your policy, per team.
- Account. Records what was allowed and what was stopped, in a log you can verify.
Nothing is Ready yet.
For one machine or a whole team.
Limits: it matches known value shapes and does not judge meaning. Details below.
What it does.
Three jobs, on every request.
Finds what should not leave and swaps it for a token.
- Tokenizing hostnames, addresses, credentials and personal data Tested
- PII, PCI and secret detectors plus custom patterns Tested
- Destination allow and deny lists Tested
- Malware scanning Coded
- Scanning model replies as they stream back Coded
- Heuristic checks for prompt injection Coded
- Destination reputation feeds Coded
- Inspecting encrypted traffic, with consent at install Coded
Allows, blocks or dry-runs, per team.
- Per-team policy Tested
- Blocking tool calls Tested
- Shadow mode Tested
- Signed canary rollout Coded
- Per-team model allow-lists Coded
- OIDC sign-in for clients and admins Coded
- Rate limits Coded
Leaves a record you can verify.
- A hash-chained audit trail Tested
- Spend limits Coded
- Offline-signed licenses Tested
- Alerts by email and webhook Coded
- A digest of what the detectors matched Coded
- An audit trail that survives outages Coded
- Opt-in response cache and prompt-cache hints Coded
How it works.
Polymux sits inside your firewall, with your clients pointed at it. The aim is no ambiguous states: a request that reaches it is inspected and forwarded, or stopped and recorded.
Illustrative: the host, address and token identifiers are made up, and the tokens are shortened. The provider sees tokens, and your team gets the real values back in the reply. The cost is that the model cannot see your topology, so it cannot infer which environment a host belongs to.
If an enforcement check fails or errors, that stream stops at Polymux and the others flow on. The data plane fails closed by design. The control plane degrades visibly: it stays reachable so an operator can clear the fault. A few paths do not behave that way yet, and each deliberate exception is documented as an architecture decision.
- 01Authenticate & authorize
- 02Enforce policy & budget
- 03Detect & tokenize
- 04Cache or forward
- 05Scan the response
- 06Govern tool calls
- 07Restore & return
- 08Record to audit chain
Any stage can stop a stream. The stages show the design. What is Tested is listed under Maturity.
What is Tested, and what is only Coded.
Coded: written, with its own automated tests; not yet run end to end. Tested: run end to end through the real program against mock providers and lab clusters. Ready: run on live traffic across a range of scenarios, and signed off by the Founder. Nothing is Ready yet.
- Coded14
- Tested8
- Ready0
Each capability above carries its rung.
Questions are welcome at any point: development@polymux.io.
Follow along: status and updates or the Atom feed.
Limits: what Polymux does not do
Scope. It handles HTTP and HTTPS traffic, not every outbound protocol.
Reach. Only traffic sent through Polymux is inspected. It does not capture a machine's other traffic.
Detection is pattern-based. It matches known shapes of values: credentials, keys, personal data, hostnames, addresses and your own patterns. It does not read for meaning, so long prose carrying company IP, encoded or compressed payloads, and a person deliberately working around the patterns can get past it.
Failure. A detector that runs and finds nothing is trusted, so detection accuracy matters. Its accuracy has not been measured.