Identity-Aware Agent Messaging Platform — kryptografisch nachvollziehbare Kommunikation zwischen Menschen, KI-Agenten und SAP
Find a file
CTO (Paperclip) ba1b88d490
Some checks failed
build-images / signing-service image (push) Failing after 16s
validate / JSON Schema (ajv) (push) Successful in 19s
validate / Go (vet + test) (push) Failing after 4s
validate / Rego (opa fmt + opa test) (push) Successful in 13s
validate / DB (migrate up/down dry-run) (push) Failing after 21s
testagent-transform: Phase-1 trust-chain demo agent (DEV-610)
Minimal CLI agent process that end-to-end demonstrates the Transform step
of the ProofedMesh trust chain:

  1. Fetches an approval attestation from the transparency-log by
     attestation_ref (`sha256:<hex>`).
  2. DSSE-verifies the fetched envelope against a pinned approval-signer
     ed25519 keyring; stops before any signing call on failure.
  3. Builds an in-toto v1 Statement with predicateType
     `basicstack.de/attestations/transform/v1`, operation
     `expense.map_to_sink`, materials[0].attestation_ref = approval_ref,
     and subject[0].digest.sha256 = sha256(canonical(handover_payload)).
  4. Calls signing-service /api/v1/sign/dsse with BOTH identities:
     Authorization: Bearer <pocket-id client_credentials token> AND
     X-Workload-Token: <projected SA token from
     /var/run/secrets/tokens/trust-api>.
  5. Submits the returned DSSE envelope + content_hash to the
     transparency-log /api/v1/log/entries.
  6. POSTs the canonical handover_payload bytes to the dummy-sink
     (schema sink.dummy.v1), carrying the transform content_hash on the
     X-Attestation-Ref header.

Tests use httptest for all four backends:

  - Happy path (verifies the bytes sent to the sink match the signed
    subject digest and that the TLog recorded the same content_hash the
    agent returned).
  - Invalid approval signature -> stops before sign-call; TLog and sink
    untouched.
  - Signing-service returns 403 signing_denied -> surfaced as
    signer.ErrSigningDenied; TLog and sink untouched.
  - Missing Pocket-ID token -> fails before any network call.

Includes PocketID client_credentials TokenSource (OIDC discovery + cache)
and ProjectedSATokenSource (reads kubelet-managed Volume) mirroring
admin-api/approval-service.

Non-scope: no read-side attestations (Phase 2), no K8s/CI image build
wiring (follow-up ticket).

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-25 19:55:02 +00:00
.forgejo/workflows ci: install docker-cli explicitly on debian trixie (DEV-607) 2026-10-25 19:27:24 +00:00
db approval-service: Phase-1 content-binding approval service (DEV-608) 2026-10-25 19:42:06 +00:00
deploy signing-service: Pocket-ID JWKS + K8s TokenReview + OPA (DEV-609) 2026-10-25 19:42:40 +00:00
docs attest+tlog: ADR-0005 Signing/TLog API contract, HTTP clients + orchestrator in admin-api (go vet clean, 11 new tests pass) 2026-10-25 17:51:33 +00:00
policies signing-service: Pocket-ID JWKS + K8s TokenReview + OPA (DEV-609) 2026-10-25 19:42:40 +00:00
schemas schemas: add ds/receipts v1.0.0, ds/per_diem v1.0.0, expense.canonical v1.2.0, sink.db.expense v1.2.0 (+ examples) 2026-10-25 17:07:20 +00:00
services testagent-transform: Phase-1 trust-chain demo agent (DEV-610) 2026-10-25 19:55:02 +00:00
README.md signing-service: Dockerfile, K8s manifests (agent-trust), image CI, secret convention 2026-10-25 18:19:51 +00:00

ProofedMesh

Identity-Aware Agent Messaging Platform — eine Plattform für kryptografisch nachvollziehbare Kommunikation zwischen Menschen, KI-Agenten und beliebigen Prozess-Senken (ERP, eigene Datenbankapplikationen, HTTP-Webhooks, Message-Queues, Dateiablage).

Vision

Benutzerfreigaben, delegierte Berechtigungen und sämtliche Verarbeitungsschritte zwischen Menschen, Agenten und Zielsystemen werden kryptografisch nachvollziehbar.

Der Benutzer autorisiert den ursprünglichen Geschäftsinhalt. Jeder Agent attestiert anschließend seine eigene Verarbeitung. Die empfangende Senke überprüft die vollständige Kette, bevor sie eine Aktion ausführt.

Identität, Berechtigung, Verarbeitung und Nachrichtentransport werden strikt getrennt. Der Trust-Core ist senken-agnostisch.

Status

Dieses Repository bildet die Basis für die Architekturentwicklung. Die Komponentenentwicklung hat noch nicht begonnen.

  • Aktive Architektur: docs/architecture/v1.1.md — V1.1 inkl. Senken-Generalisierung (SAP ist eine von vielen Senken), Pocket ID als alleiniger IdP, PII-Trennung, Trillian für Transparency Log, Content Binding mit WebAuthn, Replay-Schutz, Retention 1 Jahr
  • Historisch: docs/architecture/v1.0.md — ursprünglicher Entwurf, archiviert

