Attesto

Developer surfaces

Gateway, MCP, OTel i n8n

Główne SDK Attesto obejmują bezpośrednią integrację aplikacji. Gateway, MCP, OpenTelemetry i n8n obejmują systemy wokół aplikacji: proxy dla modeli, narzędzia agentów, trace observability i automatyzację workflow. Każda powierzchnia musi emitować realne Proofstream evidence, respektować source timestamps i trzymać secrets poza payloads, receipts, bundles, logami oraz kodem przeglądarkowym.

Scope

Ta strona jest dla developerów i technicznych operatorów, którzy integrują Attesto z AI gateways, agent hosts, telemetry pipelines i narzędziami automatyzacji. Nie dokumentuje wewnętrznych operacji staff i nie zastępuje podręczników SDK, API, connectors ani Local Vault. Użyj jej, aby dobrać właściwą powierzchnię i zrozumieć, jaką evidence tworzy każda z nich.

Kiedy użyć której powierzchni

PowierzchniaUżyj, gdyTworzyGłówny właściciel
Inference GatewayChcesz przechwytywać wywołania modeli zgodne z OpenAI bez zmiany każdej aplikacji.Request/response commitments, policy metadata, model routing evidence i receipts.Zespół platformowy lub AI engineering.
MCP serverAgent hosts potrzebują deterministycznych tools do logowania events, weryfikacji receipts lub budowania bundles.Tool-call evidence, stream events i wyniki weryfikacji receipts.Zespół agent platform lub developer tooling.
OpenTelemetry bridgeEmitujesz już spans i chcesz zamienić wybrane traces na Attesto evidence.Span commitments, trace/span source references i service metadata receipts.Zespół observability lub platformy.
n8n nodeAutomatyzacja workflow potrzebuje weryfikowalnych step receipts i weryfikacji podpisanych webhooków.Workflow-step events, source references, receipt IDs i wyniki weryfikacji.Zespół automation lub operations.

Inference Gateway

Attesto Inference Gateway to server-side proxy dla wywołań modeli zgodnych z OpenAI. Aplikacje wysyłają requests do gateway; gateway przekazuje je do skonfigurowanego upstream provider i zapisuje Attesto evidence przed zwróceniem odpowiedzi providera. Użyj go, gdy zespoły nie mogą dodać SDK calls do każdej aplikacji albo gdy potrzebna jest centralna polityka i model routing. 

export ATTESTO_API_KEY="$ATTESTO_SYSTEM_KEY"
export OPENAI_BASE_URL=http://127.0.0.1:8765/v1

attesto-gateway --listen 127.0.0.1:8765 \
  --admin-listen 127.0.0.1:8766 \
  --attesto-base-url https://verify.attesto.eu \
  --upstream https://api.openai.com/v1 \
  --stream-id "$ATTESTO_STREAM_ID" \
  --capture commitments
curl -sS "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer ${PROVIDER_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4.1-mini","messages":[{"role":"user","content":"Summarize this policy"}]}'

MCP server

Attesto MCP server udostępnia MCP-compatible agent hosts wąski zestaw deterministycznych narzędzi Attesto. Aktualna tool surface to log_action, get_receipt, verify_receipt, get_stream_head i verify_completeness. Serwer loguje actions, pobiera receipts, weryfikuje receipts offline, sprawdza stream heads i dowodzi, że sequence range jest gap-free bez przekazywania agentowi szerokich backend credentials. MCP server powinien działać server-side w środowisku runtime agenta. Nie zawiera modelu AI, importów AI vendor ani ukrytej logiki decyzyjnej; to deterministyczny wrapper narzędziowy nad Attesto SDK. 

pip install attesto-mcp
{
  "mcpServers": {
    "attesto": {
      "command": "attesto-mcp",
      "args": ["--stdio"],
      "env": {
        "ATTESTO_BASE_URL": "https://verify.attesto.eu",
        "ATTESTO_API_KEY": "${ATTESTO_API_KEY}",
        "ATTESTO_STREAM_ID": "${ATTESTO_STREAM_ID}"
      }
    }
  }
}
attesto-mcp --stdio

OpenTelemetry bridge

OpenTelemetry bridge zamienia wybrane spans na Attesto events. Jest przydatny, gdy źródłem prawdy jest już trace pipeline: spans model gateway, policy evaluation, connector sync albo incident handling. Bridge musi filtrować agresywnie; nie wysyłaj domyślnie każdego span. 

pip install attesto opentelemetry-sdk
import os
from attesto import AttestoClient
from attesto.otel import AttestoSpanProcessor
from opentelemetry.sdk.trace import TracerProvider

provider = TracerProvider()
provider.add_span_processor(
    AttestoSpanProcessor(
        client=AttestoClient(api_key=os.environ["ATTESTO_API_KEY"]),
        stream_id=os.environ["ATTESTO_STREAM_ID"],
    )
)

n8n node

Attesto n8n node jest dla automatyzacji workflow, która potrzebuje weryfikowalnego step evidence. Użyj go dla approval workflows, connector handoffs, incident triage, policy checks i automatyzacji dla klientów, gdzie auditor musi później zobaczyć, co i kiedy się stało. 

npm install n8n-nodes-attesto

Evidence model

Wszystkie cztery powierzchnie powinny emitować evidence zgodnie z tą samą semantyką Proofstream co SDKs. Gateway request, MCP tool call, OTel span lub n8n workflow step nie są wyjątkowe: to source event z source reference, timestamp, normalized commitment, receipt i opcjonalną późniejszą inclusion w windows, checkpoints, witnesses i anchors.

PoleWymagane zachowanie
source_system_idIdentyfikuje gateway, agent host, telemetry service lub instancję n8n.
source_refStabilny idempotency key, taki jak request id, tool call id, trace/span id lub workflow execution id.
source_timeOryginalny source timestamp z timezone lub offset.
payload_commitmentCommituje normalized payload metadata bez przechowywania provider secrets.
receiptZwraca lub zapisuje receipt id, aby event można było później zweryfikować.

Security boundaries

Operations

Traktuj te powierzchnie jako integracje produkcyjne. Potrzebują health checks, retry policy, rate-limit handling, idempotency, walidacji source-time i obserwowalnych failure states. Powierzchnia może być zainstalowana z package registry, ale nie jest production-ready dla tenanta, dopóki nie ma realnego Attesto API key, realnego stream i udanego receipt/verify canary.

CheckOczekiwany wynik
Install smokePackage instaluje się z oficjalnego registry bez source maps lub source leaks.
Receipt canaryJedno realne event zostaje zalogowane, a receipt przechodzi weryfikację.
Retry canaryPowtórzone source_ref daje replay/idempotent behavior, nie zduplikowaną historię.
Secret scanŻaden tenant key, provider key, prompt secret, trace secret ani workflow credential nie pojawia się w logach lub bundles.

Failure modes

FailureZnaczenieReakcja
Attesto unavailablePowierzchnia nie może uzyskać receipt.Fail closed, gdy polityka wymaga evidence; w innym wypadku oznacz run jako missing evidence.
Provider unavailableUpstream model/tool/workflow service zawiódł.Zaloguj bezpieczne failure metadata, jeśli polityka pozwala; nie twórz fikcyjnego success event.
Invalid source timeSource timestamp jest brakujący lub malformed.Reject albo normalize według tenant policy i zapisz receive time oddzielnie.
Secret detectedPayload lub attribute wydaje się zawierać secret material.Zablokuj emission, zredaguj u źródła i zrotuj, jeśli wyciek jest potwierdzony.

Rollout checklist