Product tour · Verified-State API & MCP

See how Tokynd Verified-State API works — end to end

Ask the platform one question — 'is this control satisfied right now, and where's the proof?' — and get a signed answer, over API or MCP.

STEP 01

State is written

Every product writes its verified state to the Assurance Graph: closures, tiers, posture, evidence.

STEP 02

Your tools ask

A CI gate, an auditor's tool, or another agent asks one question over the API or MCP: is this control satisfied — and what's the proof?

STEP 03

A signed answer

The response carries the state plus a reference to its signed proof — never a screenshot, never a promise.

STEP 04

Verify, offline

The consumer verifies the proof independently. Stale or unsigned state fails closed.

Watch it run

The Verified-State API is in build. This is the designed exchange, stage by stage.

verified-state · designed flowtokynd
# the question — as designed GET /verified-state?control=SOC2-CC6.1&asset=crm-lookup → or the same question over MCP, from an agent
# the answer { "control": "SOC2-CC6.1", "asset": "crm-lookup", "state": "satisfied", "as_of": "latest verified closure", "proof": "evidence-pack://… · signed" }
✓

Offline verification — the consumer checks the proof's signature — no Tokynd account, no portal

✓

Fails closed — stale or unsigned state is refused, never presented as satisfied

A worked example — the designed flow

Illustrative exchange

InputA control question, over API or MCP
LookupThe Assurance Graph's verified state
OutputThe state + a reference to its signed proof
ProofOffline-verifiable; stale or unsigned fails closed
In buildIn build — the API/MCP surface over the Assurance Graph.
← All product tours Register interest