Makoto
Menu
Threat model

Signed history can still be false, incomplete, stale, or unsafe.

Makoto makes exact claims attributable and tamper-evident. It does not turn every signed claim into truth. The receiver must evaluate distinct failure modes instead of treating “signature valid” as a universal pass.

On narrow screens, scroll right to compare the control and residual risk.
ThreatAttackMakoto controlResidual risk
False origin claimAn authorized collector signs the wrong source URI or misleading collection metadata.Attribution, authorization policy, exact source-artifact digest, and optional organization profile.The source claim may still be dishonest; external observation or audit is required.
Artifact mutationData changes after its statement or handoff is signed.Receiver hashes the bytes it actually received and matches the signed subject digest.A malicious producer can sign already-bad bytes.
Metadata mutationAn intermediary edits a transformation, profile binding, or subject digest.DSSE authenticates the exact statement payload bytes.Valid signatures do not establish signer authorization.
Graph rewiringA transformation is pointed at a different predecessor or artifact.Each input binds predecessor statement digest, predecessor subject, and input artifact digest.A fully re-signed alternate graph may be internally valid under a compromised authorized key.
Branch omissionA producer removes an inconvenient but valid branch from the presented graph.A signed handoff commits to exact roots, heads, statements, profiles, and final artifacts.The receiver still needs an independent expectation to know which handoff should exist.
Replay or rollbackAn older valid handoff is presented as current.Expected head or manifest, nonce, age policy, artifact tuple, or external transparency anchor.Without an independent anchor, old valid evidence can look complete.
Signer abuseA known key signs a claim outside its role.Receiver-owned policy authorizes keys per source, operation, profile, and handoff role.Policy and key revocation must be maintained outside the bundle.
Profile substitutionA familiar schema URI resolves to weaker bytes or omits transitive references.Signed profile references pin the root and closure digests; receivers resolve offline from an authenticated catalog.Policy must require the right profile for the right subject.
Resource exhaustionA bundle, graph, JSON document, regex, or schema closure is crafted to exhaust the verifier.Strict resource bounds, closed path grammar, bounded pattern vocabulary, and fail-closed diagnostics.Implementations must apply limits before expensive work and test adversarial inputs.
Content hazardInvisible Unicode, malicious formulas, PII, or poison data remains byte-for-byte intact.Organizational profiles can constrain structured artifact content and required analysis metadata.Integrity does not equal safety, quality, privacy, or compliance.

Trust boundaries stay outside the bundle

  1. Signing keysPrivate keys and production signing policy are deployment responsibilities. Demo keys are intentionally insecure fixtures.
  2. AuthorizationThe receiver supplies policy; the producer does not get to declare itself trusted.
  3. Expected stateFreshness requires an expected head, manifest, nonce, artifact, age, or transparency record learned independently.
  4. Schema catalogPrivate profiles remain private and are resolved from authenticated local bytes, never ambient network lookup during verification.
Turn attacks into fixtures

A threat becomes useful when it has one exact mutation and one expected denial.

The reference demo already covers artifact mutation, signature failure, predecessor removal, rewiring, private-profile violation, and unauthorized signers. Add the case it missed.