Architekturprinzipien

  1. Unveränderliche Benutzerfreigabe — ein vertrauenswürdiger Dienst bestätigt den konkret autorisierten Geschäftsinhalt (per WebAuthn Content Binding).
  2. Eigene Identität jedes Agenten — jeder Agent besitzt eine separate kryptografische Identität.
  3. Verkettete Attestierungen — jeder Verarbeitungsschritt referenziert exakte Eingabe- und Ausgabe-Hashes.
  4. Unabhängige Autorisierung — eine Signatur allein erteilt keine Berechtigung; OPA kontrolliert erlaubte Transformationen und Senken-Aktionen.
  5. Transportneutralität — Nachweise funktionieren über HTTP, NATS oder Matrix, ohne dass die Vertrauenskette verloren geht.
  6. Senken-Neutralität — der Trust-Core kennt keine konkrete Senken-Semantik; Senken-Adapter sind Plug-ins mit festem Vertrag.

Zielkernstack (V1.1)

Bereich Technologie
Identität Pocket ID (Menschen und Agent-Clients)
Workload-ID Kubernetes projected ServiceAccount Token + TokenReview
Signaturen Ed25519 / DSSE, OpenBao Transit
Provenienz in-toto v1 (basicstack.de/attestations/*/*)
Autorisierung OPA + Approval Service
Transparency Trillian + PostgreSQL
Transport HTTPS/mTLS + NATS JetStream; Matrix optional für Mensch-Chat
Agenten Paperclip
Senken Plug-in-Architektur: SAP S/4HANA (ABAP), eigene DB-Apps (Go-Adapter), HTTP-Webhooks, Message-Queues, Dateiablage
Evidence PostgreSQL + S3 (Retention 1 Jahr)
PII Separater verschlüsselter S3-Bucket, redaktionierbar

Repository-Layout

docs/
  architecture/
    v1.0.md       # Ursprünglicher Entwurf (archiviert)
    v1.1.md       # Aktive Architektur
  adr/
    README.md     # ADR-Index
    0000-template.md
    0001-first-rollout-db-app-scope.md
    0002-session-scope-token-format.md
    0003-pii-retention-policy.md
    0004-db-migrations.md
db/
  README.md
  trust/migrations/0001_per_diem_rates.{up,down}.sql
schemas/
  README.md
  expense/canonical/{v1.0.0,v1.1.0,v1.2.0}.json
  ds/expense/project_assignment/v1.0.0.json
  ds/receipts/v1.0.0.json
  ds/per_diem/v1.0.0.json
  sink/db/expense/{v1.0.0,v1.1.0,v1.2.0}.json
policies/
  README.md
  transformations/{expense,per_diem}.rego (+ _test.rego)
  sinks/expense_db_app.rego (+ _test.rego)
  data_sources/{expense_db_app,receipts,per_diem_rates}.rego (+ _test.rego)
services/
  per-diem-calculator/   # deterministic calculator (Go)
  admin-api/             # admin surface for per-diem rate management (Go)
  attest-reconciler/     # periodic worker: re-signs per_diem_rates rows without rate_change_attestation_ref (Go)
  signing-service/       # DSSE signing service (Go, ADR-0005) + Dockerfile
  transparency-log/      # Trillian-backed transparency log (Go, ADR-0005)
deploy/
  trillian/              # Trillian MySQL + log server/signer (namespace agent-trust)
  signing-service/       # signing-service Deployment/Service/NetworkPolicy + Secret convention
.forgejo/workflows/
  validate.yml      # JSON-Schema (ajv) + Rego (opa fmt + opa test) + Go (vet + test)
  build-images.yml  # Container-Images für ProofedMesh-Services → harbor.basicstack.de

Weitere Verzeichnisse (weitere Services, Deployment-Manifeste, Senken-/Datenquellen-Adapter) folgen im Zuge der Architekturentwicklung.

Einstiegspunkte

  • Architektur V1.1 — Zielbild
  • ADRs — getroffene Entscheidungen
  • Schemas — kanonische Business-, Datenquellen- und Senken-Formate
  • Policies — OPA/Rego-Policies für Transformationen, Senken und Datenquellen

Lokal validieren

# JSON-Schemas
npx -y ajv-cli@5 compile --spec=draft2020 -c ajv-formats \
  -s schemas/expense/canonical/v1.0.0.json

# Rego
opa fmt --list --diff policies/
opa test policies/ -v

# Go services
(cd services/admin-api && go vet ./... && go test ./...)
(cd services/per-diem-calculator && go vet ./... && go test ./...)
(cd services/attest-reconciler && go vet ./... && go test ./...)

CI (.forgejo/workflows/validate.yml) läuft dieselben Prüfungen auf jedem Push und PR gegen main.