Nothing leaves uninspected.

What happens to your data the second it leaves? Most organizations are guessing.

One narrow waist. Every stream crosses it.

Outbound security is usually broken by breadth: a dozen products, each seeing a slice, none of them the last word. This does one thing. The internet is built as an hourglass — countless applications above, countless networks below, one narrow waist between — and Polymux gives your outbound traffic the same deliberate architecture: your users, apps, and agents on one side, the services they call on the other, a single governed junction between them. No ambiguous states: a stream is inspected and forwarded, or stopped and recorded. There is no third outcome.

Streams stay individually isolated as they multiplex through: each authenticated, inspected, and budgeted on its own terms. When an enforcement check fails — or even errors — that stream stops at the waist. Traffic halts rather than leaks. The deliberate exceptions are availability plumbing, not policy, and each is documented as an architecture decision instead of left as an accident.

This sits behind your edge, not instead of it. A firewall and an edge router decide whether a connection may be made — address, port, destination — and the deep-inspecting ones match signatures and categories on what passes. None of them carry meaning across the boundary: recognize that a value is yours, substitute it before it leaves, and put it back on the way home. That's the gap this fills, and it's why the junction belongs inside the boundary rather than at it.

The two planes are built to fail differently, and on purpose. The data plane fails closed: a check that fails, or errors, ends that stream. The control plane degrades visibly — when its own guard rails trip it boots fenced and stays reachable, reporting unready rather than serving, so an operator can reach the instrument that clears the fault instead of being locked out by it.

What's already standing at the junction.

Everything below is implemented and exercised by the automated test suite — unit, end-to-end, and failure-path coverage against mock providers and lab clusters. None of it has carried production traffic yet. We say so on each card.

An agent's authority should be checked somewhere the agent can't reach.

Under the AI features is the same inspection-and-enforcement engine, and AI is where it earns its keep first — because an agent breaks the assumptions the rest of your stack still makes. It chooses what to send. It acts on whatever enters its context. It does both faster than anyone reviews.

So be exact about what a gateway buys you here. It cannot tell you which tool call is a mistake — that judgement needs intent, and we don't claim a detector for intent. What it does is move the decision off the agent: onto a policy the agent can't edit, at a point it can't route around, with a record of what was decided and why. You still have to write the policy. It just stops being advisory, and it stops living inside the thing that might be compromised.

This is a run on the same enforcement path the automated suite drives — a 403 on the secret, a 200 with the infrastructure tokenized and rehydrated. Token identifiers are minted fresh each run, so the ones shown are representative, not fixed; what holds every time is their shape. The kind stays legible while the rest is random, so count, ordering, and relationships can't be derived from the token stream — and it's chunked and free of look-alike characters (no l-versus-1, no o-versus-0), so an operator can still read one off an audit line and drop it into a search box. The provider never sees the real names; your team gets them back rehydrated.

There is a real cost here, and it is worth naming rather than hiding: the model loses your topology. It cannot infer which environment a host belongs to, how your subnets group, or what your naming scheme implies. That loss is the point. Those relationships are the map an attacker builds first, and a model that cannot see them cannot leak them — to a provider, to a log, or to whoever reads either one later. What survives is everything that is not about your topology: the error in the traceback, the type mismatch in the config, the logic in the code.

Pre-release is a claim about traffic, not about rigor.

By construction is the whole posture, and it means something specific: the unsafe option is removed, not defaulted off. When the weak token format was replaced, the switch that selected it was deleted rather than flipped. A service started with no environment declared refuses to boot rather than assuming the permissive one. The control plane cannot clear a safety fence that it is itself subject to. None of those are checks someone has to remember to run; there is no longer a way to express the wrong thing.

The same instinct governs what we write down. A security product asks you to believe a lot of sentences, so ours are bound by a rule we enforce on ourselves: a claimed guarantee has to be enforced or cited. Where a claim's shape can be checked mechanically, that rule is a build gate — a grant-style claim that doesn't name the line enforcing it fails the build. Where it can't, it's a review duty, and we track what that leaves undrained rather than rounding it up.

More than a hundred architecture decisions are recorded with the reasoning and the alternatives that lost. Our readiness file is generated, carries measurements with named sources, and has no status column — because a status column is where a document starts asserting instead of counting. And we run our own audits asking the only question that matters here: what in this repository reads as implemented but isn't? The findings go in the repository, resolved or not.

What we don't publish is the roadmap. Specifics land when they ship — a roadmap is a to-do list for a competitor, and ours stays in the lab.