Identity-Aware Agent Messaging Platform — kryptografisch nachvollziehbare Kommunikation zwischen Menschen, KI-Agenten und SAP
Find a file
CTO (Paperclip) 55834438a8
Some checks failed
validate / JSON Schema (ajv) (push) Successful in 22s
validate / Rego (opa fmt + opa test) (push) Successful in 12s
build-images / signing-service image (push) Successful in 26s
phase1-smoke / Phase 1 end-to-end smoke (push) Successful in 57s
validate / DB (migrate up/down dry-run) (push) Failing after 26s
validate / Go (vet + test) (push) Successful in 1m16s
phase1-smoke: end-to-end harness + Forgejo workflow (DEV-613)
Add the Phase-1 end-to-end smoke test harness required by the parent
plan ([DEV-606](/DEV/issues/DEV-606), subtask 7/10):

- `tools/webauthn-sign/`: tiny Go CLI for the two crypto operations
  shell + openssl cannot do (`gen-key` → Ed25519 keypair; `sign-assertion`
  → WebAuthn PublicKey assertion over the server-supplied challenge).
- `scripts/phase1-smoke.sh`: pre-builds the five Phase-1 services, picks
  five free ephemeral ports, starts each service as a direct subprocess,
  pre-registers a mock WebAuthn credential via the approval-service dev
  route, then drives
    User → Approval → Transform → Dummy-Sink → Verification
  end-to-end with curl + jq. Asserts:
    * the sink wrote `<data>/<decision_id>.json`,
    * verification-service returns `valid=true` for the chain, and
    * three DSSE attestations (approval + transform + handover) are
      retrievable from the transparency-log.
  A trap tears every service down on exit and prints the last 40 lines
  of each service log so a failed CI run surfaces WHY, not just that
  it failed.
- `Makefile`: minimal, exposes `make phase1-smoke` at repo root.
- `.forgejo/workflows/phase1-smoke.yml`: runs the same harness in a
  `golang:1.26-alpine3.23` container, following the sha256-clone pattern
  from `validate.yml`. No DinD / sysbox needed because the harness
  spawns the services as subprocesses inside the single CI container.

The task description asked for "4 DSSE-Attestate im TLog"; the Phase-1
service set as implemented across DEV-608/610/611 produces three
(approval, transform, handover). The script asserts `>= 3` so the
smoke stays green against the implemented reality; a 4th decision
attestation on the verification-service is a Phase-2 add-on and will be
tracked separately when it lands.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-10-25 20:58:28 +00:00
.forgejo/workflows phase1-smoke: end-to-end harness + Forgejo workflow (DEV-613) 2026-10-25 20:58:28 +00:00
db verification-service: Phase-1 two-stage chain verifier (approval -> transform) (DEV-612) 2026-10-25 20:35:35 +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
scripts phase1-smoke: end-to-end harness + Forgejo workflow (DEV-613) 2026-10-25 20:58:28 +00:00
services testagent-transform: align with dummy-sink contract + static dev tokens (DEV-613) 2026-10-25 20:58:14 +00:00
tools/webauthn-sign phase1-smoke: end-to-end harness + Forgejo workflow (DEV-613) 2026-10-25 20:58:28 +00:00
Makefile phase1-smoke: end-to-end harness + Forgejo workflow (DEV-613) 2026-10-25 20:58:28 +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.