Attesto

SDKs

SDK Python, TypeScript, CLI i Go

Attesto udostępnia cztery first-class developer surfaces: Python, TypeScript, Go oraz Attesto CLI. Współdzielą ten sam Proofstream protocol, golden vectors, verifier matrix, production origin oraz zasady secret-handling.

Package registries

Oficjalne package identifiers to attesto dla Python oraz @attesto/sdk dla TypeScript. Aktualna rodzina release to 0.5.0 dla Python, TypeScript, Go i CLI, i jest to pierwsze wydanie zawierające weryfikatory pochodzenia Attesto 3. Moduł Go go.attesto.eu/sdk v0.5.0 oraz jego moduł krzywej go.attesto.eu/sdk/zk v0.5.0 są opublikowane. Wheel PyPI attesto==0.5.0 i package npm @attesto/sdk==0.5.0 są opublikowane (2026-08-23), a oba rejestry rozwiązują 0.5.0 jako latest; podpisany kanał CLI na get.attesto.eu również serwuje 0.5.0, z installerami dla Linux/macOS (curl | sh) i Windows (irm | iex). Instaluj wyłącznie z oficjalnych rejestrów PyPI i npm; nie instaluj SDKs z mirrors, losowych tarballs ani source snapshots.

Release gate rozdziela packages od surfaces: registry readiness oczekuje trzech package/module distributions (attesto, @attesto/sdk i modułu Go) oraz czterech production developer surfaces, ponieważ CLI attesto jest first-class Go-backed verifier surface. Gate musi raportować surfacesExpected=4, surfacesReady=4, cliReady=true oraz cliVersionMatches=true.

Package artifacts są celowo minimalne. npm artifacts zawierają tylko runtime JavaScript, declaration files, README.md i package metadata. Produkcyjne releases PyPI są wheel-only. Sourcemaps, raw TypeScript source, tests, caches, source archives, frontend bundles, API keys, private keys i secret-like material są zabronione.

Authentication model

System-key clients są używane do event ingest, stream heads, receipts, public proof objects, bundles i remote verification. Tenant/operator clients używają dashboard bearer token dla tenant stream lists, connector installation, Local Vault installation, fork evidence inspection, proof-state views i tenant audit-pack creation. Nie umieszczaj żadnych tych credentials w frontend code.

Wsparcie Article 13 i evidence Article 12 jedną linią integracji

Dla systemów AI high-risk Article 12 dotyczy technicznej zdolności loggingu i traceability, a Article 13 dotyczy transparentności oraz użytecznych informacji dla deployers i użytkowników. W terminach Attesto dokładna linia integracji to export OPENAI_BASE_URL=http://localhost:8765/v1: kieruje wywołania OpenAI-compatible do Attesto Gateway, aby automatyczne zbieranie evidence mogło się rozpocząć. Deterministyczny Article 12 report wyjaśnia, co zostało zapisane i co jest niezależnie weryfikowalne, a ten sam receipt-backed trail może wspierać dokumentację Article 13. To wsparcie dowodowe, nie deklaracja zgodności prawnej.

Konkretna jednowierszowa integracja gateway, która to umożliwia, to:

export OPENAI_BASE_URL=http://localhost:8765/v1

W produkcji zastąp localhost wdrożonym hostem gateway i trzymaj zarówno provider key, jak i Attesto system key w server-side secret storage.

Użyj tego wzorca, gdy kontrolujesz granicę funkcji Python. Dekorator zapisuje commitments dla argumentów, wartości zwrotnej, timingu, source reference i failures; report podsumowuje coverage bez LLM.

from attesto import AttestoV2Client, attest, article12
import os

with AttestoV2Client(api_key=os.environ["ATTESTO_API_KEY"]) as capture:
    @attest(capture, stream_id="str_...")
    def score_case(case: dict) -> dict:
        return {"decision": "manual_review", "policy_id": "policy-2026-01"}

    score_case({"case_id": "case-2026-0001"})
with AttestoV2Client.with_bearer_token(os.environ["ATTESTO_TENANT_TOKEN"]) as operator:
    print(article12(operator, "str_..."))

Capture path używa system API key; report path czyta tenant stream events i dlatego wymaga tenant/operator bearer token.

