SDKs

Python-, TypeScript-, CLI- und Go-SDKs

Attesto stellt vier first-class Developer Surfaces bereit: Python, TypeScript, Go und die Attesto CLI. Sie teilen dasselbe Proofstream Protocol, dieselben Golden Vectors, die Verifier Matrix, den Production Origin und die Regeln für Secret Handling.

Article 13 Support und Article 12 Evidence mit einer Integrationszeile

Für high-risk AI-Systeme geht es bei Article 12 um technische Logging-Fähigkeit und Traceability, während Article 13 Transparenz und nutzbare Informationen für Deployer und Nutzer betrifft. In Attesto-Begriffen lautet die exakte Integrationszeile export OPENAI_BASE_URL=http://localhost:8765/v1: damit werden OpenAI-compatible Calls an das Attesto Gateway gerichtet und automatische Evidence Capture kann starten. Der deterministische Article 12 Report erklärt, was aufgezeichnet und unabhängig verifizierbar ist, und derselbe receipt-backed Trail kann Article-13-Dokumentation unterstützen. Das ist Nachweisunterstützung, keine rechtliche Konformitätserklärung.

Die konkrete One-line Gateway-Integration, die das ermöglicht, ist:

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

Ersetzen Sie localhost in Produktion durch den bereitgestellten Gateway Host und speichern Sie sowohl Provider Key als auch Attesto System Key in serverseitiger Secret Storage.

Nutzen Sie dieses Muster, wenn Sie eine Python-Funktionsgrenze kontrollieren. Der Decorator erfasst Commitments über Argumente, Rückgabewert, Timing, Source Reference und Failures; der Report fasst Coverage ohne LLM zusammen.

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_..."))

Der Capture Path nutzt einen System API Key; der Report Path liest Tenant Stream Events und benötigt daher einen Tenant/operator Bearer Token.

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

Was die SDK übernimmt

Die SDKs sind bewusst schlanke server-side Clients. Sie verbergen das Evidence Model nicht, sondern entfernen repetitive Transportarbeit, damit Ihre Anwendung sich auf die richtige Event Shape und die Verifikation der zurückgegebenen Evidence konzentrieren kann.

Capability Matrix

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

Nutzen Sie attestedFetch, wenn ein OpenAI-compatible SDK oder Framework eine custom fetch implementation akzeptiert. Es zeichnet nur Commitments auf, niemals raw prompts oder completions. strict: true schlägt geschlossen fehl, wenn Evidence nicht gesendet werden kann; Fail-open Mode muss überwacht werden.

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

Verwenden Sie AttestoV2Client, wenn Sie stream-level Receipts, Checkpoint Consistency, Witness Policy Visibility, Verifier Bundles und Offline Verification Helpers benötigen.

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

Verwenden Sie Go für Infrastructure Automation, Security Tooling, Cloud Workers und Verifier Services. Die Go SDK nutzt derzeit nur die Go Standard Library und wird über den öffentlichen go.attesto.eu/sdk Module Path aufgelöst.

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

Die Attesto CLI ist die Operator- und Verifier Surface für scripted Workflows. Sie unterstützt JSON Output, Local Config, Stream/Event Actions, Receipt Verification, Bundle Verification, Fork Evidence, Quorum Evidence, Connectors, Local Vault und Release-readiness Evidence Checks. Sie gibt niemals gespeicherte API Keys, Tenant Tokens oder Connector Secrets aus.

Installieren Sie die signierte CLI über get.attesto.eu. Die Installer prüfen die SHA256-Checksum des Release, bevor irgendetwas installiert wird, und die Signatur des Manifests lässt sich mit cosign verifizieren. Die Homebrew-Formula und die nativen Linux-Pakete verpacken dieselben Kanal-Binaries neu: ihre Hashes stammen aus dem cosign-signierten SHA256SUMS-Manifest, nie aus einem separaten Build:

# 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

arm64/aarch64-Pakete sind gegen das signierte Manifest metadata-verifiziert, wurden aber nicht auf Arm-Hardware ausgeführt.

CLI command reference

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 erfordern Bearer-token Mode. Verwenden Sie das nur in trusted Operator Automation und niemals in öffentlichen 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 und Online Verify Helpers

SDK Verification Methods sind nützlich in Services, die Attesto Receipts oder Bundles empfangen und fail-closed arbeiten müssen, bevor sie diese akzeptieren.

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("; "));
}

