Skip to content

Trust boundary

What stays yours

This is at once the hardest concept to convey and the core trust sell. An evaluator who understands the boundary understands why Machinaut can make a promise no observability vendor can.

Machinaut is transport and a read-side. It never holds the authority to forge an approval. Your writer, your raw data, and your signing keys stay in your environment.

What stays yours

Machinaut is deliberately not in the write path or the trust path. The following never leave your environment:

  • Your agent runtime and the writer. Machinaut never runs your agent and never hosts Lodestar’s event-log writer. It ingests copies of the writer’s output. (That writer is process-local by design; a shared hosted runtime would fight the architecture.)
  • Your raw data. Redaction happens at the source, before anything ships, gated by a sensitivity ceiling — data classed above it is stripped locally. Only the redacted record’s tamper-evident hash travels, as a commitment. Machinaut receives what you chose to send, never a live tap on your environment.
  • Your signing keys. The Ed25519 approver keys are customer-held on every tier today, Free included. Machinaut never sees them.
  • Your approval decisions. The decision is made by a human on your side and signed on your side. Machinaut carries the request out and the signed answer back; it does not make or mint the decision.

The forgery boundary does not move

Approvals are Ed25519-signed and verified customer-side, after transport, against operator-pinned keys. That verification is the forgery boundary, and it stays in your environment no matter what.

The approval channel is pure transport. A malicious or fully compromised Machinaut endpoint can, at worst, delay an approval — and a delayed hold resolves to a deny (the safe default). A compromised Machinaut cannot:

  • mint a grant that no approver signed,
  • upgrade a denied decision into a granted one,
  • replay a valid grant onto a different action,
  • or revive a stale / expired grant.

Every one of those is caught by customer-side verification of a signature over a canonical decision document bound to the specific request and action. Machinaut is transport; it must never become the forgery authority.

Two guardrails keep it that way: the channel requires pinned keys and forbids unsigned mode, and the channel endpoint is operator-pinned configuration — never derived from agent or log content — so there is no dynamic discovery and no request-forgery path into it.

Two custody models — one of which is real

The only difference between them is who holds the signing key. Only customer-held exists today, and it is the default on every tier; managed custody is planned and currently refused by the console.

Managed keys (convenience)Customer-held keys (every tier)
Who signsMachinaut would sign on the operator’s behalfYou sign, in your environment
PostureConvenient; a cloud compromise could sign for that tenantMachinaut is pure transport and cannot forge, period
IsolationPer-tenant KMS/HSM isolation — never a shared cloud keyKeys never touch the cloud
StatusPlanned — does not exist todayLive, on every tier

Managed keys is a convenience tier, not the posture — and it is not built. The console surfaces the selector but refuses it (409), and no tier ships defaulted to managed. If it ever ships it will be ring-fenced (per-tenant KMS/HSM, never a shared key, always labelled the weaker option) and never the enterprise default.

Customer-held is not an enterprise upsell — it is the default everywhere

The left column above is planned, not a shipped toggle. Today, approver keys are customer-held at every tier, Free included. So “Machinaut cannot forge an approval” is not a claim we scope to enterprise buyers — it holds for everyone, and it is the one thing we would have to lie about to break.

What the trust story is today, by tier

Be honest about who gets which guarantee right now. This page used to scope the strongest claim to enterprise buyers and tell free users that Machinaut signed on their behalf. Both halves of that were wrong, so here is what is actually true:

  • Customer-held keys — every tier, today. The full guarantee: approver keys stay in your environment and Machinaut cannot forge, period. Free included. It is not an enterprise upsell.
  • Managed keys — planned, and refused today. Nobody is on it. Machinaut does not hold or use your signing key on any tier, so there is no tenant for which a cloud compromise could sign. If managed custody ever ships, this page will say so, and it will be labelled the weaker posture wherever it appears.
  • What is still missing: one-click local signing. Self-signing works today, but the ergonomics are yours to wire up — which is what Machinaut Desktop is for. That is a convenience gap, not a trust gap.

Why this is the differentiator

An observability vendor sees your traces; if it’s compromised, your data and your records are compromised with it. Machinaut, in the customer-held posture, is structurally different: even a total cloud compromise cannot forge an approval or fabricate the evidence trail, because the signing and the verification both happen on your side. That’s a security story an observability tool cannot tell — and it’s the reason the boundary is the pitch, not a disclaimer. The customer-held posture is the default on every tier today, so the claim is not tier-scoped: it holds for Free users too.

The one-line guarantee

With customer-held keys, a total compromise of Machinaut can only delay a decision — and a delay resolves to a deny. It can never mint, upgrade, replay, or revive a grant. The forgery boundary never moves into the cloud.