attesto --token-env ATTESTO_TENANT_TOKEN \
  report article12 --stream str_... --output report.md

Co obsługuje SDK

SDKs są celowo cienkimi server-side clients. Nie ukrywają evidence model, ale usuwają powtarzalną pracę transportową, aby aplikacja mogła skupić się na wyborze właściwego event shape i weryfikacji zwróconej evidence.

ObszarZachowanie SDKOdpowiedzialność developera
Base URLDomyślnie https://verify.attesto.eu.Nadpisuj tylko dla private/staging deployments.
AuthenticationObsługuje system API-key mode i tenant bearer-token mode.Użyj najwęższej credential potrzebnej do zadania.
IdempotencyTworzy idempotency keys dla writes, jeśli nie zostały dostarczone.Użyj tej samej key przy ponownym retry tego samego body z własnego job system.
RetriesRetry dla przejściowych błędów 429, 5xx i transport errors z backoff.Nie zmieniaj payloads między retries.
Proofstream helpersUdostępnia helpers dla stream, receipt, checkpoint, anchor, IVC, bundle i verify.Świadomie wybierz stream granularity i policy IDs.
ErrorsZwraca typed auth, validation, rate-limit i server errors.Loguj bezpieczne error categories, nie API keys ani raw secret-bearing payloads.

Capability matrix

CapabilityPythonTypeScriptGoCLI
Streams/events/receiptsTakTakTakTak
Windows/checkpoints/consistencyTakTakTakTak
Remote verifier APITakTakTakTak
Offline receipt verificationVerifier helper/APIVerifier helper/APITakTak
Witness policy and fork evidenceTakTakTakTak
Anchors and IVC epochsTakTakTakTak
ConnectorsTakTakTakTak
Local Vault relay/witnessTakTakTakTak
Weryfikacja pochodzenia (Attesto 3): disclosure, bundle provenance, key revocation, effective assurance, ZK range resultTak (offline)Tak (offline)Tak (offline)Nie
Dokładne otwarcie private numeric (Pedersen)extra attesto[zk]peer @noble/curvesmoduł go.attesto.eu/sdk/zkNie
Release readiness evidenceVia scriptsVia scriptsVia CLI/module testsTak

Python

pip install attesto
import os
from datetime import UTC, datetime
from attesto import AttestoClient

attesto = AttestoClient(api_key=os.environ["ATTESTO_API_KEY"])
ack = attesto.log_event(
    type="inference",
    status="verified",
    ts=datetime.now(UTC),
    payload={
        "model": "risk-service-v4",
        "score": 0.91,
        "policy_id": "policy-2026-01",
    },
)
print(ack.id)

Python async

import os
from datetime import UTC, datetime
from attesto import AsyncAttestoClient

async with AsyncAttestoClient(api_key=os.environ["ATTESTO_API_KEY"]) as attesto:
    ack = await attesto.log_event(
        type="ai.decision",
        status="verified",
        ts=datetime.now(UTC),
        payload={"decision": "manual_review", "score": 91},
    )
    print(ack.id)

TypeScript

npm install @attesto/sdk
import { AttestoClient } from "@attesto/sdk";

const attesto = new AttestoClient({
  apiKey: process.env.ATTESTO_API_KEY!,
});

const ack = await attesto.logEvent({
  type: "inference",
  status: "verified",
  ts: new Date(),
  payload: {
    model: "risk-service-v4",
    score: 0.91,
    policy_id: "policy-2026-01",
  },
});
console.log(ack.id);

TypeScript attestedFetch

Użyj attestedFetch, gdy SDK lub framework OpenAI-compatible akceptuje custom fetch implementation. Rejestruje tylko commitments, nigdy raw prompts ani completions. strict: true failuje zamknięcie, gdy evidence nie może zostać wysłane; tryb fail-open musi być monitorowany.

import { AttestoV2Client, attestedFetch } from "@attesto/sdk";

const client = new AttestoV2Client({ apiKey: process.env.ATTESTO_API_KEY! });
const fetchWithEvidence = attestedFetch(client, {
  streamId: "str_...",
  capture: "commitments",
  strict: true,
});

