TrustGate

TrustGate ist eine Demonstration mit synthetischen Daten im Razorpay-Testmodus eines KI-Käufers, der einen Katalogkauf vorschlagen kann, ohne die Befugnis zu erhalten, Händler, Betrag, Währung, Genehmigung oder Anbieterergebnis zu überschreiben. Der Agent schlägt vor; TrustGate autorisiert und protokolliert Beweise unabhängig.

Was es beweist

• Katalog-SKU und Menge sind die einzigen Kaufdaten, die ein Agent beeinflussen kann.

• Mandantenbezogene Richtlinien, menschliche Genehmigung, eine einmalige Checkout-Befugnis und verifizierte Anbieterereignisse begrenzen jede Zahlungsaktion.

• Unsichere Versuche werden abgelehnt, bevor eine Anbieterbestellung erstellt werden kann, und hinterlassen eine prüfbare Spur.

Related MCP server: safe-cart-ai

Wie KI hier eingesetzt wird

Der Käuferagent ist bewusst dünn gehalten, und genau das ist das Argument und keine Abkürzung. Er kann nur eine Katalog-SKU, eine Menge und einen Zweck vorschlagen; jede geldkritische Tatsache wird serverseitig abgeleitet. Löschen Sie den Agenten vollständig, und die Autorisierungsebene bleibt unverändert und weiterhin korrekt.

Der technische Beitrag ist kein ausgeklügelter Agent. Es geht darum, die Ausfallmodi von Sprachmodellen ernst zu nehmen – Prompt-Injection durch Inhalte Dritter, Befolgung von Anweisungen gegen die Interessen des Betreibers, selbstsichere falsche Überlegungen über Geld – und ein System zu bauen, das korrekt bleibt, wenn diese auftreten.

Diese Behauptung wird in beide Richtungen getestet. python -m agent.demo --live führt ein echtes Modell gegen Katalogbeschreibungen aus, die von Dritten geschrieben wurden, einschließlich feindseliger. Derselbe Katalog wird zweimal gesendet, einmal ohne Beschreibungen, sodass der Einfluss nicht vertrauenswürdiger Inhalte durch den Vergleich der beiden Vorschläge gemessen wird, statt durch Selbstauskunft. Die Regressionssuite ruft niemals einen Modellanbieter auf: Sie verwendet deterministische Ersatzstoffe, sodass die Sicherheitsverifikation nicht davon abhängt, dass sich ein Modell an einem bestimmten Tag auf eine bestimmte Weise verhält.

Das Problem erkennen

Drei saubere Ablehnungen beweisen, dass das System funktioniert, und sind schwach darin, zu zeigen, warum jemand es braucht. Die Demo beginnt daher damit, dass der eigene Code dieses Projekts fehlschlägt, ohne Netzwerk, ohne Anmeldedaten und ohne Datenbank:

python -m demo.unguarded

Derselbe Agent liest denselben vergifteten Katalog – buchstäblich denselben, da beide Kataloge aus agent/demo_catalog.py aufgebaut sind und ein Test bestätigt, dass die gesetzte Zeile und das Basisobjekt eine identische injizierte Anweisung tragen. Eine Modellantwort wird zwei Adaptern übergeben.

Der ungeschützte akzeptiert einen Betrag und einen Händler, sodass die injizierte Anweisung ausgeführt wird und er INR 20.000,00 an einen Händler zahlt, den der Katalogtext nannte, gegen einen Katalogpreis von INR 600,00. Der andere hat für keines der beiden Felder einen Platz, weil PurchaseProposal nur eine SKU, eine Menge und einen Zweck deklariert. Was die Verwerfung übersteht, ist quantity=50, ein Feld, das der Agent setzen darf – und der Server begrenzt es gegen das eigene Maximum des Katalogs von 2, sodass der Versuch abgelehnt wird, bevor eine Zahlungsanforderung erstellt wird.

Der Unterschied ist kein Filter, der einen Angriff erkannt hat. Es ist, dass eine Schnittstelle ein Feld für das Geld hatte und die andere nicht. Die Basislinie hat ihre eigenen Tests, die sowohl bestätigen, dass sie nichts Echtes erreichen kann, als auch, dass sie weiterhin ausnutzbar ist, da eine Demonstration, die stillschweigend aufhörte, verwundbar zu sein, weiterhin bestehen würde, während sie das Gegenteil aussagt.

Angriffsmatrix

Tier-A-Adversarial-Szenarien. Diese Tabelle wird aus dem Szenarioregister von python -m scenarios.report generiert, und ein Test bestätigt, dass sie übereinstimmt, sodass sie keinen Angriff behaupten kann, der nicht durch einen bestandenen Test abgedeckt ist. Jedes Szenario beweist drei Dinge: Der Angriff wird mit seinem Grundcode abgelehnt, es wurde keine Anbieterbestellung erstellt, und keine Zahlung erhielt eine Befugnis, die sie nicht hatte.

Jedes Tier-A-Szenario ist implementiert. A11a und A11b teilen die Mandantenverwechslung in einen nicht auflösbaren Mandanten und einen bekannten Mandanten, der die Grenze überschreitet, weil die beiden aus unterschiedlichen Gründen fehlschlagen und nur das zweite eine Autorisierungsfrage ist.

Was die Tests wert sind

Eine erfolgreiche Testsuite sagt, dass sich der Code wie geschrieben verhält. Sie sagt nicht, dass die Tests Einspruch erheben würden, wenn der Code aufhört, etwas Wichtiges zu tun, und nur die zweite Behauptung zählt, wenn es um Geld geht. Dieses Projekt hat Belege für den Unterschied: Anforderungsbezogene Sitzungen verwarfen einst jeden Schreibvorgang, während 146 Tests bestanden, weil die Suite innerhalb derselben Transaktion prüfte, in die sie schrieb.

