SDKs

SDKs Python, TypeScript, CLI et Go

Attesto expose quatre developer surfaces first-class: Python, TypeScript, Go et l'Attesto CLI. Elles partagent le même protocole Proofstream, les mêmes golden vectors, la verifier matrix, la production origin et les règles de gestion des secrets.

Support Article 13 et preuve Article 12 avec une seule ligne d'intégration

Pour les systèmes AI high-risk, l'Article 12 concerne la capacité technique de journalisation et la traçabilité, tandis que l'Article 13 concerne la transparence et les informations utiles pour les deployers et les utilisateurs. En termes Attesto, la ligne d'intégration exacte est export OPENAI_BASE_URL=http://localhost:8765/v1 : elle dirige les appels OpenAI-compatible vers l'Attesto Gateway afin que la capture automatique de preuve puisse démarrer. Le rapport Article 12 déterministe explique ce qui a été enregistré et vérifiable indépendamment, et la même trace receipt-backed peut soutenir la documentation Article 13. C'est un support de preuve, pas une déclaration de conformité juridique.

La ligne d'intégration gateway concrète qui rend cela possible est :

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

En production, remplacez localhost par l'hôte gateway déployé et gardez la provider key ainsi que la system key Attesto dans un secret storage server-side.

Utilisez ce modèle lorsque vous contrôlez une frontière de fonction Python. Le décorateur enregistre des commitments sur les arguments, la valeur de retour, le timing, la source reference et les failures; le rapport résume la couverture sans 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_..."))

Le chemin de capture utilise une system API key; le chemin de rapport lit les tenant stream events et nécessite donc un tenant/operator bearer token.

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

Ce que le SDK prend en charge

Les SDKs sont volontairement des clients server-side fins. Ils ne cachent pas le modèle de preuve, mais retirent le transport répétitif afin que votre application puisse se concentrer sur le bon event shape et sur la vérification de l'evidence retournée.

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

Utilisez attestedFetch lorsqu’un SDK ou framework OpenAI-compatible accepte une custom fetch implementation. Il enregistre uniquement des commitments, jamais les raw prompts ni completions. strict: true échoue fermé lorsque la preuve ne peut pas être envoyée; le mode fail-open doit être surveillé.

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,
});

Client Proofstream v2

Utilisez AttestoV2Client lorsque vous avez besoin de stream-level receipts, checkpoint consistency, witness policy visibility, verifier bundles et 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

Utilisez Go pour l'infrastructure automation, le security tooling, les cloud workers et les verifier services. Le SDK Go utilise actuellement uniquement la Go standard library et se résout depuis le module public go.attesto.eu/sdk.

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

L'Attesto CLI est la surface opérateur et verifier pour les workflows scriptés. Elle prend en charge JSON output, local config, stream/event actions, receipt verification, bundle verification, fork evidence, quorum evidence, connectors, Local Vault et release-readiness evidence checks. Elle n'affiche jamais les API keys stockées, tenant tokens ou connector secrets.

Installez la CLI signée depuis get.attesto.eu. Les installers vérifient la checksum SHA256 de la release avant toute installation, et la signature du manifest peut être vérifiée avec cosign. La formula Homebrew et les packages Linux natifs réempaquettent les mêmes binaires du canal : leurs hashes proviennent du manifest SHA256SUMS signé par cosign, jamais d'un build séparé :

# 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

Les packages arm64/aarch64 sont vérifiés au niveau des métadonnées contre le manifest signé, mais n'ont pas été exécutés sur du matériel arm.

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

Endpoints opérateur

Les endpoints tenant/operator exigent le mode bearer-token. Utilisez cela uniquement dans une operator automation fiable et jamais dans des clients publics.

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) }

Helpers verify offline et online

Les méthodes de vérification SDK sont utiles dans les services qui reçoivent des receipts ou bundles Attesto et doivent fail-closed avant de les accepter.

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

Vérification de provenance (Attesto 3)

Les SDKs 0.5.0 ajoutent un client de vérification pour la provenance lane Attesto 3 : des provenance streams commitment-only alimentés par un Local Vault contrôlé par le client. Le Rust edge core épinglé du vault construit capsules, commitments et signatures; le SDK les re-dérive et les vérifie, et ne peut délibérément construire ni capsule ni randomizer. Chaque fonction de cette section s'exécute hors ligne, sans appel vers Attesto, et chaque rapport porte une liste not_claimed qu'un écran de vérification doit afficher à côté du résultat. Protocoles : ATTESTO-PROVENANCE-001, ATTESTO-DISCLOSURE-001, ATTESTO-ZK-RANGE-001 et la bundle provenance binding de ATTESTO-PROOFSTREAM-001. La conformité est épinglée par le corpus de golden vectors partagé dans les trois langages.

Vérifier une disclosure presentation hors ligne

Le Local Vault d'un détenteur émet une selective-disclosure presentation : les leaves révélées avec leurs randomizers, des two-hop inclusion proofs jusqu'à la capsule root, et une signature Ed25519 de l'installation émettrice. Le vérificateur ouvre chaque commitment révélé et rejoue chaque proof jusqu'à la capsule_root présentée. Les problèmes sont collectés, pas levés, pour que l'appelant voie tout ce qui ne va pas. Passez le nonce que vous avez émis pour le mode challenge; sans lui, la presentation n'est bornée que par son expires_at et le rapport indique bounded_lifetime plutôt que de suggérer une fraîcheur qu'il n'a pas vérifiée. Non-claim : la disclosure prouve que les leaves révélées sont dans la capsule; elle n'affirme pas que la capsule ne contient rien d'autre.

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

Vérifier hors ligne une bundle provenance inclusion et une key revocation

