Intramedial befindet sich in der eingeschränkten Beta. Bei der Registrierung oder Anmeldung müssen Sie das erhaltene Beta-Tester-Passwort angeben oder unter preview@intramedial.com eines anfordern. Vielen Dank.
Wird geladen…
Trust Center
Prüfbar
Prüfbares Vertrauen, nicht nur Worte.
Intramedial entscheidet, was Agenten tun dürfen, und führt das Protokoll. Diese Seite legt dar, wie das funktioniert, was wo festgelegt ist und was wir noch nicht veröffentlicht haben. Sie beansprucht keine Zertifizierung. Jede Aussage verlinkt auf das Dokument oder die Quelle dahinter.
Agenten handeln, wenn die Ebene Ja sagt – und das Protokoll sagt, warum.
Leiten Sie Agent-Aktionen, Inhalts-Hashes, API-Checks, DNS-Abfragen, Webhooks, LLM-Aufrufe und Git-Commits über Intramedial – für einen signierten Beleg, den jeder prüft, ohne uns zu vertrauen.
Jeder Aufruf nimmt denselben Weg. Zugangsdaten prüft die Eingangstür, die Arbeit läuft und wird in der Region des Workspace gespeichert, die Signatur kommt aus einem HSM, das seinen Schlüssel nie herausgibt.
Zugang prüfen
Die Eingangstür ordnet den Zugang einem Workspace zu, bevor Tool-Code läuft. Secrets werden als SHA-256-Hashes gespeichert und in konstanter Zeit verglichen.
Weitergabe
Workspace und Rechte gehen in Headern an den Regionaldienst, signiert von unseren eigenen Diensten. Ohne gültige Signatur lehnt der Dienst die Anfrage ab.
Beobachten/Erfassen
Für Relay- und Monitor-Tools stellt der Regionaldienst die Anfrage über den Ausgangsfilter, sonst erfasst er Ihre Angaben. Bodies werden gehasht, nicht gespeichert.
Siegeln
Der Umschlag wird nach RFC 8785 kanonisiert und in AWS KMS mit dem Ed25519-Key der Region signiert. Fehlt der Key, lehnt der Dienst ab, statt mit einem anderen zu signieren.
Überall prüfen
Der Beleg trägt seine Key-ID in den signierten Bytes. Wer Beleg und öffentlichen Schlüssel hat, prüft ohne uns, solange der Schlüssel publiziert bleibt.
02
Beweisumfang
Was ein Beleg beweist, und was er nicht beweist.
Ein Beleg ist eine präzise, enge Aussage. Lesen Sie beide Spalten, bevor Sie sich darauf stützen oder andere darum bitten.
Gültige Signatur beweist
Herkunft: Der Inhaber eines Bundle-Signaturschlüssels hat genau diese Bytes signiert.
Integrität: Nichts im Umschlag hat sich seither geändert, keine Ziffer.
Ein versiegelter Bereich: Die Merkle-Root verpflichtet auf die darin enthaltenen Datensätze.
Er beweist nicht
Dass eine von Ihnen gemeldete Tatsache stimmt. Manche Tools signieren Angaben des Aufrufers, andere, was wir beobachten; die Seite jedes Tools sagt, welches.
Wer den Inhalt verfasst oder freigegeben hat. Der Beleg nennt einen Workspace, keine Person.
Die wahre Zeit eines Ereignisses. Es gibt keinen externen Zeitstempeldienst.
Dass nichts geschah, wo kein Beleg existiert.
Dass wir über unser Wort hinaus neutral sind. Ein öffentliches Log bezeugt die stündlichen Stapel-Roots der Beleg-Hashes, aber niemand außerhalb prüft den Inhalt eines Belegs. Dieser öffentliche Eintrag ist standardmäßig aktiv; Inhaber und Admins eines Workspace können ihn für Belege abschalten, die noch in keinem Stapel sind.
Wofür Sie uns weiter vertrauen
Prüfung ist unabhängig. Vertrauen nur noch für eine kurze, benannte Liste.
Vertrauen in
Warum
Falls falsch
Der öffentliche Prüfschlüssel stammt von uns
Eine Signatur zeigt, wer einen Key hält, nicht wem er gehört.
Ein untergeschobener Key macht Fälschungen gültig. Key-ID separat fixieren.
Unsere Signaturschlüssel nutzt allein der Belegdienst
Der Dienst signiert, was sein Code signieren will.
Ein missbrauchter Key könnte nie Geschehenes signieren.
Ehrliche Beobachtung bei den beobachtenden Tools
Ledger-Zeilen sagen: Die Ebene hat das gesehen.
Eine kompromittierte Ebene könnte eine falsche Ledger-Zeile schreiben.
Sieben Ed25519-Schlüssel, einer pro Signatur-Rechtsraum, teilen sich alle Workspaces. Die öffentlichen Hälften sind offen publiziert, die privaten entstehen in und bleiben bei AWS Key Management Service.
Verwahrung
Schlüssel entstehen in Hardware-Sicherheitsmodulen von AWS KMS, laut AWS nach FIPS 140-3 Level 3 validiert.
Der Belegdienst sendet kanonische Bytes an KMS und erhält eine Signatur. Sein Zugang darf nur signieren und keinen Schlüssel exportieren.
Keine API-Route liefert privates Schlüsselmaterial; öffentliche nur öffentliche Felder.
Ohne Key für eine Region antwortet der Dienst 503 signing_unprovisioned, ohne erreichbares KMS 503 signer_unavailable. Nie weicht er auf einen anderen Key aus oder gibt unsignierte Belege aus.
Rotation ist eine manuelle Zeremonie ohne Zeitplan. Ausgemusterte Keys bleiben publiziert, alte Belege also prüfbar.
Es gibt heute keine Sperrliste und kein Key-Transparency-Log. Eine Kompromittierung würden wir per Mitteilung und Änderung der publizierten Keys bekanntgeben.
HSM-Verwahrung verhindert das Kopieren eines Keys. Sie verhindert nicht, dass wer den Dienst deployen kann, ihn signieren lässt – daher trennen wir beobachtete und gemeldete Fakten.
Das JWK-Set selbst, eine Stunde cachebar, offen für jeden Origin
/api/v1/ledger-bundles/anchors
Jeder publizierte Key mit Aktiv-Flag
/api/v1/ledger-bundles/snapshot
Ein öffentlicher Key per ID
Key-Set laden und Key-ID nachrechnen
curl -sSL https://ledger-bundles.api.intramedial.com/.well-known/ledger-bundles-keys.json -o keys.json
jq -r '.keys[] | [.kid, .jurisdiction] | @tsv' keys.json
// kid = erste 16 Bytes des SHA-256 des Roh-Keys, base64url
Am sichersten: Laden Sie den Key einmal, legen Sie kid und x im eigenen Repository ab und prüfen Sie gegen diese Kopie. /docs/ledger-bundles-snapshot
04
Isolation
Zugriffskontrolle und Isolation
Jede Anfrage trägt einen Zugang, den das Gateway einem Workspace zuordnet, bevor ein Tool läuft. So behandeln wir heute Zugangsdaten, Mandanten und ausgehende Anfragen.
01
Gehashte Zugänge
API-Keys, persönliche Zugriffstoken und Session-Token liegen als SHA-256-Hashes vor, einmal angezeigt, in konstanter Zeit verglichen. Keys laufen nach 30 Tagen, 90 Tagen, einem Jahr oder nie ab und rotieren mit 0 bis 60 Minuten Karenz.
02
Anmeldung und Sessions
Die Anmeldung läuft über Avonao ID. Sitzungsdauer, Inaktivitäts-Timeout und Cookie-Einstellungen sind hier noch nicht veröffentlicht und werden daher nicht genannt. Planen Sie mit nichts über das hinaus, was die Anmeldeseite zeigt.
03
Scopes und Rollen
Scopes für Lesen, Schreiben und Verwalten, auf Wunsch auf benannte Tools eingeengt. Belege brauchen das Recht tools.attest; die Auditor-Rolle kann keine ausstellen. Prüfungen schlagen sicher fehl.
04
Mandanten
Das Gateway, nicht der Aufrufer, bestimmt den Workspace. Jedes Lesen und Schreiben trägt die Workspace-ID; ein Body mit anderem Workspace wird abgelehnt. Die Trennung ist logisch, in einer Regional-DB.
05
Ausgehende Anfragen
Ziele auf localhost, interne Namen und private oder reservierte Bereiche werden abgelehnt, bei Eingabe und vor jeder geplanten Prüfung. Redirects folgen wir nie; Zeit und Größe sind begrenzt.
06
Rate-Limits, Missbrauch
600 Anfragen pro Minute je IP und 1.200 je Konto am Gateway. Die Erkennung bei agent.call markiert Scan- oder Credential-Stuffing-Muster zur Prüfung durch einen Menschen; sie sperrt nie selbst.
Benannte Grenzen: Der Ausgangsfilter liest die URL als Text und löst keine Hostnamen auf; die zweite Ebene ist, dass der Dienst im Cloudflare-Netz läuft, das keine Route in private Adressräume hat. IP-Allowlists öffnen sich, wenn sie unlesbar sind, damit ein DB-Fehler Kunden nicht aussperrt.
05
Datensparsam
Schutz der Daten
Der Dienst soll so wenig wie möglich halten. Zur Attestierung erhält er einen Hash, nie das Dokument; bei weitergeleiteten Aufrufen hasht er die Bodies und behält sie nicht.
Erst hashen
Sie berechnen einen SHA-256 und senden ihn. Dokument, Prompt oder Antworttext erhalten wir nie.
Relay ohne Speicherung
Weitergeleitete Bodies und Header laufen durch, gehasht. Antwort-Bodies speichern wir nur bei aktiver Aufbewahrung.
Append-only-Belege
DB-Trigger lehnen Änderungen ab, und von jedem Beleg liegt zusätzlich ein Hash in einem Write-once-Speicher (S3 Object Lock), solange die Frist Ihres Tarifs läuft. Nur auditierte Routen schwärzen oder löschen, jede mit Audit-Ereignis.
Lesbare Felder sind lesbar
URLs, Labels und Commit-Autoren stehen im Klartext im Beleg. Nichts eintragen, was der Leser nicht sehen soll.
Datenregionen
Belege, Überwachungen, Kontingentzähler, Relay-Verarbeitung und Signatur laufen in der beim Anlegen des Workspace gewählten Region. Dashboard, Website, Anmeldung, Abrechnung und Kontodaten kommen stets aus den USA (US West).
Region
Code
Signatur-Key in AWS KMS
Speicher
USA West
wnam
us-west.
Standorthinweis
Europa Mitte
weur
eu.
EU-Jurisdiktion (erzwungen)
Asia-Pacific
apac
asia.
Standorthinweis
Oceania
oc
oc.
Standorthinweis
Die Region legt fest, wo Daten gespeichert und verarbeitet werden. Ein Workspace zieht nie um; ist eine Region nicht erreichbar, scheitert der Aufruf, statt auszuweichen.
Verschlüsselt
Daten gehen per TLS zwischen Ihnen und dem Dienst und liegen bei unserem Infrastrukturanbieter Cloudflare, nach dessen Sicherheitsbedingungen. Belege sind signiert, also erkennt jeder Prüfer jede Änderung an gespeicherten Beweisen.
Löschen und Entfernen
Die Kontolöschung greift nach 30 Tagen Karenz, in denen Sie exportieren und wiederherstellen können. Belege entfernt der Löschjob nicht; sie laufen mit dem Tariffenster ab, Sie löschen sie, oder Sie bitten uns. Ein schon weitergegebener Beleg bleibt für den Empfänger prüfbar, was immer wir tun.
Aufbewahrung
Belege
Das Tariffenster: Free 7 Tage, Starter 30, Pro 90, Pro+ 180, Team 365, Scale 730, Enterprise individuell.
Konto- und Anmeldedaten
Bis zur Löschung des Kontos, danach Entfernung nach 30 Tagen Karenzzeit.
Betriebs-Logs und Zähler für Rate-Limits
Höchstens 30 Tage.
Sicherheits-Audit-Log
So lange der Workspace besteht und danach; die Person wird ersetzt, wo Löschung Pflicht ist.
Abrechnungsdaten
Solange Steuerrecht es fordert, bis 7 Jahre.
Idempotenz-Replay-Cache
24 Stunden, mit Status und Beleg-ID, niemals mit dem Body.
Status wird gemessen, nicht von Hand gepflegt. Service-Levels sind für Enterprise Vertragsinhalt; Prüfen geht auch, wenn wir ausfallen.
Öffentlicher Status
Minütlich geprüft: das API-Gateway in jeder der sieben Datenregionen, der MCP-Server, die OAuth-Discovery, die veröffentlichten Signaturschlüssel, das did:web-Dokument des Signierers und die Prüfung von Belegen. Die Ausstellung von Belegen (ein Testbeleg, mit dem Produktionsschlüssel signiert und gespeichert) kommt hinzu, sobald ihr eigener Prüf-Workspace eingerichtet ist; bis dahin wird sie nicht gemessen.
Ein Check, der scheitert oder über 8 Sekunden braucht, gilt als down; über 3 Sekunden als beeinträchtigt. Ein veralteter Monitor zeigt keine Daten, nie Grün.
Vorfälle erscheinen mit Updates, per E-Mail-Abo, als Atom-Feed und als JSON.
Die Statusseite ist nicht signiert und kein Service-Level-Agreement.
Für Enterprise-Tarife mit signiertem Bestellformular legt das Enterprise-SLA die Bedingungen fest. Der Support ist in den Geschäftszeiten besetzt und bestätigt Enterprise-Anfragen je nach Schweregrad binnen 1 Geschäftsstunde, 4 Geschäftsstunden oder 1 Geschäftstag. Self-Serve-Tarife enthalten weder Uptime-Zusage noch Service-Gutschriften; ihre Support-Reaktionsziele stehen auf der Preisseite.
Abgedeckter Dienst nicht verfügbar oder keine Belege ausstellbar, im Produktivbetrieb.
1 Geschäftsstunde
Schweregrad 2
Wichtige Funktion gestört oder beeinträchtigt, mit Workaround.
4 Geschäftsstunden
Schweregrad 3
Kleineres Problem, Frage oder Anliegen.
1 Geschäftstag
Liegt die Verfügbarkeit drei Monate in Folge oder in vier von zwölf Monaten unter 99,0 %, kann der Kunde die Bestellung mit anteiliger Erstattung kündigen.
Zum Prüfen eines Belegs genügen Beleg und öffentlicher Schlüssel. Das klappt auch, wenn unser Dienst ausfällt.
07
Offenlegung
Incident Response und Offenlegung von Lücken
Wozu wir uns verpflichten, wenn etwas schiefgeht, und wie Sie uns eine Schwachstelle melden, bevor andere sie finden.
72h
Datenschutzverletzungen
Wir informieren den Kontoinhaber per E-Mail unverzüglich und jedenfalls binnen 72 Stunden, nachdem uns eine Verletzung personenbezogener Kundendaten bekannt wird, mit dem bekannten Stand: Art, betroffene Personen und Datensätze, wahrscheinliche Folgen und ergriffene Maßnahmen. Die Mitteilung wird ergänzt, sobald wir mehr erfahren.
Störungen erscheinen auf der Statusseite mit Verlauf von Investigating bis Resolved. Bei einem Vorfall mit Schweregrad 1 erhalten Enterprise-Kunden eine Erstmeldung und Updates, wenn sich die Lage ändert.
Melden Sie über das Formular, mit Kontaktdaten oder anonym, oder per E-Mail. Forschung in gutem Glauben nach der Richtlinie ist erlaubt, und wir gehen deshalb nicht gegen Sie vor.
Schritt
Ziel
Bestätigung Ihrer Meldung
Innerhalb von 3 Werktagen
Erstbewertung und Schweregrad
Innerhalb von 10 Werktagen
Updates, solange es offen ist
Mindestens alle 14 Tage
Fix für kritische und hohe Schwere
Angestrebt: 30 Tage
Fix für geringere Schwere
Angestrebt: 90 Tage
Ziele, keine Garantien. Wir bitten um 90 Tage vor einer Veröffentlichung. Kein Bug-Bounty mit Geld; auf Wunsch nennen wir Forschende namentlich.
Keine Geldprämien. Forschende werden auf Wunsch genannt.
09
Richtlinien
Rechtsdokumente
Jedes Dokument, das den Dienst regelt, mit Datum der aktuellen Fassung. Wesentliche Änderungen an AGB, Datenschutzerklärung, AVV und Nutzungsrichtlinie kündigen wir Kontoinhabern mindestens 30 Tage vorher an.
Wie der EU AI Act auf Intramedial und seine Evidence Packs anwendbar ist, wie das Dokument es darlegt. Packs ordnen Kontrollen zu und bescheinigen nie.
Für Verbraucher in der EU und im Vereinigten Königreich: Widerruf eines kostenpflichtigen Tarifs binnen 14 Tagen, was Sie zurückerhalten, und das Muster-Widerrufsformular.
Sie prüfen einen Anbieter? Sagen Sie uns, was Sie brauchen. Wir beantworten Fragebögen schriftlich und sagen klar, wenn etwas noch nicht veröffentlicht ist.