Proofstream v2 client

Użyj AttestoV2Client, gdy potrzebujesz stream-level receipts, checkpoint consistency, witness policy visibility, verifier bundles i offline verification helpers.

from attesto import AttestoV2Client
from datetime import UTC, datetime
import os

with AttestoV2Client(api_key=os.environ["ATTESTO_API_KEY"]) as attesto:
    stream = attesto.create_stream(
        use_case="ai-decision-history",
        policy_id="policy-2026-01",
    )
    receipt = attesto.log_event(
        stream_id=stream.stream_id,
        source_ref="source-event-001",
        event_type="decision",
        occurred_at=datetime.now(UTC),
        payload={"decision": "review", "score": 91},
    )
    stored = attesto.get_receipt(receipt.stream_event_id)
    report = attesto.verify_receipt(
        receipt=stored.receipt,
        public_key_hex=os.environ["ATTESTO_RECEIPT_SIGNER_PUBLIC_KEY_HEX"],
        stream_event_id=receipt.stream_event_id,
    )
    assert report.ok

TypeScript Proofstream:

import { AttestoV2Client } from "@attesto/sdk";

const attesto = new AttestoV2Client({
  apiKey: process.env.ATTESTO_API_KEY!,
});

const stream = await attesto.createStream({
  useCase: "ai-decision-history",
  policyId: "policy-2026-01",
});

const receipt = await attesto.logEvent(stream.streamId, {
  sourceRef: "case-2026-0001:decision-1",
  eventType: "ai.decision",
  occurredAt: new Date(),
  payload: { decision: "manual_review", score: 91 },
});

const report = await attesto.verifyReceipt({
  receipt: receipt.receipt,
  streamEventId: receipt.streamEventId,
  publicKeyHex: process.env.ATTESTO_RECEIPT_SIGNER_PUBLIC_KEY_HEX!,
});
if (!report.ok) throw new Error(report.problems.join("; "));

Go

Użyj Go do infrastructure automation, security tooling, cloud workers i verifier services. Go SDK używa obecnie wyłącznie Go standard library i jest rozwiązywany z module path repozytorium Attesto.

go get go.attesto.eu/sdk
package main

import (
  "context"
  "fmt"
  "log"
  "os"

  attesto "go.attesto.eu/sdk"
)

func main() {
  client, err := attesto.NewClient(os.Getenv("ATTESTO_API_KEY"))
  if err != nil {
    log.Fatal(err)
  }

  stream, err := client.CreateStream(context.Background(), attesto.StreamCreateInput{
    UseCase: "ai-decision-history",
    PolicyID: "policy-2026-01",
  })
  if err != nil {
    log.Fatal(err)
  }

  receipt, err := client.LogEvent(context.Background(), stream.StreamID, attesto.EventInput{
    SourceRef: "case-2026-0001:decision-1",
    EventType: "ai.decision",
    Payload: attesto.M{"decision": "manual_review", "score": 91},
  })
  if err != nil {
    log.Fatal(err)
  }

  fmt.Println(receipt.StreamEventID, receipt.EventHash)
}

CLI

Attesto CLI to operator i verifier surface dla scripted workflows. Obsługuje JSON output, local config, stream/event actions, receipt verification, bundle verification, fork evidence, quorum evidence, connectors, Local Vault i release-readiness evidence checks. Nigdy nie wypisuje zapisanych API keys, tenant tokens ani connector secrets.

Zainstaluj podpisaną CLI z get.attesto.eu. Installery weryfikują sumę SHA256 release'u, zanim cokolwiek zostanie zainstalowane, a podpis manifestu można zweryfikować przez cosign. Formuła Homebrew i natywne pakiety Linuksa przepakowują te same binaria kanału: ich hashe pochodzą z podpisanego przez cosign manifestu SHA256SUMS, nigdy z osobnego builda:

# Linux / macOS
curl -fsSL https://get.attesto.eu | sh

# Windows (PowerShell; user-level install, no admin rights)
irm https://get.attesto.eu/install.ps1 | iex

# macOS / Linux (Homebrew)
brew tap attesto/attesto https://git.attesto.eu/attesto/homebrew-attesto.git
brew trust attesto/attesto
brew install attesto

