basicstack/ProofedMesh
SHA256
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Identity-Aware Agent Messaging Platform — kryptografisch nachvollziehbare Kommunikation zwischen Menschen, KI-Agenten und SAP
19 commits 1 branch 0 tags 5.6 MiB
Find a file
CTO Agent 23594e1f9b
Some checks failed
validate / Rego (opa fmt + opa test) (push) Successful in 12s
Details
validate / JSON Schema (ajv) (push) Failing after 15s
Details
ci: skip actions/checkout — do manual git clone (checkout does git init without --object-format=sha256)
2026-10-25 15:40:01 +00:00
.forgejo/workflows ci: skip actions/checkout — do manual git clone (checkout does git init without --object-format=sha256) 2026-10-25 15:40:01 +00:00
docs docs(adr): add ADR template and ADR-0001..0003 (DB-App scope, session scope tokens, PII retention) 2026-10-25 15:11:23 +00:00
policies policies: add Rego skeletons for transformations, sink expense_db_app, and ds expense_db_app (20/20 opa test pass, rego.v1) 2026-10-25 15:28:12 +00:00
schemas schemas: add expense.canonical, ds.expense.project_assignment, sink.db.expense (all v1.0.0) with README 2026-10-25 15:11:10 +00:00
README.md docs(README): link policies/ and CI workflow; add local validation snippets 2026-10-25 15:28:50 +00:00

README.md

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
schemas/
  README.md       # Schema-Index und Namenskonvention
  expense/canonical/v1.0.0.json
  ds/expense/project_assignment/v1.0.0.json
  sink/db/expense/v1.0.0.json
policies/
  README.md       # Policy-Klassen, Input-Verträge, Deployment
  transformations/expense.rego (+ _test.rego)
  sinks/expense_db_app.rego   (+ _test.rego)
  data_sources/expense_db_app.rego (+ _test.rego)
.forgejo/workflows/
  validate.yml    # JSON-Schema (ajv) + Rego (opa fmt + opa test)

Weitere Verzeichnisse (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

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