Attesto

Developer surfaces

Gateway, MCP, OTel und n8n

Die Kern-SDKs von Attesto decken direkte Applikationsintegration ab. Gateway, MCP, OpenTelemetry und n8n decken die Systeme um Applikationen herum ab: Modell-Proxying, Agent-Tools, Observability-Traces und Workflow-Automatisierung. Jede Oberfläche muss echte Proofstream-Evidence erzeugen, Source Timestamps respektieren und Secrets aus Payloads, Receipts, Bundles, Logs und Browsercode heraushalten.

Scope

Diese Seite richtet sich an Entwickler und technische Betreiber, die Attesto in AI-Gateways, Agent Hosts, Telemetry Pipelines und Automatisierungstools integrieren. Sie dokumentiert keine internen Staff-Operationen und ersetzt nicht die SDK-, API-, Connector- oder Local-Vault-Handbücher. Nutze sie, um die passende Oberfläche zu wählen und zu verstehen, welche Evidence jede Oberfläche erzeugt.

Wann welche Oberfläche genutzt wird

OberflächeNutzen, wennErzeugtPrimärer Owner
Inference GatewayOpenAI-kompatible Modellaufrufe erfasst werden sollen, ohne jede Applikation umzubauen.Request/Response Commitments, Policy Metadata, Model-Routing Evidence und Receipts.Platform- oder AI-Engineering-Team.
MCP serverAgent Hosts deterministische Tools für Events, Receipt-Verifikation oder Bundle-Erstellung benötigen.Tool-call Evidence, Stream Events und Receipt-Verifikationsergebnisse.Agent-Plattform oder Developer-Tooling-Team.
OpenTelemetry bridgeBereits Spans vorhanden sind und ausgewählte Traces in Attesto-Evidence umgewandelt werden sollen.Span Commitments, Trace/Span Source References und Service-Metadata Receipts.Observability- oder Platform-Team.
n8n nodeWorkflow-Automatisierung verifizierbare Step Receipts und Signed-Webhook-Verifikation braucht.Workflow-step Events, Source References, Receipt IDs und Verifikationsergebnisse.Automation- oder Operations-Team.

Inference Gateway

Das Attesto Inference Gateway ist ein serverseitiger Proxy für OpenAI-kompatible Modellaufrufe. Applikationen senden Requests an das Gateway; das Gateway leitet an den konfigurierten Upstream Provider weiter und schreibt Attesto-Evidence, bevor die Provider Response zurückgegeben wird. Nutze es, wenn Teams nicht in jeder Applikation SDK-Aufrufe ergänzen können oder zentrale Policy und Model Routing erforderlich sind. 

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

Der Attesto MCP server stellt MCP-kompatiblen Agent Hosts eine kleine Menge deterministischer Attesto Tools bereit. Die aktuelle Tool Surface ist log_action, get_receipt, verify_receipt, get_stream_head und verify_completeness. Der Server loggt Aktionen, ruft Receipts ab, verifiziert Receipts offline, prüft Stream Heads und beweist, dass ein Sequence Range gap-free ist, ohne dem Agent breite Backend Credentials zu geben. Der MCP server sollte serverseitig in der Agent Runtime laufen. Er enthält kein AI-Modell, keine AI-Vendor Imports und keine versteckte Entscheidungslogik; er ist ein deterministischer Tool Wrapper über dem 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

Die OpenTelemetry bridge wandelt ausgewählte Spans in Attesto Events um. Sie ist sinnvoll, wenn die Trace Pipeline bereits Source of Truth ist: Model-Gateway Spans, Policy-Evaluation Spans, Connector-Sync Spans oder Incident-Handling Spans. Die Bridge muss stark filtern; nicht jeder Span sollte standardmäßig gesendet werden. 

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

Der Attesto n8n node ist für Workflow-Automatisierung gedacht, die verifizierbare Step Evidence benötigt. Nutze ihn für Approval Workflows, Connector Handoffs, Incident Triage, Policy Checks und kundennahe Automatisierung, bei der ein Auditor später sehen muss, was wann passiert ist. 

npm install n8n-nodes-attesto

Evidence model

Alle vier Oberflächen sollten Evidence über dieselbe Proofstream-Semantik wie die SDKs erzeugen. Ein Gateway Request, MCP Tool Call, OTel Span oder n8n Workflow Step ist nichts Besonderes: Es ist ein Source Event mit Source Reference, Timestamp, normalized Commitment, Receipt und optionaler späterer Inclusion in Windows, Checkpoints, Witnesses und Anchors.

FeldErforderliches Verhalten
source_system_idGateway, Agent Host, Telemetry Service oder n8n Instance identifizieren.
source_refStabiler Idempotency Key wie Request ID, Tool Call ID, Trace/Span ID oder Workflow Execution ID.
source_timeOriginaler Source Timestamp mit Timezone oder Offset.
payload_commitmentNormalized Payload Metadata committen, ohne Provider Secrets zu speichern.
receiptReceipt ID zurückgeben oder speichern, damit das Event später verifiziert werden kann.

Security boundaries

Operations

Behandle diese Oberflächen als Production Integrations. Sie benötigen Health Checks, Retry Policy, Rate-Limit Handling, Idempotency, Source-Time-Validierung und beobachtbare Failure States. Eine Oberfläche kann aus einer Package Registry installiert sein, ist aber für einen Tenant erst production-ready, wenn sie einen echten Attesto API Key, einen echten Stream und eine erfolgreiche Receipt/Verify Canary hat.

CheckErwartetes Ergebnis
Install smokePackage installiert aus der offiziellen Registry ohne Source Maps oder Source Leaks.
Receipt canaryEin echtes Event wird geloggt und das Receipt verifiziert.
Retry canaryWiederholte source_ref liefert Replay/Idempotent-Verhalten, keine doppelte Historie.
Secret scanKein Tenant Key, Provider Key, Prompt Secret, Trace Secret oder Workflow Credential erscheint in Logs oder Bundles.

Failure modes

FailureBedeutungResponse
Attesto unavailableDie Oberfläche kann kein Receipt erhalten.Fail closed, wenn Policy Evidence verlangt; andernfalls Run als missing evidence markieren.
Provider unavailableDer Upstream Model/Tool/Workflow Service ist fehlgeschlagen.Sichere Failure Metadata loggen, wenn Policy es erlaubt; kein Success Event erfinden.
Invalid source timeDer Source Timestamp fehlt oder ist malformed.Reject oder Normalize gemäß Tenant Policy und Receive Time getrennt erfassen.
Secret detectedPayload oder Attribute scheint Secret Material zu enthalten.Emission blockieren, an der Quelle redigieren und rotieren, wenn Leakage bestätigt ist.

Rollout checklist