# Native Linux packages: verify the signed manifest first
curl -fsSLO https://get.attesto.eu/0.5.0/SHA256SUMS
curl -fsSLO https://get.attesto.eu/0.5.0/SHA256SUMS.sig
cosign verify-blob --key https://get.attesto.eu/cosign.pub --insecure-ignore-tlog --signature SHA256SUMS.sig SHA256SUMS

# Debian / Ubuntu (run the install as root; arm64 debs and aarch64 rpms
# are on the same channel)
curl -fsSLO https://get.attesto.eu/0.5.0/attesto_0.5.0-1_amd64.deb
sha256sum -c --ignore-missing SHA256SUMS
apt install ./attesto_0.5.0-1_amd64.deb

# Fedora / RHEL (run the install as root)
curl -fsSLO https://get.attesto.eu/0.5.0/attesto-0.5.0-1.x86_64.rpm
sha256sum -c --ignore-missing SHA256SUMS
dnf install ./attesto-0.5.0-1.x86_64.rpm

Pakiety arm64/aarch64 są zweryfikowane na poziomie metadanych względem podpisanego manifestu, ale nie były uruchamiane na sprzęcie arm.

CLI command reference

Command groupSubcommandsUżycie
version, config, login, logoutconfig get, config setSprawdź wersję i zarządzaj lokalną redacted configuration.
streamscreate, get, headTwórz streams, inspect tenant-visible stream metadata i pobieraj append-only head.
eventslog, batchWyślij jeden event albo JSON event batch z source timestamps i payload files.
receiptsget, verifyPobierz stored receipt i zweryfikuj lokalnie albo przez /v2/verify/receipt.
windows, checkpoints, anchors, ivcget, verify, checkpoints consistency, ivc epochs get/verifyPobieraj i weryfikuj Proofstream windows, checkpoint roots, consistency proofs, anchor epochs i IVC epochs.
witnesses, quorum, fork-evidencepolicies, status, receipts, inspect, verifyInspect witness policy, proof state, quorum material i fork evidence.
bundles, verifybuild, get, verify, offline-verify, verify file, verify truth-packageBuduj verifier bundles i weryfikuj bundles, portable receipt files albo Truth Package ZIPs.
connector, connectorsconnector init, connectors create, ingest, revoke, verifyScaffold connector manifests, zarządzaj tenant connectors, ingest events i weryfikuj signed connector payloads.
local-vaultinstall, relay, spool, status, witness, fork-evidence, revokeObsługuj Local Vault installations, encrypted spool workflows, witness receipts, fork evidence i revocation.
marketplaceinit, validate, submitPrzygotuj publisher manifests, waliduj je lokalnie i submit assets do prywatnej review Attesto.
doctor, report, readinessreport article12, readiness lifecycle/fork-defense/quorum/assurance/connectors/local-vault/nova/productionUruchamiaj install diagnostics, deterministic Article 12 reporting i release-readiness evidence checks.
cd sdk/go
go run ./cmd/attesto --json version

go run ./cmd/attesto --json \
  --api-key-env ATTESTO_API_KEY \
  streams create \
  --use-case ai-decision-history \
  --policy-id policy-2026-01

Offline receipt verification:

go run ./cmd/attesto --json receipts verify \
  --file receipt.json \
  --public-key-hex "$ATTESTO_RECEIPT_SIGNER_PUBLIC_KEY_HEX"

Production readiness evidence check:

go run ./cmd/attesto --json readiness lifecycle
go run ./cmd/attesto --json readiness fork-defense
go run ./cmd/attesto --json readiness production

Marketplace publisher automation:

go run ./cmd/attesto --json marketplace init \
  --output attesto.connector.json \
  --slug signed-webhook-evidence \
  --name "Generic Signed Webhook Evidence" \
  --version 1.0.0 \
  --category compliance \
  --summary "Produces Attesto evidence for signed webhook events." \
  --description "Produces verifiable Proofstream events for signed webhook payloads." \
  --publisher-slug attesto \
  --publisher-name Attesto \
  --repository-url https://git.rotz.ai/attesto/attesto-v1/src/branch/attesto-2.0/connectors/webhook \
  --docs-url https://docs.attesto.eu/manuals/connectors.html#signed \
  --provider-url https://docs.attesto.eu/manuals/connectors.html#signed \
  --auth-mode signed-webhook \
  --auth-scopes webhook:read \
  --sync-modes webhook \
  --event-types webhook.event.received \
  --canary-ref release/attesto-2.0-connector-assurance-readiness/result.json \
  --capabilities proofstream,offline-verification

