Specification · Jiffy Trust Protocol

Jiffy Trust Protocol (JTP) v0.1.0

spec_version0.1.0·architectureA (Protocol Gateway)

JTP v0.1.0 is the protocol-layer surface Jiffy publishes for AI artifact trust. It implements AARM Architecture A — a Protocol Gateway placement that sits between calling agent runtimes and the tools, MCPs, skills, and agents they invoke. Every artifact maps to a signed Ed25519 attestation with a tier, a Jiffy Trust Score, IoI flags, and machine-checkable forensic fields. The same surface serves anonymously over HTTPS, machine-callable, byte-deterministic per RFC 8785 (JCS).

Reference paper: arXiv:2602.09433 — Agent Action Receipt Model (AARM): A Protocol-Layer Trust Architecture for Multi-Agent Systems. AARM Working Group, v1.0. JTP claims AARM Architecture A conformance; the manifest at /api/v1/aarm/conformance is the machine-readable view of this same spec.

1. Architecture

JTP implements AARM Architecture A — Protocol Gateway. The gateway is the single point through which artifact invocations are evaluated. It is anonymous-readable, rate-limited, and serves Ed25519-signed JSON. Verifiers do not need a session, an account, or a key handshake.

+---------------------+        +---------------------+        +---------------------+
|   Calling Agent     |        |   JTP Gateway       |        |   Tool / MCP /      |
|   Runtime           | -----> |   (Architecture A)  | -----> |   Skill / Agent     |
|   (Claude, Cursor,  |        |                     |        |                     |
|    Cody, custom)    | <----- |   - tier classify   |        |                     |
+---------------------+        |   - JTS score       |        +---------------------+
                               |   - IoI flags       |
                               |   - signed receipt  |
                               +---------------------+
                                          |
                                          v
                               +---------------------+
                               |   Verifier (anyone) |
                               |   verify Ed25519    |
                               |   verify hash chain |
                               +---------------------+

2. System model

Multi-agent systems compose by allowing autonomous agents to call tools, services, and other agents through well-typed interfaces. The Jiffy Trust Protocol (JTP) sits between the calling agent runtime and the tool/MCP/skill being invoked — what AARM Architecture A calls a Protocol Gateway placement (§3.1).

Every artifact a calling agent might invoke (an MCP server, a Claude skill, an IDE rules file, an `agents.md` doc) is identified by a stable URI. The gateway maps the URI to a signed attestation: tier, Jiffy Trust Score (JTS), Indicators of Insecurity (IoI flags), and machine-checkable forensic fields (chain seq, prev hash, context digest).

The gateway is anonymous-readable, rate-limited, and serves Ed25519-signed JSON over HTTPS. Verifiers do not need a session, an account, or a key handshake — they pull the public key from the JWKS endpoint and verify the signature offline. The signed payload is byte-deterministic per RFC 8785 (JCS) so the same input always produces the same signature input.

3. Threat model

Trusted

JTP gateway service (signs attestations with a key whose public half is published at /.well-known/jiffy-trust-pubkey)
AARM receipts the gateway emits (Ed25519 detached signatures, RFC 8785 JCS canonicalization)
Calling agent runtime holding a verifier (Verifies signatures locally; can audit the chain offline)

Untrusted

Any artifact the calling agent might invoke (untrusted unless the gateway has issued a tier ≤ CAUTION attestation for it)
Network intermediaries (TLS terminates at the gateway; intermediaries cannot forge a valid signature)
Compromised MCP servers, malicious skills, prompt-injected agents.md files

Partially trusted

Agent runtime caller identity (best-effort attribution via `actor` field; AARM Architecture A does not require enrollment)
Cached attestations served from edge / CDN (signed bytes are byte-identical to fresh; freshness window is published in `Cache-Control`)

4. Five-tier action classification

AARM partitions every agent-observable action into one of five tiers. The classifier is pure and deterministic — usable from edge adapters, Node API routes, or unit tests with the same result.

Tier	Description	Examples
T1	Read-only, non-escalating	fs:read, http:GET, git:status
T2	Non-persistent side effects	log:write, metrics:emit, stdout
T3	Local sandbox mutation	fs:write, git:commit (local)
T4	Cross-actor mutation	git:push, slack:post, email:send
T5	Irreversible privileged	dns:change, iam:grant, rm -rf

5. Security objectives (9 / 9 from AARM)

AARM defines 9 security objectives (O1–O9). Each row below names the objective, its honest status against the current Jiffy code path, and the file (line range when stable) where the implementation lives.

