Grux

Guardrails for desktop AI agents. A Swift package. MIT licensed.

This is the guardrail layer extracted from the Grux desktop agent at gruxai.com. Same name, and deliberately so: it is the part of that product you can read, audit, and use without it.

00
Days
00
Hours
00
Minutes
00
Seconds
Install

    

Secret redaction, live

Paste anything. This is what would reach the model.

Input
What reaches the model

This demo is an illustrative JavaScript approximation, not the library. The real matcher is the Swift one and it is table driven, with a corpus of negative cases this page does not run. Where the two disagree, the Swift one is correct and this one is wrong. A security tool whose demo quietly disagrees with its own library is the exact failure this library exists to complain about, so it is said plainly here rather than buried.

Two modules

SecretRedactor

Strips credentials out of anything before it reaches a model.

What it does not do

It is a matcher, not a parser, so it cannot catch a secret that does not look like one. A password, a short opaque session cookie, an internal hostname, or a credential in a format no pattern covers all pass straight through.

Single case hex strings are deliberately exempt, and that is a real gap rather than a feature. It keeps git SHAs and checksums intact, at the cost that a 32 or 64 character lowercase hex API secret goes through untouched. If your stack issues hex secrets, add a pattern rather than relying on the generic pass.

URLGuard

SSRF policy for anything that follows links.

What it does not do

It does not follow redirects, and that is the biggest gap. evaluate judges one string. A perfectly public URL is free to answer 302 Location: http://127.0.0.1:8080/ and nothing here will see it. You must re-evaluate every hop.

It does not resolve DNS either, so a hostname that resolves to a private address is judged on the string you handed it, not on where it actually points.

Six tags shipped before this one. All six leak.

Each one looked fine when it was cut, and several were found by audits of code that had already survived earlier audits. This table is the reason to trust the current release more, and it is also the reason not to trust it completely.

TagWhat it does wrong
0.1.0Passes private key bodies straight through to the model. Forgeable injection fence: any web page could close the </untrusted_data> tag itself.
0.2.0Leaks the AWS secret access key. Introduced base64 blindness and a quadratic pass.
0.2.1Leaks the AWS secret access key.
0.3.0Superseded by later audit rounds. See the changelog.
0.3.1Superseded by later audit rounds. See the changelog.
0.4.0Allows loopback and NAT64 SSRF bypasses. Leaks indented PEM bodies, PGPASSWORD=, session cookies, Set-Cookie, bare Bearer headers and curl -u passwords.

The one worth reading even if you never install this. In 0.4.0, a denylist entry written any way other than a bare host matches nothing at all. https://evil.com, evil.com:443 and *.evil.com are all silently inert against denylist: ["evil.com"]. Your own denylist fails open while looking correctly configured. Check yours.

Earlier tags stay resolvable so existing checkouts do not break, and every one is documented in the changelog so nobody adopts one by accident.

Roadmap

In the order they come out of the private codebase, each landing with its tests rather than as a sketch.