go run ./cmd/attesto --json marketplace validate \
  --manifest-file attesto.connector.json

go run ./cmd/attesto --json \
  --token-env ATTESTO_TENANT_TOKEN \
  marketplace submit \
  --manifest-file attesto.connector.json \
  --source-ref https://git.rotz.ai/attesto/attesto-v1/src/branch/attesto-2.0/connectors/webhook \
  --visibility public \
  --pricing-model free

Operator endpoints

Tenant/operator endpoints wymagają bearer-token mode. Używaj tego tylko w trusted operator automation i nigdy w public clients.

from attesto import AttestoV2Client

operator = AttestoV2Client.with_bearer_token(
    os.environ["ATTESTO_TENANT_TOKEN"],
)
streams = operator.list_tenant_streams()
forks = operator.list_fork_evidence(streams[0]["streamId"])
const operator = new AttestoV2Client({
  apiKey: process.env.ATTESTO_TENANT_TOKEN!,
  authMode: "bearer",
});

const streams = await operator.listTenantStreams();
const forks = await operator.listForkEvidence(String(streams[0].streamId));
operator, err := attesto.NewBearerClient(os.Getenv("ATTESTO_TENANT_TOKEN"))
if err != nil { log.Fatal(err) }
streams, err := operator.ListTenantStreams(context.Background(), "", 100, 0)
if err != nil { log.Fatal(err) }

Offline i online verify helpers

SDK verification methods są użyteczne w usługach, które otrzymują Attesto receipts lub bundles i muszą fail-closed przed ich akceptacją.

from attesto import AttestoV2Client
from datetime import UTC, datetime
import os

with AttestoV2Client(api_key=os.environ["ATTESTO_API_KEY"]) as attesto:
    report = attesto.verify_object(
        kind="bundle",
        proof_object=bundle_object,
    )
    if not report.ok:
        raise RuntimeError(report.problems)
const report = await attesto.verifyObject({
  kind: "bundle",
  object: bundleObject,
});

if (!report.ok) {
  throw new Error(report.problems.join("; "));
}

Weryfikacja pochodzenia (Attesto 3)

SDK 0.5.0 dodają klienta weryfikacji dla provenance lane Attesto 3: provenance streams typu commitment-only zasilanych przez Local Vault kontrolowany przez klienta. Przypięty Rust edge core vaulta buduje capsules, commitments i podpisy; SDK wyprowadza je ponownie i sprawdza, a celowo nie potrafi zbudować capsule ani randomizera. Każda funkcja w tej sekcji działa offline, bez wywołania Attesto, a każdy raport zawiera listę not_claimed, którą ekran weryfikatora musi pokazać obok wyniku. Protokoły: ATTESTO-PROVENANCE-001, ATTESTO-DISCLOSURE-001, ATTESTO-ZK-RANGE-001 oraz bundle provenance binding z ATTESTO-PROOFSTREAM-001. Zgodność jest przypięta przez wspólny korpus golden vectors we wszystkich trzech językach.

WeryfikatorPython (attesto.provenance)TypeScript (@attesto/sdk)Go (go.attesto.eu/sdk)
Disclosure presentationverify_disclosureverifyDisclosureVerifyDisclosure
Bundle provenance inclusion + key revocationverify_bundle_provenance, evaluate_key_revocationverifyBundleProvenance, evaluateKeyRevocationVerifyBundleProvenance, EvaluateKeyRevocation
Effective assuranceeffective_assuranceeffectiveAssuranceEffectiveAssurance
Dokładne otwarcie private numericverify_pedersen_opening (attesto[zk])verifyPedersenOpening (@noble/curves peer)zk.VerifyOpening (go.attesto.eu/sdk/zk)
ZK range resultinspect_predicate_result, validate_range_statementinspectPredicateResult, validateRangeStatementInspectPredicateResult, ValidateRangeStatement

