Positioning
What Machinaut is
The one-line pitch, the category, and the line between what Lodestar OSS gives you for free and what a hosted product genuinely adds.
Machinaut is where your team governs your agent fleet: approve, audit, prove.
Not “see your agent’s chain” — the open-source Lodestar already does that, locally, for a single operator. Machinaut is the hosted, multi-tenant control plane on top: the place a team governs many agents across many projects, and can prove — with signatures that hold up outside our cloud — why each governed action ran.
What Machinaut is
Machinaut is the hosted, multi-tenant trust layer for AI agents — the commercial control plane built on Lodestar OSS. Concretely, it is:
- The read side. Your agent’s governed event log ships here; Machinaut ingests, indexes, and renders it for a whole team.
- The approval authority’s transport. When Lodestar holds a risky action for approval, Machinaut is how the request reaches an approver and the signed decision gets back — as untrusted transport, verified on your side (see the trust boundary).
- The governance surface. Org / tenant / roles, cross-session fleet views, an org-scoped audit log, shareable post-mortems, policy drafting.
Why a team needs this — the free loop’s blind spot
The whole govern loop runs free for a solo developer, and the solo loop is never gated (that’s the open-core posture, not a trial). So the honest question isn’t “what does Machinaut add?” — it’s “what breaks the day a team runs this on the free, single-operator loop?” On day one of a 5-person team running 20 agents:
- The agent’s own author is the only one who can approve its risky actions. A held push to
mainis waved through by the person who wrote the agent — self-approval, no second signer, no separation of duties. - There is no record across sessions. Each operator sees their own loopback. Nobody can answer “has any agent in this org done X before?” across the fleet.
- There is nothing to hand an auditor. No org-scoped trail of who approved what, no exportable proof, no cross-session history — because the local viewer is single-operator and read-only by design.
Those aren’t missing conveniences; they’re live liabilities the moment more than one person is accountable for what the agents do. That is the need Machinaut fills.
Why Machinaut — and why not just self-host a rebuild
The fair objection, met head-on: “Everything valuable — the chain, redaction, signing, the kernel, calibration, approvals — is Apache-2.0 that runs in my environment for free. So why pay for hosting?” Three honest answers, in ascending order of how hard they are to copy:
- Self-hosting the solo case is genuinely fine. For one developer, the OSS local viewer is the fallback — free, forever. What you’d be rebuilding to serve a team is the multi-tenant identity / RBAC / fleet / retention layer — which is precisely what the paid tier is, and precisely what the single-operator OSS surface structurally is not.
- Why you stay. The evidence compounds in one place: a single, tenant-wide, tamper-evident record accrues centrally — every governed session, every signed approval, the calibration history, searchable across the whole fleet and exportable as an audit artifact. A from-scratch rebuild starts empty and can only ever cover what it was pointed at from the day it was stood up. (We keep data portable by design — it’s a soft switching cost, not a lock-in.)
- The one thing a rebuild — or an observability vendor — structurally cannot copy. Approvals are signed and verified in your environment; with customer-held keys, even a total compromise of Machinaut cannot forge an approval or fabricate the trail — it can only delay a decision, and a delay resolves to a deny. An observability vendor can’t match this without abandoning its own “we see and hold everything” model and becoming a security product. That’s the durable defense (the trust boundary has the full argument).
What the “cannot forge” claim rests on
What Machinaut is not
- Not “see your agent’s chain.” That’s Lodestar OSS, local and single-operator. Casting the explorer — or storage, or persistence — as the wedge would be claiming an OSS capability as ours.
- Not the agent runtime. Machinaut never runs your agent or hosts the writer. The write side and your keys stay in your environment.
- Not an observability tool. Observability answers “what did my LLM app do, and how fast/expensive?” Machinaut answers “should this action be allowed, and can I prove why it happened?” — governance and verifiable evidence, not traces and dashboards.
- Not model-boundary security. Jailbreak / prompt-injection defense guards the input to the model. Machinaut governs the actions an agent takes and proves the reasoning behind them.
The category: Agentic Security
Machinaut sits in Agentic Security — governing what an agent does and proving why it did it (the epistemic chain from observation to action). The name is young and the space is still forming; we’re candid about that. What’s not in doubt is the capability, which lands at the convergence of authorization / policy, audit / compliance, and agent guardrails enforced at the action boundary. Where it is not is the two categories it’s most often confused with:
| Category | Question it answers | Examples |
|---|---|---|
| Observability | “What did my app do? How fast, how expensive?” | Langfuse, LangSmith, Phoenix |
| Model-boundary security | “Is this prompt trying to jailbreak or inject?” | Prompt-injection / jailbreak filters |
| Agentic Security (Machinaut) | “Should this action run? Can I prove why it happened?” | Lodestar + Machinaut |
Not observability. Not model-boundary security. Agentic Security.
The open-core boundary
Machinaut is commercial software on top of Apache-2.0 OSS. Being explicit about the line is both a hard invariant (never claim an OSS feature as ours) and a trust signal — it tells an evaluator exactly what they’re paying for. The wedge leads with the write-path and the governed team surface, not with storage or search.
| Lodestar OSS already ships — we render it, we don’t own it | Machinaut adds — genuinely needs a hosted product |
|---|---|
| The policy kernel: allow / deny / hold, the trust ladder, signed approvals | The approval write-path as a product — a second signer, cross-org, with the signed decision the OSS viewer deliberately never writes |
| The chain projection (observation → … → action); the chain report | Fleet governance — cross-session, cross-project, cross-teammate; the org-scoped audit trail and exportable proof |
| Sensitivity-ceiling redaction; tamper-evident payload hashing; calibration math | Identity — org / tenant / roles, SSO/RBAC — the multi-operator layer the single-operator viewer isn’t |
| The single-operator local explorer | Ingestion + indexed search + retention — the tenant-wide, compounding, tamper-evident record |
The wedge in one line: a team governance and provable-evidence surface — the approval write-path, fleet, and audit trail — versus OSS’s single-operator, loopback, read-only, local viewer.
Who it’s for
- Solo developer / OSS user. Runs Lodestar locally, then ships a session for a hosted, shareable chain-report link. The solo loop is never gated; the hosted extras are search across sessions and a place to keep and share them. The trigger to the team tier is a named event, not a quota: the day a second person needs to approve the agent’s work, or an auditor asks who approved what.
- A team running agents in production. The blind-spot above is their reality: they need a second signer, an audit trail across everyone’s sessions, and signed, verifiable proof of why each governed action ran. That’s the paid tier: roles, SSO, fleet views, and long retention. (Customer-held keys — the strongest posture — are not a paid add-on; they’re the default on every tier, Free included.)
Status is labelled, not aspirational