Provenance-Verifikation (Attesto 3)

Die 0.5.0-SDKs bringen einen Verifikationsclient für die Attesto 3 Provenance Lane: Commitment-only Provenance Streams, die von einem kundenkontrollierten Local Vault gespeist werden. Der gepinnte Rust Edge Core des Vaults baut Capsules, Commitments und Signaturen; das SDK leitet sie erneut ab und prüft sie, und kann bewusst weder eine Capsule noch einen Randomizer konstruieren. Jede Funktion in diesem Abschnitt läuft offline, ohne Aufruf an Attesto, und jeder Report trägt eine not_claimed-Liste, die eine Verifier-Oberfläche neben dem Ergebnis anzeigen muss. Protokolle: ATTESTO-PROVENANCE-001, ATTESTO-DISCLOSURE-001, ATTESTO-ZK-RANGE-001 und die Bundle Provenance Binding von ATTESTO-PROOFSTREAM-001. Die Konformität wird durch das gemeinsame Golden-Vector-Korpus in allen drei Sprachen festgepinnt.

Eine Disclosure Presentation offline verifizieren

Der Local Vault eines Inhabers stellt eine Selective-Disclosure Presentation aus: die offengelegten Leaves mit ihren Randomizern, Two-Hop Inclusion Proofs bis zur Capsule Root und eine Ed25519-Signatur der ausstellenden Installation. Der Verifier öffnet jedes offengelegte Commitment und spielt jeden Proof bis zur präsentierten capsule_root nach. Probleme werden gesammelt statt geworfen, damit der Aufrufer alles sieht, was nicht stimmt. Übergeben Sie die von Ihnen ausgegebene Nonce für den Challenge-Modus; ohne sie ist die Presentation nur durch ihr expires_at begrenzt und der Report meldet bounded_lifetime, statt eine Frische zu suggerieren, die nicht geprüft wurde. Non-Claim: die Disclosure beweist, dass die offengelegten Leaves in der Capsule liegen; sie ist keine Aussage darüber, dass die Capsule nichts anderes enthält.

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

Bundle Provenance Inclusion und Key Revocation offline verifizieren

Ein Verifier Bundle über einen Provenance Stream trägt provenance_root, provenance_event_count und vault_key_lifecycle in seinem gehashten Payload. Ein Inclusion Object, geliefert von GET /v2/streams/{streamId}/provenance-events/{sourceRef}/bundle-inclusion?from_checkpoint_id=...&to_checkpoint_id=... oder als provenance_inclusions neben dem Bundle mitgeführt, beweist eine Capsule Root unter dieser Root. Der Verifier berechnet den Bundle Hash neu, hasht das Leaf aus seinen Feldern erneut, spielt den Proof nach, nimmt die Receipt Time für das seq_no des Leafs aus den eigenen Receipts des Bundles und wendet die eingefrorene Revocation-Regel auf die Installation an, die das Leaf nennt. inclusion und key_status bleiben getrennt: eine Capsule Root kann nachweislich unter dem Bundle liegen, während ihr Schlüssel vor dem Empfang widerrufen wurde, und not_evaluated ist niemals ein Bestehen. Revocation wird gegen die Platform Receipt Time bewertet, nie gegen das vom Vault behauptete occurred_at, mit inklusiver Grenze; ein Claim, der vor dem Widerruf liegt, wird mit suspect_backdated markiert. Non-Claims: die Root beweist, dass die Capsule Root unter dem Bundle existierte, und nichts über den Inhalt der Capsule; der Key Lifecycle gilt zum Zeitpunkt des Bundle-Baus, ein späterer Widerruf ist also nicht im 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()

Effective Assurance ableiten (L3 wird abgeleitet, nie signiert)