Weryfikacja disclosure presentation offline

Local Vault posiadacza wystawia selective-disclosure presentation: ujawnione leaves z ich randomizerami, two-hop inclusion proofs do capsule root oraz podpis Ed25519 wystawiającej instalacji. Weryfikator otwiera każdy ujawniony commitment i odtwarza każdy proof aż do przedstawionej capsule_root. Problemy są zbierane, a nie rzucane, aby wywołujący zobaczył wszystko, co jest nie tak. Przekaż wydany przez siebie nonce dla trybu challenge; bez niego presentation jest ograniczona tylko przez expires_at, a raport podaje bounded_lifetime zamiast sugerować świeżość, której nie sprawdził. Non-claim: disclosure dowodzi, że ujawnione leaves są w capsule; nie jest stwierdzeniem, że capsule nie zawiera niczego więcej.

from attesto.provenance import verify_disclosure

report = verify_disclosure(
    presentation,
    expected_nonce=challenge,
    subject_commitment=asset_commitment,
)
report.ok               # every leaf opened and every proof folded to capsule_root
report.verified_leaves  # ({"subtree": "claims", "leaf_role": "c2pa_manifest_valid", "value": ...},)
report.freshness        # "challenge" | "bounded_lifetime"
report.subject_checked  # True only when subject_commitment matched
report.problems         # () or every problem found
report.not_claimed      # ({"id": "undisclosed_facts_absent", "statement": ...},)
import { verifyDisclosure } from "@attesto/sdk";

const report = await verifyDisclosure(presentation, {
  expectedNonce: challenge,
  subjectCommitment: assetCommitment,
});
report.ok; report.verified_leaves; report.freshness;
report.subject_checked; report.problems; report.not_claimed;
report := attesto.VerifyDisclosure(presentation,
	attesto.WithExpectedNonce(challenge),
	attesto.WithSubjectCommitment(assetCommitment),
)
report.Ok; report.VerifiedLeaves; report.Freshness
report.SubjectChecked; report.Problems; report.NotClaimed

Weryfikacja bundle provenance inclusion i key revocation offline

Verifier bundle nad provenance stream zawiera provenance_root, provenance_event_count i vault_key_lifecycle wewnątrz hashowanego payloadu. Inclusion object, zwracany przez GET /v2/streams/{streamId}/provenance-events/{sourceRef}/bundle-inclusion?from_checkpoint_id=...&to_checkpoint_id=... lub przenoszony jako provenance_inclusions obok bundle, dowodzi jednego capsule root pod tym rootem. Weryfikator przelicza bundle hash, ponownie hashuje leaf z jego pól, odtwarza proof, bierze receipt time dla seq_no leafa z własnych receipts bundle i stosuje zamrożoną regułę revocation do instalacji, którą leaf wskazuje. inclusion i key_status pozostają rozdzielone: capsule root może być dowodliwie pod bundle, podczas gdy jego klucz został unieważniony przed odbiorem, a not_evaluated nigdy nie jest zaliczeniem. Revocation jest oceniana względem platform receipt time, nigdy względem deklarowanego przez vault occurred_at, z granicą włączającą; deklaracja sprzed unieważnienia otrzymuje flagę suspect_backdated. Non-claims: root dowodzi, że capsule root istniał pod bundle, i niczego o zawartości capsule; key lifecycle jest stanem z chwili budowy bundle, więc późniejsze unieważnienie nie znajduje się w bundle.

from attesto.provenance import evaluate_key_revocation, verify_bundle_provenance

report = verify_bundle_provenance(bundle, inclusion)
report.ok          # bundle hash holds, inclusion VALID, key live at receipt
report.inclusion   # "VALID" | "INVALID"
report.key_status  # "valid" | "revoked_at_receipt" | "unknown_installation" | "not_evaluated"
report.flags       # e.g. ("revoked_at_receipt", "suspect_backdated")
report.not_claimed # three statements

