Skip to content

meshmapper Hypotheses

A path hypothesis is a suspect path. It is not a finding.

meshmapper writes records that validate against path-hypothesis.schema.json, and every record has proven: false by definition. Assay owns proof with oracle-backed trials.

Schema Shape

{
  "schema_version": "1.0",
  "id": "privilege_laundering:entry->planner->billing",
  "class": "privilege_laundering",
  "entry": "entry",
  "target": "billing",
  "hops": ["entry", "planner", "billing"],
  "trust_basis_gaps": ["entry->planner"],
  "owasp_asi": "ASI03",
  "atlas": "AML.T0053",
  "rationale": "path reaches a high-privilege sink through an implicitly trusted hop",
  "proven": false,
  "graph_ref": "sha256:..."
}

Required fields are schema_version, id, class, hops, rationale, and proven.

How To Read One

  • entry: node where attacker reach is assumed.
  • target: privileged sink or advertised capability.
  • hops: ordered route through the graph.
  • trust_basis_gaps: implicit-trust edges along the route.
  • graph_ref: hash of the serialized graph that produced the hypothesis.
  • rationale: rule-local explanation of why this path is worth testing.

Proof Boundary

A hypothesis can be useful even when it is wrong: it narrows the search space. It becomes a proof-carrying finding only after an Assay case runs the relevant direct and laundered routes and an oracle confirms the side effect.

Assay M5-lite can bind a selected hypothesis into a case through an explicit binding file. Assay still does not infer concrete payloads or proof from the graph alone.