01 / REACH
Files and systems
Once an agent can run tools, it can read and change what those tools can reach.
ZeroTruss sits between an AI agent and its tools. Every call is allowed or denied, and every decision is logged.
Fail safe.
01 / REACH
Once an agent can run tools, it can read and change what those tools can reach.
02 / PROOF
Afterwards, nobody can show what the agent was allowed to do, or what it actually did.
03 / TRUST
Without a checkpoint and a record, safe behaviour is something you hope for, not something you can check.
STEP 1
Every tool call is paused at the gateway before it runs. It works with agentgateway over MCP.
STEP 2
The gateway asks ZeroTruss "is this allowed?" and gets a yes or a no.
STEP 3
If the checkpoint cannot be reached, the gateway lets nothing through unchecked. With the gateway set to fail closed, a fault never opens the gate.
MCP (Model Context Protocol) is a common way for AI agents to call tools, such as one that reads files. agentgateway is a gateway that sits between AI agents and their tools. Fail safe, also called fail closed, means that when something breaks, the safe answer wins and the call does not run.
Ed25519 is a standard digital signature: only the holder of the private key can sign, and anyone with the public key can check the signature. Built and used on macOS, where the signing key is kept in the Keychain. The pipeline runs the tests on Linux.
RULES FILE (public example, list shortened)
Each entry carries a hash of the entry before it. Edit an entry, or take one out of the middle, and the chain stops matching. A separate checker verifies it. Cutting off the end of the log, or rebuilding the whole chain, is not caught.
The log stores a fingerprint (hash) of the arguments, not the arguments themselves, and a deny reason never contains a file path.
This entry's prev_hash is the hash of entry 1 (b6c52cf5...7475). That is the link in the chain.
The full software bill of materials, open for anyone to inspect. It is generated by our build pipeline on every push and checked against the CycloneDX 1.6 schema.
CycloneDX is a standard format for a software bill of materials, which is a list of the parts software is made of.
| Component | Version | License | Used in |
|---|---|---|---|
| cffi | 2.1.1 | MIT-0 | Runtime, needed by cryptography |
| cryptography | 50.0.2 | Apache-2.0 OR BSD-3-Clause | Runtime, direct |
| grpcio | 1.84.1 | Apache-2.0 | Runtime, direct |
| protobuf | 7.36.2 | 3-Clause BSD License | Runtime, direct |
| pycparser | 3.12 | BSD-3-Clause | Runtime, needed by cffi |
| typing_extensions | 4.16.0 | PSF-2.0 | Runtime, needed by cryptography and grpcio |
Not part of what runs. They are listed from the lock files, which pin each one to an exact version.
Measured on commit dcdcec9, 7 Nov 2026.
196
automated tests
14 days
Checked on every push: no dependency under 14 days old
Exact versions, with hashes
Every dependency is pinned and installed from prebuilt packages only.
Vulnerability audit runs on every push
On every lock file (pip-audit).
Secret scan of the whole history
Runs on every push.
Signed rules
Ed25519. Private key in the macOS Keychain.
Hash-chained audit log
With a validator.
Apache-2.0 licensed
CycloneDX SBOM
Generated on every push.
INCLUDED