Signed everything, now build it yourself

We ship a source-available agent that runs with real privileges on machines other people own, including machines that move money. That is a large amount of trust to ask for, and "trust us" is not a sentence that earns it. The only thing that earns it is making every claim checkable, so a security team can confirm what we say instead of believing it. Here is the shape of that, top to bottom.

Read exactly what runs on your box

The agent's source is public, under the Elastic License 2.0. That is the foundation, not a marketing checkbox. A security team can read the actual code that will run on their servers, all of it, before they install anything. There is no closed core doing the interesting part. What you audit is what runs.

Public source alone is not enough, though, because the thing you read on a repository is not necessarily the binary that lands on your host. That gap is where the rest of this lives.

Signed definitions, so the server cannot push you anything it wants

The agent's behavior is driven by definitions sent from the server: what to check, how, where. That is powerful, and in the wrong hands it would be a remote-code-execution channel. So every definition is signed with a publisher key, and the agent verifies the signature before it will run one. A definition that is not properly signed is rejected. The signing key is not on the server that pushes definitions; compromising the delivery path does not get you the ability to forge a definition. The agent trusts the signature, not the sender.

Signed binaries, with anti-downgrade

The agent updates itself, which is another dangerous power if you do it naively. So the update path verifies two things before it will replace the running binary: the content hash matches, and a signature over the bytes checks out against the publisher key baked into the agent at build time. An unsigned or tampered binary is refused outright. And the agent refuses to "update" to an older version than it is running, so an attacker cannot roll you back to a version with a known hole. Forward, signed, or not at all.

Machine-bound identity, useless if stolen

Each agent's credentials are encrypted with a key bound to the specific machine, mixing in a value only root on that host can read. Copy the identity file to another box and it will not decrypt. Steal the encrypted bytes and, without the root-only piece, you cannot reconstruct the key. A compromised host gives up only its own short-lived, revocable credential, not anything that helps you elsewhere. The blast radius of a stolen file is that one file, on that one machine, and even there it is inert.

Reproducible builds: do not trust our binary, rebuild it

This is the part that turns "trust" into "verify," and it is the one we are proudest of.

The build is reproducible. The toolchain version is pinned, the build strips the paths and timestamps that would otherwise make each build unique, and the result is deterministic. That means you do not have to take our word that the published binary matches the published source. You can rebuild it yourself, from the source you audited, with the pinned toolchain, and compare the hash to the release we signed. If they match, you have proven that the binary running on your servers is exactly the code you read, with nothing added on the way. If they ever did not match, you would know, and so would we.

Most vendors, including ones with expensive certifications, cannot offer this. Plenty do not publish a proper software bill of materials, let alone a way to independently reproduce the binary. It is not hard because it is impossible; it is hard because it takes discipline to keep the build deterministic. We keep that discipline precisely so the answer to "how do I know your binary is your source" is a command you run, not a promise we make.

The point of all of it

Every layer here has the same shape. Do not ask the customer to believe; give the customer a way to check. Read the source. Verify the signatures. Rebuild the binary and match the hash. Confirm the credential is inert off its machine. None of it requires trusting us, which is the only kind of trust worth building a security story on, because it is the only kind that survives a skeptical reviewer whose job is to assume you are lying. Hand them the tools to catch you, and the ones who cannot catch you become the ones who vouch for you.

Since this was drafted, we packaged all of the above for exactly that reviewer: the trust pack at wakora.io/trust carries eleven signed documents, the SBOM for the current release, the publisher key, and the byte-for-byte rebuild instructions with the expected hash. No forms in front of it. Download, verify, and try to catch us.