Un verifier bundle sur un provenance stream porte provenance_root, provenance_event_count et vault_key_lifecycle dans son payload haché. Un inclusion object, renvoyé par GET /v2/streams/{streamId}/provenance-events/{sourceRef}/bundle-inclusion?from_checkpoint_id=...&to_checkpoint_id=... ou transporté comme provenance_inclusions à côté du bundle, prouve une capsule root sous cette root. Le vérificateur recalcule le bundle hash, re-hache la leaf à partir de ses champs, rejoue le proof, prend le receipt time du seq_no de la leaf dans les receipts du bundle lui-même, et applique la règle de révocation gelée à l'installation que la leaf nomme. inclusion et key_status restent séparés : une capsule root peut être prouvée sous le bundle alors que sa clé a été révoquée avant réception, et not_evaluated n'est jamais un succès. La révocation est évaluée contre le platform receipt time, jamais contre le occurred_at revendiqué par le vault, avec une borne inclusive; une revendication antérieure à la révocation reçoit le drapeau suspect_backdated. Non-claims : la root prouve que la capsule root existait sous le bundle et rien sur le contenu de la capsule; le key lifecycle est celui du moment de construction du bundle, une révocation ultérieure n'y figure donc pas.

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()

Dériver l'effective assurance (L3 est dérivé, jamais signé)

Un vault signe L0 (clé logicielle), L1 (clé dans un token PKCS#11 non extractible) ou L2 (L1 plus un quote TPM 2.0 sur la mesure du vault) dans son envelope, et la plateforme refuse une envelope L1/L2 qu'elle ne peut pas étayer par une attestation enregistrée. L3 n'a aucune représentation sur le fil : le vérificateur le dérive de L2 plus un witness quorum atteint sur le checkpoint englobant, et une envelope qui revendique L3 est refusée. L'état de l'anchor est rapporté à côté et ne promeut jamais un niveau. Le rapport garde la vault assurance, le witness quorum, l'état de l'anchor et le niveau dérivé comme quatre faits distincts. La façon dont les niveaux sont acquis est décrite dans le guide 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

Vérifier l'ouverture exacte d'un private numeric

Un private numeric claim engage sa valeur encodée sous forme de Pedersen commitment sur ristretto255. Lorsqu'un détenteur révèle la valeur et le blinding, le vérificateur recalcule le commitment et le compare octet par octet. L'arithmétique de courbe est optionnelle parce que le reste de la vérification est du travail SHA-256 et Merkle : Python a besoin de attesto[zk], TypeScript de la peer dependency @noble/curves et Go du module séparé go.attesto.eu/sdk/zk. Un client qui en est dépourvu rapporte not_checked. Le descriptor doit déjà avoir ouvert sa claim leaf sous la capsule root, sinon une paire concordante peut être fabriquée de toutes pièces. Une valeur exactement nulle est une ouverture valide. Ceci ne vérifie pas un 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)

Inspecter un ZK range result

La selective disclosure v2 prouve que la mesure d'un détecteur nommé se situait dans un intervalle sans la révéler. Aucun SDK ne vérifie le range proof lui-même; cela reste le travail du Rust core. Le SDK rapporte zk_predicate: not_checked sous verified_here, conserve ce que l'émetteur a revendiqué sous reported_by_issuer, et refuse un résultat qui omet l'un des trois non-claims obligatoires ou porte un champ en forme de verdict tel que authentic, score ou probability. Une borne prouvée ne dit rien sur le fait que le contenu soit généré par une machine. L'evidence de capsule d'un provider AttestoMark Image, Audio ou Video est un objet ATTESTO-PROVIDER-RESULT-001/0.2 dont le champ presented_matches_record indique si les octets présentés étaient exactement l'asset marqué; une divergence est une observation qu'un transcodage honnête produit aussi, jamais un refus.

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)

Absent des SDKs : la construction de capsule, la génération de randomizer et la signature d'envelope vivent dans l'edge core du Local Vault; les range proofs ne sont vérifiés que par le Rust core; il n'y a pas encore de client wrapper pour POST /v2/provenance/streams; et la CLI attesto ne vérifie ni disclosures ni bundle provenance en 0.5.0.

MockAttesto pour les tests locaux

attesto.testing.MockAttesto est un Python test harness pour CI locale et tests d'intégration. Il utilise les mêmes canonical hashing et receipt shapes que le SDK, mais signe avec une per-instance throwaway mock key et marque les objets comme mock evidence. Utilisez-le pour tester votre application flow sans accès réseau ni compte Attesto; n'utilisez jamais de mock receipts dans production evidence ou customer bundles.

MockAttesto est volontairement fail-closed contre les vrais trust roots: la vérification avec une production witness key doit rejeter mock evidence. Les tests restent rapides sans créer de chemin où synthetic evidence passerait pour production proof.

Packages compagnons et surfaces edge

Les core SDKs restent petits. Des packages séparés couvrent edge relay, MCP tooling, workflow nodes et le futur independent witness node. Ces packages ne doivent jamais devenir des dépendances transitives cachées des core SDKs.

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

Spécifié comme privacy-preserving observation node package. Le comportement customer-operated witness actuel est disponible via Local Vault witness mode; les packages standalone attesto-witness, @attesto/witness et go.attesto.eu/witness ne doivent être installés qu’après que la release evidence marque ce package vert.

Règles de sécurité

• Utilisez les SDKs uniquement depuis du code server-side.
• Stockez les system keys dans votre secret manager et injectez-les at runtime.
• Ne placez pas de system keys dans les frontend bundles, mobile apps, query strings ou logs.
• Utilisez la production origin par défaut sauf si votre tenant dispose d'une private deployment origin.
• Gardez l'idempotency activée pour chaque write path.