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.
| Obszar | Zachowanie SDK | Odpowiedzialność developera |
|---|---|---|
| Base URL | Domyślnie https://verify.attesto.eu. | Nadpisuj tylko dla private/staging deployments. |
| Authentication | Obsługuje system API-key mode i tenant bearer-token mode. | Użyj najwęższej credential potrzebnej do zadania. |
| Idempotency | Tworzy 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. |
| Retries | Retry dla przejściowych błędów 429, 5xx i transport errors z backoff. | Nie zmieniaj payloads między retries. |
| Proofstream helpers | Udostępnia helpers dla stream, receipt, checkpoint, anchor, IVC, bundle i verify. | Świadomie wybierz stream granularity i policy IDs. |
| Errors | Zwraca typed auth, validation, rate-limit i server errors. | Loguj bezpieczne error categories, nie API keys ani raw secret-bearing payloads. |
Capability matrix
| Capability | Python | TypeScript | Go | CLI |
|---|---|---|---|---|
| Streams/events/receipts | Tak | Tak | Tak | Tak |
| Windows/checkpoints/consistency | Tak | Tak | Tak | Tak |
| Remote verifier API | Tak | Tak | Tak | Tak |
| Offline receipt verification | Verifier helper/API | Verifier helper/API | Tak | Tak |
| Witness policy and fork evidence | Tak | Tak | Tak | Tak |
| Anchors and IVC epochs | Tak | Tak | Tak | Tak |
| Connectors | Tak | Tak | Tak | Tak |
| Local Vault relay/witness | Tak | Tak | Tak | Tak |
| Weryfikacja pochodzenia (Attesto 3): disclosure, bundle provenance, key revocation, effective assurance, ZK range result | Tak (offline) | Tak (offline) | Tak (offline) | Nie |
| Dokładne otwarcie private numeric (Pedersen) | extra attesto[zk] | peer @noble/curves | moduł go.attesto.eu/sdk/zk | Nie |
| Release readiness evidence | Via scripts | Via scripts | Via CLI/module tests | Tak |
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 group | Subcommands | Użycie |
|---|---|---|
version, config, login, logout | config get, config set | Sprawdź wersję i zarządzaj lokalną redacted configuration. |
streams | create, get, head | Twórz streams, inspect tenant-visible stream metadata i pobieraj append-only head. |
events | log, batch | Wyślij jeden event albo JSON event batch z source timestamps i payload files. |
receipts | get, verify | Pobierz stored receipt i zweryfikuj lokalnie albo przez /v2/verify/receipt. |
windows, checkpoints, anchors, ivc | get, verify, checkpoints consistency, ivc epochs get/verify | Pobieraj i weryfikuj Proofstream windows, checkpoint roots, consistency proofs, anchor epochs i IVC epochs. |
witnesses, quorum, fork-evidence | policies, status, receipts, inspect, verify | Inspect witness policy, proof state, quorum material i fork evidence. |
bundles, verify | build, get, verify, offline-verify, verify file, verify truth-package | Buduj verifier bundles i weryfikuj bundles, portable receipt files albo Truth Package ZIPs. |
connector, connectors | connector init, connectors create, ingest, revoke, verify | Scaffold connector manifests, zarządzaj tenant connectors, ingest events i weryfikuj signed connector payloads. |
local-vault | install, relay, spool, status, witness, fork-evidence, revoke | Obsługuj Local Vault installations, encrypted spool workflows, witness receipts, fork evidence i revocation. |
marketplace | init, validate, submit | Przygotuj publisher manifests, waliduj je lokalnie i submit assets do prywatnej review Attesto. |
doctor, report, readiness | report article12, readiness lifecycle/fork-defense/quorum/assurance/connectors/local-vault/nova/production | Uruchamiaj 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.
| Weryfikator | Python (attesto.provenance) | TypeScript (@attesto/sdk) | Go (go.attesto.eu/sdk) |
|---|---|---|---|
| Disclosure presentation | verify_disclosure | verifyDisclosure | VerifyDisclosure |
| Bundle provenance inclusion + key revocation | verify_bundle_provenance, evaluate_key_revocation | verifyBundleProvenance, evaluateKeyRevocation | VerifyBundleProvenance, EvaluateKeyRevocation |
| Effective assurance | effective_assurance | effectiveAssurance | EffectiveAssurance |
| Dokładne otwarcie private numeric | verify_pedersen_opening (attesto[zk]) | verifyPedersenOpening (@noble/curves peer) | zk.VerifyOpening (go.attesto.eu/sdk/zk) |
| ZK range result | inspect_predicate_result, validate_range_statement | inspectPredicateResult, validateRangeStatement | InspectPredicateResult, 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.
| Powierzchnia | Package | Uzycie | Regula statusu |
|---|---|---|---|
| Serwer MCP | attesto-mcp | Udostepnia deterministyczne narzedzia Attesto hostom MCP. | Instalowac tylko z PyPI release evidence. |
| Local Vault | attesto-local-vault | Szyfrowany customer-edge spool, relay i opcjonalny witness mode. | Klucze zostaja lokalnie; bez uzycia frontend. |
| Node n8n | n8n-nodes-attesto | Workflow receipts i weryfikacja signed webhook. | Credentials zostaja w n8n credentials. |
| Independent witness node | attesto-witness, @attesto/witness, go.attesto.eu/witness | Privacy-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
- Używaj SDKs tylko z kodu server-side.
- Przechowuj system keys w swoim secret manager i wstrzykuj je at runtime.
- Nie umieszczaj system keys w frontend bundles, mobile apps, query strings ani logs.
- Używaj domyślnego production origin, chyba że twój tenant ma private deployment origin.
- Utrzymuj idempotency włączone dla każdego write path.