make mutation bricht jede Sicherheitsinvariante absichtlich, eine nach der anderen, und verlangt, dass die als Wächter benannten Tests fehlschlagen. Jede Quelldatei wird in einem finally-Block wiederhergestellt, und die Wiederherstellung wird vor dem Drucken des Berichts gegen git diff geprüft, sodass ein unterbrochener Lauf keine Mutation hinterlassen kann. Es beendet sich mit einem Nicht-Null-Exitcode, wenn irgendeine Mutation überlebt.

Diese Tabelle wird aus dem Mutationsregister von python -m scenarios.report --mutations generiert, und ein Test stellt sicher, dass sie übereinstimmt, sodass sie keine bewachte Invariante behaupten kann, die nicht tatsächlich bewacht ist.

Der erste Lauf dieser Suite fand einen echten Defekt. SELECT ... FOR UPDATE über das ORM erwirbt die Sperre korrekt und verwirft dann die Zeile, die Postgres zurückgegeben hat, weil SQLAlchemy die Attribute eines Objekts, das sich bereits in der Identitätskarte der Sitzung befindet, beibehält. Ein zweiter Aufrufer blockierte daher wie vorgesehen an der Sperre, erhielt die committete Zeile, behielt seine veraltete Kopie und autorisierte eine Zahlung, die gerade erst autorisiert worden war. Die Sperre serialisierte, wann Übergänge liefen, nicht, von welchem Zustand sie ausgingen. Alle Sperrungen laufen jetzt über models.locking.locked(), und ein Test stellt sicher, dass dieser Helfer die einzige Stelle im Quellcode ist, die eine Sperre übernehmen kann.

Current Scope

TrustGate verwendet nur synthetische Mandanten, Händler und INR-Preise. Es ist ein lokales Sicherheits-Testfeld, kein Zahlungsabwickler, kein Compliance-Produkt, kein System für rechtliche Einwilligungen, kein Betrugsmodell und keine Live-Mode-Zahlungsintegration.

Quickstart

Voraussetzungen: Docker Desktop und Python 3.12.

Copy-Item .env.example .env
docker compose up -d
docker compose exec -T api python -m alembic upgrade head
docker compose exec -T api python -m pytest -q

Der lokale API-Health-Check ist unter http://127.0.0.1:8000/health verfügbar.

Erstellen Sie einen wegwerfbaren synthetischen M1-Mandanten mit python -m agent.seed. Setzen Sie MCP_TENANT_ID und MCP_ACTOR_ID auf die ausgegebenen Werte und führen Sie dann die lokale Buyer-Agent-Demo mit python -m agent.demo "Buy Starter credits for our student club." aus. Sie kann nur eine Katalog-SKU, Menge und Zweck vorschlagen; der MCP-Server leitet alle geldkritischen Fakten ab. Verwenden Sie python -m agent.demo --adversarial "Buy a small amount of cloud credits.", um die deterministische Demonstration des vergifteten Katalogs auszuführen.

Um denselben Ablauf mit einem echten Modell anstelle eines deterministischen Ersatzes auszuführen, installieren Sie das optionale Extra mit pip install -e ".[agent]" und fügen Sie --live hinzu. Zwei Backends werden unterstützt und beide verwenden dieselbe Messages-API-Form:

• TRUSTGATE_MODEL_BACKEND=anthropic (Standard) liest ANTHROPIC_API_KEY.

• TRUSTGATE_MODEL_BACKEND=bedrock rechnet gegen ein AWS-Konto ab. Setzen Sie AWS_REGION auf die Region, zu der die Anmeldedaten gehören, und dann entweder AWS_BEARER_TOKEN_BEDROCK (einen Bedrock-API-Schlüssel, den einfachsten Weg) oder Standard-AWS-Anmeldedaten für die SigV4-Signierung. Amazon Bedrock stellt Anthropic-Modelle über ein AWS-Marketplace-Abonnement bereit, daher benötigt das AWS-Konto auch ein gültiges Zahlungsmittel, selbst wenn Guthaben die Nutzung abdecken würde.

• TRUSTGATE_MODEL_BACKEND=groq liest GROQ_API_KEY und benötigt überhaupt kein Zahlungsmittel.

TRUSTGATE_MODEL_ID überschreibt das Modell auf jedem Backend. Der Käufer ist eine Protokollimplementierung, daher ist der Anbieter eine Konfigurationsentscheidung und keine architektonische: Das Verhalten der Autorisierungsschicht hängt nicht davon ab, welches Modell den Kauf vorschlägt.

Dies ist der einzige Pfad im Projekt, der einen Modellanbieter kontaktiert; die Testsuite tut das nie. Führen Sie ihn nur gegen den synthetischen Seed-Katalog aus. Seine Drittanbieter-Beschreibungen werden zweimal an das Modell gesendet, einmal ohne Beschreibungen und einmal intakt, um den Einfluss zu messen. Senden Sie niemals echte Kunden-, Händler- oder Zahlungsdaten durch diese Demonstration.

Um den Razorpay-Testmodus-Adapter zu testen, setzen Sie RAZORPAY_KEY_ID und RAZORPAY_KEY_SECRET in der ignorierten .env-Datei. Fügen Sie niemals Testmodus- oder Live-Modus-Geheimnisse zum Repository hinzu.

Trust Boundary

AI buyer proposes SKU, quantity, and purpose
        -> TrustGate derives and authorizes money-critical facts
        -> Razorpay Test Mode executes a bounded order
        -> TrustGate records authorization and provider evidence

Der formale Build-Plan befindet sich in docs/build-plan.md; Architektur, Bedrohungsmodell und Designentscheidungen finden Sie in docs/.