Ein Vertrauensprotokoll für
die Autorisierung der exakten Wirkung.
SecureStamp erweitert digitales Vertrauen von Ursprung und Absicht bis zur Ausführung. Genehmigte Entscheidungen werden zu begrenzten Ausführungsbefugnissen, eingeschränkt durch eine vom Kunden kontrollierte Richtlinie und gefolgt von unabhängig überprüfbarem Nachweis.
Gmail, Outlook und Apple Mail, mit Herkunftsnachweis im Posteingang
Offizielle Kanäle
WhatsApp, Telegram und der Perimeter, den eine Marke deklariert
Agenten und APIs
MCP-Tools, APIs und autonome Workflows
Protokollarchitektur
Vertrauen vor dem Handeln. Nachweis nach der Ausführung.
Ein Vertrauens-Stack, angewendet auf jede Oberfläche.
SecureStamp ist kein E-Mail-Prüfer mit angeschraubter Agenten-Funktion. Ursprung, Absicht, Ausführungsautorisierung und Ausführungsnachweis sind vier Schichten einer Kette — und diese Kette läuft gleich, ob die Anweisung im Posteingang, in einem Messenger oder über einen MCP-Tool-Aufruf ankommt.
SecureStamp erweitert Vertrauen von der Anweisung bis zur Konsequenz.
Vertrauens-Stack
Ursprung
Woher kam das? Domains, Header, Signaturen, deklarierte Identität und Kanalperimeter. Unterstützender Nachweis — notwendig, und nie die Schlagzeile.
Absicht
Was wird verlangt? Die angeforderte Aktion wird gelesen und zuerst benannt: zahlen, genehmigen, Zugangsdaten herausgeben, ein Tool aufrufen. Ein Eingangssignal, kein Beweis.
Execution Authorization
Welche exakte Wirkung darf verursacht werden? Eine genehmigte Entscheidung wird zu einer begrenzten Einmal-Befugnis für eine kanonische Operation unter expliziten Einschränkungen.
Ausführungsnachweis
Welche Autorisierung wurde verbraucht, und welches Ergebnis konnte der Ausführungspunkt feststellen? Eine signierte Quittung, die jeder offline prüfen kann.
Angewendet auf
Gmail · Outlook · Apple Mail
Offizielle Kanäle
WhatsApp · Telegram · deklarierte Perimeter
Agenten
MCP-Clients und Copiloten
APIs
Direkte Integrationen
Workflows
Automatisierungen und delegierte Dienste
Execution Authorization gilt überall dort, wo Befugnis an Software delegiert wird, nicht nur an KI-Agenten. Eine Automatisierung, ein Workflow oder ein delegierter Dienst, der im Namen eines anderen handelt, wirft dieselbe Frage auf: welche exakte Wirkung wurde genehmigt?
Protokoll-These
Der neue Perimeter ist die Aktion.
Zuerst haben wir Geräte gegen Malware und Trojaner verteidigt. Dann Posteingänge gegen Phishing. Jetzt handelt Software in unserem Namen, und die Frage ist nicht mehr nur, was sie erreichen darf — sondern was sie verändern darf.
Nachrichten, Ereignisse und Prompts können APIs, Tool-Aufrufe, Workflows und digitale Geldoperationen auslösen. SecureStamp schlägt überprüfbare Signale vor, bevor eine Kommunikation zur Aktion wird.
Identität steuert, wer auf ein System zugreifen kann. SecureStamp begrenzt die exakte Wirkung, die autonome Software verursachen darf.
Vier Schichten
Authentifizierung stellt Identität fest. Zugriffskontrolle begrenzt die Reichweite. Execution Authorization begrenzt die Wirkung.
Authentifizierung
Wer oder was handelt?
Zugriffsautorisierung
Welche Ressourcen darf es erreichen?
Execution Authorization
Welche exakte Wirkung darf es verursachen?
Ausführungsnachweis
Welche Autorisierung wurde verbraucht, und welches Ergebnis konnte der Ausführungspunkt feststellen?
Die vierte Frage ist bewusst so formuliert. Ein Ergebnis, das nicht festgestellt werden kann, bleibt unbestimmt, und keine Schicht dieses Stacks tut so, als wäre es anders.
Wo wir sitzen
SecureStamp beginnt dort, wo die Entscheidung endet.
Identitäts-, Richtlinien- und Freigabesysteme entscheiden, ob eine Aktion fortfahren soll. SecureStamp bindet diese genehmigte Entscheidung an die exakte Wirkung, die ausgeführt werden darf.
Entscheiden
Was soll erlaubt sein? Das beantworten Identität, Policy Engines, Freigaben und Menschen.
Autorisieren
Welche exakte Wirkung ist zulässig? Das ist die Schicht, die SecureStamp hinzufügt.
Ausführen
Diese Wirkung innerhalb der Kundenbeschränkungen anwenden, an einem Punkt, den der Kunde kontrolliert.
Verifizieren
Welche Autorisierung wurde verbraucht, und welches Ergebnis konnte der Ausführungspunkt feststellen?
SecureStamp ersetzt weder Identität noch Policy Engines, Freigabe-Workflows oder Provider-APIs. Es bindet deren genehmigte Entscheidungen an exakte ausführbare Wirkungen.
SecureStamp liefert überprüfbare Signale und begrenzte Autorisierungen. Es ersetzt weder interne Richtlinien, Berechtigungen, Sandboxing, menschliche Freigabe noch bestehende Sicherheitskontrollen.
Geräte
Der erste moderne Perimeter war das Gerät: Malware, Trojaner, gefährliche Dateien und lokales Verhalten.
Posteingänge
Dann wanderte das Risiko zu den Nachrichten: ähnlich aussehende Domains, gefälschte Links, Anhänge, Zahlungsdruck und Identitätsvortäuschung.
Aktionen
Heute kann eine Anweisung Werkzeuge öffnen, APIs aufrufen, Rechnungen verarbeiten, Daten bewegen oder Zahlungen vorbereiten.
Trust checks
SecureStamp liest, was eine Nachricht verlangt – zahlen, freigeben, Zugangsdaten herausgeben, ein Werkzeug aufrufen – und untermauert das mit Nachweisen zu Herkunft, Kanal und Kontext, bevor geantwortet, gezahlt, Daten geteilt oder ein Workflow ausgeführt wird.
Kanalagnostisch
Ein kanalagnostischer Standard
SecureStamp ist nicht für einen Posteingang, eine App oder eine Branche gebaut. Das Protokoll ordnet Signale um Ursprung, Kanal, deklarierte Absicht und Aktion. Es lässt sich auf E-Mail, Messaging, QR, Websites, Rechnungen, Tickets, APIs, Agenten und digitale Geldoperationen anwenden.
Delegierte Befugnis
Überall dort, wo Befugnis an Software delegiert wird.
Ein Agent, eine Automatisierung, ein Workflow oder ein delegierter Dienst, der im Namen eines anderen handelt — sie alle werfen dieselbe Frage auf. Die Zugriffsberechtigung sagt, was sie erreichen können; sie definiert nicht die exakte Wirkung, die für diese Transaktion genehmigt wurde.
MCP für Agenten
SecureStamp MCP Server
MCP ist der Weg, über den KI-Anwendungen Werkzeuge, Daten und Workflows erreichen. SecureStamp steht vor dieser Reichweite: Software fragt, worum eine Anweisung tatsächlich bittet, wer die Gegenpartei ist und welche exakte Wirkung sie verursachen darf — bevor irgendetwas läuft.
SecureStamp autorisiert; es hält niemals deine nachgelagerten Provider-Credentials. Wenn eine Operation wirklich ausgeführt werden muss, wandert der signierte Grant zu einem Execution Guardian, den du betreibst, und nur dieser Daemon berührt den Provider.
read_message_request(...)analyze_message_intent(...)verify_counterparty(...)get_safe_next_step(...)authorize_action(...)create_action_challenge(...)issue_action_receipt(...)get_source_envelope(...)request_execution_grant(...)get_execution_status(...)Konzeptioneller Ablauf
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF ordnet zuerst die verlangte Aktion, dann Inhalts-, Herkunfts-, Authentifizierungs-, Kanal- und Kontextsignale, und erzeugt eine einfache, prüfbare Ausgabe für Menschen, Systeme und Agenten.
Requested Action
Antworten, Öffnen, Zahlen, Überweisen, Genehmigen, Daten teilen, Werkzeuge aufrufen oder Workflows ausführen.
Content Signals
Dringlichkeit, Links, Anhänge, Zugangsdaten, Zahlungsanweisungen und Änderungen der Bankverbindung.
Origin Signals
Domain, Organisation, deklarierte Identität, Absender.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, Header, Signaturen, Schlüssel und Receipts.
Channel Signals
E-Mail, Web, WhatsApp, Telegram, QR, API, Support, Abrechnung und Tickets.
Verdict Layer
Trust, Signal und Action Verdict: eine lesbare, prüfbare Ausgabe, die zuerst die verlangte Aktion nennt und darunter die Herkunftsnachweise zeigt.
Drei Eingangssignale, dann Autorisierung
Proof of Origin beantwortet, woher eine Anweisung kam. Proof of Intent nennt, worum sie bittet. Action Verdict empfiehlt, ob sie fortfahren soll. Alle drei sind Signale, die in eine Entscheidung einfließen — und eine Entscheidung ist noch keine Autorisierung.
Proof of Intent
Was wird verlangt? Ein Eingangssignal, das die angeforderte Aktion zuerst benennt. Es ist kein Beweis dessen, was autorisiert wurde.
Proof of Origin
Woher kam es? Domain, Organisation, Kanal, Absender, Marke und technische Signale. Unterstützender Nachweis.
Action Verdict
Soll das fortfahren? Ein Entscheidungssignal. Was nach dieser Entscheidung passiert, ist Execution Authorization.
Ausführungsschicht
Public Beta · Produktivzugang kontrolliertEin Urteil ist kein Beweis.
Ein Verdict kann empfehlen, ob eine Aktion fortfahren soll. Es beweist für sich genommen nicht die exakte Wirkung, die autorisiert wurde, die Autorität dahinter, ob die Autorisierung wiederverwendet wurde, oder das bei der Ausführung beobachtete Ergebnis.
Action Proof erzeugt diese Beweiskette. Eine genehmigte Entscheidung wird zu begrenzter ausführbarer Autorität: eine exakte Wirkung, eine Autorität, ein Ablauf, eine Verwendung — offline überprüfbar, von jedem.
Zugriff ist keine Befugnis zu handeln
Zugriff steuert, was Software erreichen kann. Execution Authorization begrenzt die exakte Wirkung, die sie verursachen darf.
Ressourcenautorisierung beantwortet, worauf ein Principal zugreifen darf. Execution Authorization beantwortet, welche transaktionsspezifische Wirkung er verursachen darf. Fine-grained Zugriff lässt die Transaktion selbst weiterhin undefiniert: welche Ressource, welcher Betrag, welches Ziel, wie oft.
Autorisiere die Wirkung, nicht nur den Zugriff auf das Werkzeug.
Vom Kunden kontrollierte Obergrenze
Deine Richtlinie ist die Obergrenze.
SecureStamp Cloud kann eine Autorisierung enger machen. Sie kann sie nicht weiter machen als die Richtlinie, die deine Organisation signiert und lokal installiert hat. Cloud-Autorisierung ist notwendig, für sich allein aber nie hinreichend.
Effektive Berechtigung
effektive Berechtigung =
Cloud-Grant
∩ signierte lokale Richtlinie
∩ Adapter-Einschränkungen
∩ Kill Switches- Die lokale Richtlinie ist ein Dokument, das deine Organisation mit ihrem eigenen Schlüssel signiert und neben dem Guardian installiert. Sie fixiert Tenant, Gateway, Operationen, Adapter-Manifeste, akzeptierte Autoritäten und Richtlinienversionen, Ressourcen, Parameter, monetäre Limits, Nebenläufigkeit und Netzwerkziele.
- Sie ist deny-only per Konstruktion. Sie hat kein Feld, das etwas gewähren könnte, das die Cloud nicht gewährt hat.
- Der Start im Produktivmodus ohne gültige signierte lokale Richtlinie wird nicht gewarnt, sondern beim Start abgelehnt.
- Kill Switches existieren global sowie pro Provider, Operation, Tenant und Gateway — und noch einmal in der lokalen Richtlinie selbst. Sie stoppen bereits ausgestellte Grants.
- Richtlinien tragen ein verpflichtendes Überprüfungsdatum und ein optionales Ablaufdatum. Eine abgelaufene Richtlinie blockiert neue Mutationen und lässt Status, Beweis, Rücklesen und Abgleich unangetastet.
- Schlüsselwiederherstellung ist M-von-N und offline. Der SecureStamp-Support kann diese Kontrolle nicht ersetzen, und genau das ist der Punkt.
- Eine kompromittierte Cloud-Control-Plane kann die lokal erlaubte Autorität weiterhin nicht überschreiten.
Beim Kunden betrieben
Wir autorisieren. Sie führen aus.
Der Guardian läuft in deiner Umgebung und hält die Provider-Credentials. SecureStamp Cloud erhält keine Provider-Credentials und ruft deinen Provider nie auf.
- Provider-Credentials werden als root-eigene Dateien gemountet, nie als Umgebungsvariablen und nie als eingebettete Konfiguration.
- Die MCP-Bridge — der Prozess, der dem Modell am nächsten ist — benötigt weder Provider-Credentials noch Cloud-SDKs.
- Die Wirkung wird aus dem Zustand aufgelöst, den der Daemon selbst liest, nie aus Parametern, die das Modell geliefert hat.
- Der Vorzustand wird unmittelbar vor der Mutation erneut gelesen; eine wesentliche Änderung macht den Grant ungültig, statt ihn zu überschreiben.
Beweiskette
Fünf Glieder, jedes von einer anderen Partei signiert
Kryptografischer Beweis der Autorisierung. Signierte Evidenz des Ausführungsergebnisses.
Source Envelope
Das Plugin signiert auf dem Gerät, was der Mensch tatsächlich gesehen hat, mit einem Schlüssel, der es nie verlässt. Nachrichteninhalte werden nie übertragen.
Action Effect
Der Guardian — nicht das Modell — liest den Provider-Zustand und normalisiert die exakte Wirkung: Provider, Operation, Ressourcen, Parameter und ein Digest des Vorzustands.
Execution Grant
SecureStamp Cloud signiert einen Einmal-Grant, gebunden an dieses Wirkungs-Digest, an die genehmigende Autorität, an die geltende Richtlinienversion und an ein Ablaufdatum. maxUses ist immer 1.
Execution Claim
Dein Guardian beansprucht den Grant gegen sein eigenes Ledger. Ein wiedereingespielter Grant wird abgelehnt, bevor irgendein Provider kontaktiert wird.
Action Receipt
Der Guardian signiert die verbrauchte Autorisierung, den Ausführungskontext und das Ergebnis, das er feststellen konnte, zusammen mit dem Digest der lokalen Richtlinie, die ihn begrenzt hat.
Autorität
Keine Anfrage bringt ihre eigene Berechtigung mit.
Die Autorität, die eine Operation verlangt, legt das Protokoll fest. Der Aufrufer kann sie nicht wählen, das Modell kann nicht für sie argumentieren, und sie kann nicht innerhalb derselben Anfrage herabgestuft werden, die sie benötigt. Quorum-Profile sind signierte Richtlinien-Snapshots, keine Autoritätswerte: standard und elevated sind Labels für Menschen, während der Beweis auf dem Threshold, der Approver-Liste und dem Policy-Hash beruht.
noneGewährt niemals Ausführung. Existiert, damit ihr Fehlen explizit statt implizit ist.
policy_delegatedAutonomie innerhalb einer Richtlinie, die die Organisation im Voraus festgelegt hat, und nur für eine auf dem Gerät signierte Anfrage. Nie für eine korrelierte.
human_mfaEin namentlich bekannter Mensch genehmigt gegen eine aktive MFA-Session. Wird dort eingesetzt, wo die Wirkung begrenzt und in der Praxis umkehrbar ist.
quorumM-von-N unabhängige Approver, jeder mit eigener MFA-Session, gegen eine im Voraus festgelegte Richtlinie. Wer anfragt, kann die eigene Anfrage nie genehmigen. Pflicht für jede Vergabe von Privilegien.
Fehlersicherheit
Unbekannt bleibt unbekannt.
Eine mehrdeutige Provider-Antwort bleibt bis zum Abgleich unbestimmt. Mutierende Operationen werden nicht blind wiederholt.
Eine Zahlungs-API läuft in einen Timeout, nachdem sie eine Mutation empfangen hat. Sie zu wiederholen kann die Wirkung verdoppeln. SecureStamp nimmt kein Scheitern an und wiederholt nicht: Der Guardian gleicht den Provider-Zustand ab und kann indeterminate zurückgeben. Mehrdeutigkeit ist ein erstklassiges Ergebnis und wird nie zu Erfolg aufgerundet.
Unabhängige Überprüfung
Prüfen Sie die Kette, ohne uns zu fragen.
Der Verifizierer ist ein veröffentlichtes Paket ohne Netzwerkzugriff. Er berechnet jedes Digest und jede Signatur in einem Proof Bundle offline neu, einschließlich des Policy-Snapshot-Hashes und des Digests der signierten lokalen Richtlinie. Receipts lassen sich offline verifizieren, ohne SecureStamp zu kontaktieren, und die Verifikation hängt nicht von einem laufenden SecureStamp-Dienst ab.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.jsonDer Verifizierer erscheint vor den Artefakten, die er verifiziert. Eine neue Receipt- oder Bundle-Version wird nie ausgegeben, bevor ein veröffentlichter Verifizierer sie bereits akzeptiert.
Konnektoren
Bring den Ausführungspunkt mit, den du bereits nutzt.
Das Autorisierungsmodell von SecureStamp ist providerunabhängig. Dies sind Referenz-Connectoren, kein geschlossener Katalog. Wie ein Connector integriert wird und wie weit SecureStamp für ihn einsteht, sind zwei getrennte Fragen, und wir halten sie bewusst getrennt.
Wie es sich anbindet
Zertifizierter Adapter
Ein Modul, das wir geschrieben, geprüft und an veröffentlichte Zertifizierungsnachweise gebunden haben.
Deklarativer HTTPS-Adapter
Origin, Methode und Path werden bei der Installation fixiert. Keine beliebige URL, Methode oder Header vom Modell, keine Redirects, striktes Schema, deterministische Idempotenz.
SDK / sidecar
Für Protokolle, die den deklarativen Vertrag nicht erfüllen können, über einen Unix-Socket.
Wie die Zusicherung deklariert wird
SecureStamp Certified
Wir haben es geschrieben, geprüft und die Evidenz veröffentlicht.
Partner Attested
Ein namentlich genannter Partner steht dafür ein, und das Bundle sagt es.
Customer Defined
Du hast es gebaut. Die Kette verifiziert weiterhin, und das Bundle sagt unmissverständlich, dass SecureStamp den Connector-Code nicht zertifiziert hat.
Adapter übersetzen eine autorisierte Wirkung in providerspezifische Ausführung. Sie definieren die gewährte Autorität nicht neu.
Stripe
refund.createhuman_mfaOkta
group.add_userhuman_mfaAWS
iam.attach_role_policyquorumGoogle Cloud
iam.project_binding.addquorumAzure
rbac.role_assignment.createquorumMicrosoft Entra
pim.directory_role_assignment.createquorumPasst zu deiner bestehenden Control Plane
Funktioniert mit den Kontrollen, die du schon hast.
SecureStamp ersetzt weder Identität noch Policy Engines, Freigabe-Workflows oder Provider-APIs. Es bindet deren genehmigte Entscheidungen an exakte ausführbare Wirkungen.
Grenzen der Evidenz
Was ein Receipt belegt und was nicht.
Ein Action Receipt belegt, was durch einen enrollten Guardian lief, und das Ergebnis, das dieser Guardian feststellen konnte. Es belegt nicht, dass außerhalb von SecureStamp keine Aktion stattfand, und begründet auch kein rechtliches Eigentum am Provider-Konto.
Die Evidenzgrenze ist der enrollte Ausführungspfad.
Aktionen außerhalb dieses Pfads liegen außerhalb des Geltungsbereichs des Receipts.
Release-Status
Warum diese Pakete noch Beta heißen.
Protokoll, Code und Verifizierer sind heute vollständig und auditierbar. Aber wir nennen einen Connector erst dann stabil, wenn wir Evidenz von 100 realen Ausführungen gegen einen Live-Provider veröffentlicht haben — inklusive Fault Injection, Replay-Ablehnung und Beweis, dass die Credential nicht mehr hätte tun können — gebunden an genau den Commit, der sie erzeugt hat. Produktive Ausführung erfordert ausdrückliches Opt-in und Connector-Eignung, und bis ein Connector dieses Gate besteht, weigert sich sein Guardian, außerhalb des Sandbox-Modus zu laufen. Ein Trust-Produkt, das dich bittet, ihm einfach zu glauben, ist bereits gescheitert.
Pakete
@securestamp/action-proof-verifyDer Offline-Verifizierer und seine Verifikationsverträge. Wird vor allem veröffentlicht, was er verifiziert.
@securestamp/action-proofVerträge, Signierung und Proof Bundles.
@securestamp/execution-guardianDer vom Kunden gehostete Daemon und seine Provider-Connectoren.
@securestamp/execution-guardian-mcpDie MCP-Bridge. Keine Credentials, keine Cloud-SDKs, per Konstruktion.
Trust Levels
Trust Level erklärt den Ursprung. Action Verdict hilft, über die Aktion zu entscheiden.
Die Stufen L1-L5 bewerten überprüfbaren Ursprungsnachweis. Sie behaupten nicht, dass Inhalte wahr sind oder dass eine Aktion automatisch ausgeführt werden soll.
L1
Registriert
Die Domain oder Organisation ist bei SecureStamp registriert.
L2
Abgeglichen
Technische Signale wie SPF, DKIM, DMARC oder DNS sind stimmig.
L3
Signiert
Die Nachricht, der Kanal oder das Ereignis enthält ein signiertes und überprüfbares Token.
L4
Notariell beglaubigt
Für spätere Prüfung existiert eine überprüfbare Integritätsreferenz oder Quittung.
L5
Zertifiziert
Die organisatorische Identität hinter dem Ursprung wurde mit zusätzlichen Nachweisen geprüft.
Verifizierter Ursprung bedeutet keine genehmigte Aktion
Trust Level beschreibt die Stärke des Ursprungsnachweises. Action Verdict bewertet eine konkrete Aktion anhand von SSF, Kontext und Richtlinie. Ein legitimer Ursprung kann trotzdem eine Aktion anfordern, die geprüft werden muss.
Integrationspunkte
Vier Wege, Vertrauen zu deklarieren und abzufragen
DNS TXT record
Veröffentliche einen TXT-Record unter _securestamp.[domain]. Verifizierer lösen die Subdomain auf und validieren den deklarierten Ursprung, ohne private Inhalte einzusehen.
- —v=1 — Protokollversion
- —id=<stamp_id> — überprüfbarer Identifikator
- —url=<verify_url> — kanonische Verifizierungs-URL
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
Füge X-SecureStamp in ausgehende Nachrichten ein, damit Clients, Plugins und Gateways Ursprung und Status über signierte Signale abfragen können.
- —Token, signiert vom Absender oder autorisierten Knoten
- —Minimale Claims: stampId, domain, orgId, score, exp
- —Öffentlicher Schlüssel oder überprüfbare Referenz zur Validierung
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
Frage Domains, Kanäle oder Aktionen ab, ohne sensible Anweisungen im Klartext zu speichern. Antworten können Signale, Reasons und Trust Receipts enthalten.
- —Trust Checks für Domains und Kanäle
- —Action Verdict für sensible Aktionen
- —Überprüfbare Receipts für Audits
- —Öffentlicher Verifizierer und Registry, wo zutreffend
GET https://securestamp.org/v1/trust/example.com{
"domain": "example.com",
"trustLevel": "L3",
"signals": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
"actionVerdict": "needs_confirmation",
"receiptRef": "tr_01h..."
}MCP Server
Aktive Agent-Trust-Schicht, damit Agenten Trust Checks vor Tool Calls, APIs, Workflows und sensiblen Operationen abfragen können.
- —SecureStamp MCP Server
- —Tool call checks
- —Action Verdict vor der Ausführung
- —Menschliche Freigabe, wenn die Richtlinie es verlangt
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
Verifizierung offizieller Kanäle über konversationelle Oberflächen
Mit Signal lässt sich abfragen, ob eine Nummer, ein Bot, ein Handle, ein Link, ein Konto oder ein Kontaktpunkt zum offiziellen Perimeter gehört, den eine Entität deklariert hat. Es ist die Schicht für WhatsApp, Telegram, Web, QR, Support, Abrechnung und andere Kanäle, über die eine Person oder ein Agent sensible Anweisungen erhalten kann.
Offizieller Perimeter
Prüft E-Mail-, WhatsApp-, Telegram-, Web-, QR-, Support- und Abrechnungskanäle gegen überprüfbare Records.
Mit SSF verbunden
Kanalsignale fließen in Trust, Action Verdict und Receipts ein, ohne eine Marke zu einer absoluten Garantie zu machen.
Ehrliche Grenze
Signal verifiziert die Zugehörigkeit zum offiziellen Perimeter. Es beweist nicht, dass jede Nachricht wahr ist.
Receipts, Registry und Audit
Prüfbarer Nachweis, ohne sich auf Screenshots zu verlassen
Jede relevante Abfrage oder Deklaration kann ein überprüfbares Receipt erzeugen. Receipts helfen, Ursprung, Kanal, deklarierte Absicht und Action Verdict zu prüfen, ohne einer Oberfläche blind zu vertrauen.
Trust Receipts
Signierte Receipts mit Signal, erlaubtem Kontext, Zeitstempel und überprüfbarer Referenz.
Registry
Tokens, Receipts und öffentliche Referenzen lassen sich ohne Authentifizierung prüfen, wenn der Ablauf es zulässt.
Audit
Organisationen können Receipts mit internen Richtlinien, Freigaben und Compliance-Kontrollen kombinieren.
Öffentliches Glossar
Eine gemeinsame Sprache für Nutzer, Support und Integratoren
The glossary explains SecureStamp, email, cryptography, Signal, E2EE, API and infrastructure terms so a non-technical person or junior developer can understand what they are reading.
Glossar öffnenSecureStamp Terms
Concepts created or defined by SecureStamp to explain trust, stamps, receipts and verifiable perimeters.
Email, Domains and Authentication
Classic abbreviations used when SecureStamp explains whether a sender or domain is properly authenticated.
Cryptography and Security
Terms needed to understand signatures, encryption, keys, verifiable logs and enterprise recovery.
Protocols, APIs and Infrastructure
Common language for junior developers and integrators reading APIs, plugins, dashboards or runbooks.
Föderiertes Netzwerk
Föderiertes Netzwerk und zugelassene Knoten
Die SecureStamp Foundation koordiniert ein Netzwerk zugelassener Knoten, die gemeinsame Records schreiben und verifizieren. Einen Knoten zu betreiben erfordert technische Prüfung, SLA und Übereinstimmung mit den Governance-Prinzipien.
Antrag einreichen
Organisation, Region, Betriebskapazität, erwartetes SLA, technische Oberfläche und deklarierten Anwendungsfall angeben.
Technische Prüfung
Die Foundation bewertet Kapazität, operative Sicherheit, Abdeckung und mögliche Interessenkonflikte.
Zugangsdaten ausgestellt
Bei Zulassung erhält der Betreiber Zugangsdaten und Integrationsanforderungen für die Teilnahme am Netzwerk.
Auditierter Betrieb
Der Knoten muss Verfügbarkeit, öffentliche Health, operative Nachvollziehbarkeit und Incident-Response-Prozesse aufrechterhalten.
Pflichten des Knotens
Überprüfbares Registry
Marken, Receipts und öffentliche Referenzen prüfen
Jede von SecureStamp ausgestellte Marke, jedes Receipt und jede öffentliche Referenz lässt sich prüfen, ohne diese Seite in eine kommerzielle Landingpage zu verwandeln. Die Foundation pflegt den Standard und die Abfragepunkte.
securestamp.org/verify/[token]Technische FAQ
Häufige Fragen für Entwickler und Integratoren
Was ist die SecureStamp Foundation?
Die Instanz, die den offenen SecureStamp-Standard veröffentlicht und verwaltet — für die Prüfung von Ursprung, Absicht, Kanal und Aktion, bevor gehandelt wird.
Welches Problem löst das Protokoll?
Es hilft Menschen, Systemen und Agenten, überprüfbare Signale abzufragen, bevor sie antworten, zahlen, Daten teilen, APIs aufrufen oder Workflows ausführen.
Wie hängen Vertrauens-Stack und Oberflächen zusammen?
Der Vertrauens-Stack besteht aus Ursprung, Absicht, Execution Authorization und Ausführungsnachweis. Die Oberflächen sind E-Mail, offizielle Kanäle, Agenten, APIs und Workflows. Es sind zwei unabhängige Achsen: derselbe Stack gilt für jede Oberfläche, und Execution Authorization ist eine Schicht, nie eine eigene Oberfläche.
Was ist Proof of Origin?
Überprüfbarer Nachweis, dass eine Domain, ein Kanal, ein Absender oder eine Organisation einem registrierten Ursprung entspricht.
Was ist Execution Authorization?
Der Vorgang, eine genehmigte Entscheidung an eine begrenzte, transaktionsspezifische Befugnis zu binden, die Software erlaubt, unter expliziten Einschränkungen eine definierte Wirkung zu verursachen. Zugriffskontrolle begrenzt, was Software erreichen kann; Execution Authorization begrenzt die exakte Wirkung, die sie verursachen darf.
Was ist Action Verdict?
Eine Bewertung einer konkreten Aktion vor der Ausführung. Sie kann je nach Signalen und Richtlinie erlauben, prüfen, verweigern oder menschliche Freigabe empfehlen.
Was ist SSF?
SecureStamp Signal Framework: eine gemeinsame Sprache für Signale zu Ursprung, Authentifizierung, Kanal, Inhalt, Kontext, Aktion und Verdict.
Was ist der SecureStamp MCP Server?
Eine Developer-Preview-Richtung, in der Agenten vor sensiblen Tool-Aufrufen Trust Checks über das Model Context Protocol abfragen.
Docs und Spezifikation
Protokolldokumentation
Die Spezifikation deckt Proof of Origin, Proof of Intent, SSF, Action Verdict, Integrationspunkte, Receipts, ehrliche Grenzen und die MCP-Richtung für Agenten ab.
Fragen zur Spezifikation oder zum Protokolldesign? protocol@securestamp.org
Kontakt
Melde dich
Jede Adresse führt direkt zum richtigen Team. Kein Ticketsystem — echte Menschen.