verdict = evaluate_key_revocation(
    revoked_at=key_status["revokedAt"],          # None when never revoked
    receipt_time=receipt["payload"]["issued_at"],
    claimed_occurred_at=envelope["occurred_at"],
    reason=key_status["revocationReason"],
)
verdict.accepted   # status == "valid"
import { evaluateKeyRevocation, verifyBundleProvenance } from "@attesto/sdk";

const report = await verifyBundleProvenance(bundle, inclusion);
report.ok; report.inclusion; report.key_status; report.flags; report.not_claimed;

const verdict = evaluateKeyRevocation(
  keyStatus.revokedAt,
  receipt.payload.issued_at,
  envelope.occurred_at,
  keyStatus.revocationReason,
);
verdict.accepted;
report := attesto.VerifyBundleProvenance(bundle, inclusion)
report.Ok; report.Inclusion; report.KeyStatus; report.Flags; report.NotClaimed

verdict := attesto.EvaluateKeyRevocation(revokedAt, receiptTime, claimedOccurredAt, reason)
verdict.Accepted()

Wyprowadzanie effective assurance (L3 jest wyprowadzane, nigdy podpisywane)

Vault podpisuje w swoim envelope L0 (klucz programowy), L1 (klucz w nieekstrahowalnym tokenie PKCS#11) lub L2 (L1 plus quote TPM 2.0 nad pomiarem vaulta), a platforma odrzuca envelope L1/L2, którego nie może potwierdzić zarejestrowaną attestation. L3 nie ma reprezentacji na łączu: weryfikator wyprowadza je z L2 plus osiągniętego witness quorum na obejmującym checkpoint, a envelope deklarujący L3 jest odrzucany. Stan anchora jest raportowany obok i nigdy nie podnosi poziomu. Raport utrzymuje vault assurance, witness quorum, stan anchora i wyprowadzony poziom jako cztery osobne fakty. Sposób zdobywania poziomów opisuje przewodnik Local Vault.

from attesto.provenance import effective_assurance

report = effective_assurance("L2", witness_quorum_met=True, anchor_confirmed=True)
report.effective  # "L3"
report.derived    # True: derived here, signed by nobody
report.reasons    # ("anchor confirmed; anchoring does not promote assurance", "L3 derived from L2 plus a met witness quorum")
effective_assurance("L2").effective  # "L2": quorum not evaluated withholds L3
effective_assurance("L3")            # raises AttestoProvenanceError
import { effectiveAssurance } from "@attesto/sdk";

const report = effectiveAssurance("L2", { witnessQuorumMet: true, anchorConfirmed: true });
report.effective; // "L3"
report.derived;   // true
report.reasons;
met := true
report, err := attesto.EffectiveAssurance("L2", &met, &met)
report.Effective // "L3"
report.Derived   // true
report.Reasons

Weryfikacja dokładnego otwarcia private numeric

Private numeric claim zobowiązuje swoją zakodowaną wartość jako Pedersen commitment nad ristretto255. Gdy posiadacz ujawnia wartość i blinding, weryfikator przelicza commitment i porównuje go bajt po bajcie. Arytmetyka krzywej jest opcjonalna, bo reszta weryfikacji to praca SHA-256 i Merkle: Python potrzebuje attesto[zk], TypeScript peer dependency @noble/curves, a Go osobnego modułu go.attesto.eu/sdk/zk. Klient bez niej raportuje not_checked. Descriptor musi już mieć otwarty swój claim leaf pod capsule root, inaczej pasującą parę można sfabrykować w całości. Wartość dokładnie zero jest poprawnym otwarciem. To nie weryfikuje range proof.

from attesto.provenance import pedersen_available, verify_pedersen_opening

opened = (
    verify_pedersen_opening(descriptor, encoded_value, blinding_scalar)
    if pedersen_available()
    else None  # report "not_checked"
)
import { pedersenAvailable, verifyPedersenOpening } from "@attesto/sdk";

const opened = (await pedersenAvailable())
  ? await verifyPedersenOpening(descriptor, encodedValue, blindingScalar)
  : null; // report "not_checked"
import "go.attesto.eu/sdk/zk"

opened, err := zk.VerifyOpening(descriptor, encodedValue, blindingScalar)

Inspekcja ZK range result

Selective disclosure v2 dowodzi, że pomiar wskazanego detektora mieścił się w przedziale, bez jego ujawniania. Żaden SDK nie weryfikuje samego range proof; to pozostaje zadaniem Rust core. SDK raportuje zk_predicate: not_checked pod verified_here, zachowuje to, co deklarował wystawca, pod reported_by_issuer i odrzuca wynik, który pomija jeden z trzech wymaganych non-claims albo zawiera pole w kształcie werdyktu, takie jak authentic, score lub probability. Udowodniona granica nie mówi nic o tym, czy treść została wygenerowana maszynowo. Capsule evidence z providera AttestoMark Image, Audio lub Video to obiekt ATTESTO-PROVIDER-RESULT-001/0.2, którego pole presented_matches_record raportuje, czy przedstawione bajty były dokładnie oznaczonym assetem; niezgodność to obserwacja, którą daje także uczciwe transkodowanie, nigdy odmowa.

from attesto.provenance import inspect_predicate_result, validate_range_statement

report = inspect_predicate_result(result)
report["verified_here"]       # {"zk_predicate": "not_checked", "capsule_inclusion": "not_checked"}
report["reported_by_issuer"]
report["not_claimed"]         # detector_correctness_not_proven, content_truth_not_proven, ai_generation_not_proven
width = validate_range_statement(statement)  # 8 | 16 | 32 | 64
import { inspectPredicateResult, validateRangeStatement } from "@attesto/sdk";

const report = inspectPredicateResult(result);
report.verified_here; report.reported_by_issuer; report.not_claimed;
const width = validateRangeStatement(statement);
report, err := attesto.InspectPredicateResult(result, nil)
report.VerifiedHere; report.ReportedByIssuer; report.NotClaimed
width, err := attesto.ValidateRangeStatement(statement)

Nie ma w SDK: budowa capsule, generowanie randomizera i podpisywanie envelope żyją w edge core Local Vault; range proofs weryfikuje tylko Rust core; nie ma jeszcze client wrappera dla POST /v2/provenance/streams; a CLI attesto w 0.5.0 nie weryfikuje disclosures ani bundle provenance.

MockAttesto do testów lokalnych

attesto.testing.MockAttesto to Python test harness dla lokalnego CI i testów integracyjnych. Używa tego samego canonical hashing i receipt shapes co SDK, ale podpisuje per-instance throwaway mock key i oznacza obiekty jako mock evidence. Używaj go do testowania application flow bez sieci i bez konta Attesto; nie używaj mock receipts w production evidence ani customer bundles.

MockAttesto celowo fail-closed wobec prawdziwych trust roots: verification z production witness key musi odrzucić mock evidence. Dzięki temu testy są szybkie, ale synthetic evidence nie może przejść jako production proof.

Pakiety companion i powierzchnie edge

Core SDKs pozostają małe. Osobne pakiety pokrywają edge relay, MCP tooling, workflow nodes i przyszły independent witness node. Te pakiety nigdy nie mogą stać się ukrytymi zależnościami transitive core SDKs.

PowierzchniaPackageUzycieRegula statusu
Serwer MCPattesto-mcpUdostepnia deterministyczne narzedzia Attesto hostom MCP.Instalowac tylko z PyPI release evidence.
Local Vaultattesto-local-vaultSzyfrowany customer-edge spool, relay i opcjonalny witness mode.Klucze zostaja lokalnie; bez uzycia frontend.
Node n8nn8n-nodes-attestoWorkflow receipts i weryfikacja signed webhook.Credentials zostaja w n8n credentials.
Independent witness nodeattesto-witness, @attesto/witness, go.attesto.eu/witnessPrivacy-preserving obserwacja publicznych albo jawnie udostepnionych heads.Phase-gated; nie jest core SDK dependency.
pip install attesto-mcp
pipx install attesto-local-vault
npm install n8n-nodes-attesto

Określony jako privacy-preserving observation node package. Obecne customer-operated witness behavior jest dostępne przez Local Vault witness mode; standalone attesto-witness, @attesto/witness i go.attesto.eu/witness powinny być instalowane tylko po tym, jak release evidence oznaczy ten package jako zielony.

Security rules