Objective	Name	Status	Implementation
O1	Pre-execution interception Every artifact invocation passes through the gateway URL (or the MCP tool wrapper) before the runtime executes. Caller-side wiring (loader hook in the runtime) is required for true blocking; the protocol surface itself ships in production.	Met	web/src/app/api/v1/trust/route.ts (Sprint 12) + jiffy_trust_check MCP tool (Sprint J.2, jiffy-scan-mcp-server/packages/typescript/src/tools/jiffy-trust-check.ts)
O2	Policy compliance JTS scoring + 5-tier classification produce a deterministic per-artifact policy verdict. Policy is enforced inline at the protocol layer.	Met	web/src/app/api/v1/trust/route.ts + Jiffy Trust Score + tier mapping (web/src/lib/aarm/tiers.ts)
O3	Context-aware evaluation Per-receipt context digest is computed (sha256 of canonicalized context), so two semantically equivalent contexts collapse to the same hash. Session-level accumulation (C_n = C_{n-1} ∪ {a_n, o_n, δ_n}) is explicitly Non-Goal 4 and lands in a future sprint.	Partial	web/src/lib/aarm/receipt.ts::contextDigest (line 99)
O4	Classification-based decisions 5-tier classifier in production. Pure deterministic function; no DB, no network, no LLM — usable from edge adapters or unit tests with the same result.	Met	web/src/lib/aarm/tiers.ts (83+ pre-classified actions, regex fallback, Tier 3 default)
O5	Inline enforcement Sub-200ms p99 hot path published with the X-Jiffy-Latency-Ms header; single-region today (us-east1), explicitly noted in SLA docs.	Met	F1 SLA contract (Sprint J.1, web/src/lib/jtp/latency.ts) + F2 MCP loop (Sprint J.2)
O6	Human escalation Tool returns a `defer` recommendation for CAUTION/PENDING tiers and `deny` for RISKY/CRITICAL — the calling runtime is expected to surface a UI prompt or hand off to an approval queue. Approval-queue UI is out of MVP and tracked separately.	Met	jiffy-scan-mcp-server/packages/typescript/src/tools/jiffy-trust-check.ts::deriveRecommendation (T4/T5 → defer/deny). Approval queue forward-link: TBD (J.5 readiness pass or future Y.x sprint).
O7	Least privilege Anonymous public read on /v1/trust and /v1/verify. No PII, no Clerk required. Higher rate limits with an API key; baseline is anonymous-callable.	Met	web/src/middleware.ts (anonymous public matcher for /api/v1/trust + /api/v1/verify)
O8	Forensic completeness Each receipt embeds sha256(canonicalize(prev_receipt)). Genesis prev_hash = 64 zeros. Public verifier endpoint accepts arrays of receipts and returns {valid, brokenAt, reason}.	Met	web/src/lib/aarm/receipt.ts::verifyChain (line 237). Hash chain in production; chain offline-verifiable via POST /api/v1/aarm/verify-chain.
O9	Identity attribution Every receipt carries an `actor` URI and a `signing_key_id` so the issuing key is identifiable. Caller identity is best-effort — AARM Architecture A does not require enrollment, and Jiffy does not yet enforce a strong-attribution flow.	Partial	web/src/lib/aarm/receipt.ts (actor field) + web/src/app/api/v1/trust/route.ts (signing_key_id)

6. AARM structural elements (4)

Beyond the 9 security objectives, AARM defines four structural elements (§3.1, §4, §5, §6).

Section	Element	Status	Implementation
§3.1	Protocol Gateway placement JTP gateway sits between agent runtimes and tool providers, served at /api/v1/trust and surfaced to MCP clients via jiffy_trust_check.	Met	web/src/app/api/v1/trust/route.ts + jiffy-scan-mcp-server/packages/typescript/src/tools/jiffy-trust-check.ts
§4	Hash-chained tamper-evident receipts sha256-chained receipts, RFC 8785 JCS canonicalization, Ed25519 detached signatures, public verifier endpoint.	Met	web/src/lib/aarm/receipt.ts::verifyChain (line 237)
§5	Semantic distance Stub shape exists for the function signature; real cosine-distance implementation is explicitly Non-Goal 3 in spec-jtp.md and tracked for a follow-up sprint.	Deferred	web/src/lib/aarm/receipt.ts::semanticDistanceStub (line 310) — typed shape only
§6	Context accumulation Per-receipt context digest is computed; cross-receipt session accumulation (C_n = C_{n-1} ∪ {a_n, o_n, δ_n}) is Non-Goal 4 in spec-jtp.md.	Partial	web/src/lib/aarm/receipt.ts::contextDigest (line 99) — per-receipt only

7. Endpoint references

Trust APIhttps://jiffylabs.app/api/v1/trust
Verify chainhttps://jiffylabs.app/api/v1/aarm/verify-chain
Public keyhttps://jiffylabs.app/.well-known/jiffy-trust-pubkey
SLAhttps://jiffylabs.app/api/v1/trust/sla
Conformance manifesthttps://jiffylabs.app/api/v1/aarm/conformance
MCP tooljiffy_trust_check (jiffy-scan-mcp v0.5.1)

8. Example response

Every /api/v1/trust response carries an RFC 8288 Link header pointing at the conformance manifest plus a body-side aarm_conformance field for clients that prefer JSON-only discovery.

GET /api/v1/trust?artifact=mcp://example/server&type=mcp HTTP/1.1
Accept: application/json

200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=86400
X-Jiffy-Cache: HIT
X-Jiffy-Latency-Ms: 142
Link: </api/v1/aarm/conformance>; rel="aarm-conformance"; type="application/json"

{
  "artifact": "mcp://example/server",
  "type": "mcp",
  "jts": 84,
  "tier": "TRUSTED",
  "ioi_flags": [],
  "framework_codes": ["LLM07"],
  "attested_at": "2026-04-24T13:00:00.000Z",
  "attestation_id": "...",
  "signing_key_id": "jtp-v0.1.0-ed25519-001",
  "signature": "...",
  "aarm_conformance": {
    "architecture": "A",
    "spec_version": "0.1.0",
    "manifest_url": "https://jiffylabs.app/api/v1/aarm/conformance"
  }
}

9. Honest conformance summary

9/13 Met, 3 Partial, 1 Deferred — AARM Architecture A: Substantially Conformant

The score above is computed from the per-objective + per-structural statuses on this page. Composition: 9 Met, 3 Partial, 1 Deferred — total 13 conformance items (9 AARM objectives + 4 structural elements). "Substantially Conformant" is the honest framing for AARM Architecture A when most objectives are Met but some are scoped to follow-up work (semantic distance impl, session-level context accumulation, full identity-attribution flow).

Looking for the clause-by-clause AARM mapping (§-by-§ tables, example receipt, chain-verifier example)? See /docs-public/aarm-conformance. Both views are sourced from the same JTP_SPEC module — status counts cannot drift.