Ein Vault signiert L0 (Software-Schlüssel), L1 (Schlüssel in einem nicht extrahierbaren PKCS#11-Token) oder L2 (L1 plus ein TPM-2.0-Quote über die Messung des Vaults) in seinem Envelope, und die Plattform lehnt einen L1/L2-Envelope ab, den sie nicht durch eine registrierte Attestation belegen kann. L3 hat keine Darstellung auf der Leitung: der Verifier leitet es aus L2 plus einem erreichten Witness Quorum auf dem umgebenden Checkpoint ab, und ein Envelope, der L3 behauptet, wird abgelehnt. Der Anchor-Status wird daneben berichtet und hebt nie eine Stufe an. Der Report hält Vault Assurance, Witness Quorum, Anchor-Status und die abgeleitete Stufe als vier getrennte Fakten. Wie die Stufen verdient werden, beschreibt der Local-Vault-Leitfaden.

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

Ein exaktes Private-Numeric Opening verifizieren

Ein Private Numeric Claim bindet seinen kodierten Wert als Pedersen Commitment über ristretto255. Legt ein Inhaber Wert und Blinding offen, berechnet der Verifier das Commitment neu und vergleicht Byte für Byte. Kurvenarithmetik ist optional, weil der Rest der Verifikation SHA-256- und Merkle-Arbeit ist: Python braucht attesto[zk], TypeScript die Peer Dependency @noble/curves und Go das separate Modul go.attesto.eu/sdk/zk. Ein Client ohne sie meldet not_checked. Der Descriptor muss sein Claim Leaf bereits unter der Capsule Root geöffnet haben, sonst kann ein passendes Paar vollständig gefälscht werden. Ein Wert von genau null ist ein gültiges Opening. Dies verifiziert keinen 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)

Ein ZK Range Result prüfen

Selective Disclosure v2 beweist, dass die Messung eines benannten Detektors in ein Intervall fiel, ohne sie offenzulegen. Kein SDK verifiziert den Range Proof selbst; das bleibt Aufgabe des Rust Core. Das SDK meldet zk_predicate: not_checked unter verified_here, behält die Behauptung des Ausstellers unter reported_by_issuer und lehnt ein Ergebnis ab, das einen der drei verpflichtenden Non-Claims weglässt oder ein urteilsförmiges Feld wie authentic, score oder probability trägt. Eine bewiesene Schranke sagt nichts darüber, ob der Inhalt maschinell erzeugt wurde. Capsule Evidence eines AttestoMark-Image-, -Audio- oder -Video-Providers ist ein ATTESTO-PROVIDER-RESULT-001/0.2-Objekt, dessen Feld presented_matches_record meldet, ob die präsentierten Bytes genau das markierte Asset waren; ein Mismatch ist eine Beobachtung, die auch ein ehrliches Transcoding erzeugt, nie eine Ablehnung.

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)

Nicht in den SDKs: Capsule-Konstruktion, Randomizer-Erzeugung und Envelope-Signatur liegen im Edge Core des Local Vault; Range Proofs verifiziert nur der Rust Core; es gibt noch keinen Client Wrapper für POST /v2/provenance/streams; und die attesto CLI verifiziert in 0.5.0 weder Disclosures noch Bundle Provenance.

MockAttesto für lokale Tests

attesto.testing.MockAttesto ist ein Python Test Harness für lokale CI und Integrationstests. Es verwendet dieselben canonical hashing und receipt shapes wie das SDK, signiert aber mit einem per-instance throwaway mock key und markiert Objekte als mock evidence. Verwenden Sie es, um Ihren Application Flow ohne Netzwerk oder Attesto Account zu testen; verwenden Sie mock receipts niemals in production evidence oder customer bundles.

MockAttesto ist bewusst fail-closed gegenüber echten trust roots: Verification mit einem production witness key muss mock evidence ablehnen. So bleiben Tests schnell, ohne dass synthetic evidence als production proof durchgehen kann.

Companion Packages und Edge-Oberflächen

Die Core SDKs bleiben klein. Separate Packages decken Edge Relay, MCP Tooling, Workflow Nodes und den zukünftigen independent witness node ab. Diese Packages dürfen niemals versteckte transitive Dependencies der Core SDKs werden.

pip install attesto-mcp
pipx install attesto-local-vault
npm install n8n-nodes-attesto

Spezifiziert als privacy-preserving observation node package. Aktuelles customer-operated witness Verhalten ist über Local Vault witness mode verfügbar; standalone attesto-witness, @attesto/witness und go.attesto.eu/witness sollten nur installiert werden, nachdem Release Evidence dieses Package grün markiert.

Security Rules

• Verwenden Sie SDKs nur aus server-side Code.
• Speichern Sie System Keys in Ihrem Secret Manager und injizieren Sie sie at runtime.
• Legen Sie System Keys nicht in Frontend Bundles, Mobile Apps, Query Strings oder Logs ab.
• Verwenden Sie den Standard Production Origin, außer Ihr Tenant hat einen Private Deployment Origin.
• Lassen Sie Idempotency für jeden Write Path aktiviert.