Veil

Ein KI-Agent kann die Platzierung einer Anmeldeinformation orchestrieren, ohne jemals den Wert der Anmeldeinformation zu erhalten, während eine vertrauenswürdige, von Menschen gesteuerte Schnittstelle unabhängig autorisiert, wohin diese Anmeldeinformation gelangen darf.

Dieser Satz ist das gesamte Versprechen. Veil ist ein MCP-Server plus ein sicherer Eingabe-Broker: Der Agent sagt „Lege einen Stripe-Produktionsschlüssel in Google Secret Manager ab“, der Mensch sieht genau, welches Projekt und welches Secret geschrieben werden, und gibt den Wert in das eigene Fenster von Veil ein, und der Wert geht direkt zum Ziel. Das Modell hält ihn nie.

Implementiert gemäß SPEC.md.

Was Veil löst

Es beseitigt eine ganze Klasse von Fehlern, die dadurch verursacht werden, dass der Agent das Geheimnis kennt. Mit Veil in der Schleife durchläuft eine Anmeldeinformation nicht:

• LLM-Prompts oder Gesprächsverlauf

• MCP-Tool-Argumente oder Tool-Ergebnisse

• Agentenspeicher oder generierten Code

• Shell-Befehlsargumente oder Prozess-argv

• Logs, Debug-Traces oder Telemetrie

• URLs

• Modell-sichtbare Befehlsausgabe

Was Veil nicht löst

Veil macht einen KI-Agenten nicht vertrauenswürdig und ist keine „sichere KI“. Es garantiert nicht, dass der Agent das richtige Ziel ausgewählt hat, dass er Sie verstanden hat, dass er frei von Prompt-Injection ist, dass das Ziel selbst sicher ist, dass Ihr Rechner nicht kompromittiert ist oder dass eine Anmeldeinformation später nicht von Software missbraucht werden kann, die sie legitimerweise erhält.

Es gibt hier zwei getrennte Probleme:

Veil beantwortet diese beiden. Es behauptet nicht, die restlichen zu beantworten.

Vertrauensmodell

Trusted with the credential value:

  The human at the keyboard
  Veil's secure input UI          (loopback only, in your control)
  Veil's secure input broker      (this process)
  The selected destination adapter
  The destination provider        (e.g. Google Secret Manager)

NOT trusted with the credential value:

  The LLM
  The agent / MCP client
  The conversation
  The prompt and any repository content it read
  Generated code
  Logs, telemetry, crash reports

Dieses Diagramm behauptet nicht, dass die vertrauenswürdigen Komponenten unverwundbar sind. Es sagt, wo die Anmeldeinformation existieren darf. Veil ist sicherheitskritische Software: Wenn Veil selbst bösartig oder kompromittiert ist, ist die Grenze weg. Sein Quellcode, seine Abhängigkeiten und seine Veröffentlichungen verdienen die Prüfung, die Sie jedem Werkzeug zur Handhabung von Anmeldeinformationen zukommen lassen würden.

Die beiden Abläufe

Der Geheimnis-Ablauf – der Pfad des Menschen, den das Modell nicht beobachten kann:

Human ─▶ Veil secure UI (127.0.0.1) ─▶ Broker ─▶ Adapter ─▶ Destination

Der Agenten-Ablauf – alles, was das Modell sieht:

LLM ─▶ MCP client ─▶ Veil MCP server ─▶ non-sensitive result metadata

Das MCP-Tool-Schema hat keine Eigenschaft, die eine Anmeldeinformation transportieren kann. Das ist strukturell, keine Prompt-Anweisung: Es gibt kein Feld value, secret_value, password, token, content oder raw_secret, das missbraucht werden könnte, geschlossene Schemata lehnen unbekannte Eigenschaften ab, und Argumente werden auf geheimnisförmige Werte geprüft, bevor sie geparst werden.

Was der Agent aufruft

{
  "destination": "gcp-secret-manager",
  "name": "STRIPE_SECRET_KEY",
  "target": { "project": "my-production-project", "secret": "STRIPE_SECRET_KEY" },
  "write_mode": "new-version",
  "environment": "production",
  "description": "Stripe production API key"
}

Veil antwortet mit einer request_id, einer Risikoklassifizierung und dem normalisierten Ziel – und öffnet sein eigenes Autorisierungsfenster auf Ihrem Rechner. Der Agent fragt secret.status ab.

Der Agent erhält den Autorisierungslink nicht. Dieser Link ist eine Fähigkeit: Alles, was ihn hält, kann die Hälfte des Ablaufs des Menschen abschließen, und ein Agent mit einer Shell oder einem HTTP-Tool ist genau das Bedrohungsmodell. Veil übergibt ihn an Ihren Browser und gibt ihn stattdessen in seiner eigenen Konsole aus. Setzen Sie VEIL_DISCLOSE_AUTHORIZATION_URL=true, wenn Ihr Setup den Agenten benötigt, um den Link weiterzuleiten (z. B. bei einer Remote- oder Headless-Sitzung) – und verstehen Sie, dass dies einem kompromittierten Agenten erlaubt, seine eigene Anfrage zu autorisieren.

Was der Mensch sieht

Stufe A zeigt den Namen der Anmeldeinformation, den Zielanbieter, das Projekt/Konto, die Ressource, die Operation und das Risiko bevor der Wert eingegeben wird. Operationen mit hohem Risiko (Produktionsüberschreibung, Klartextspeicherung, Anwendungsdatenbanken, Ersetzen einer Anmeldeinformation) erfordern eine zweite Bestätigung in Stufe B, nach der Eingabe und vor dem Schreiben. Der Wert wird nie wieder angezeigt.

Die Seite, die der Mensch liest, und die Operation, die der Ausführer durchführt, sind das gleiche unveränderliche Objekt – es gibt kein separates „Anzeigeziel“. Jede Änderung des Ziels, des Projekts, des Secret-Namens, der Operation, des Schreibmodus oder des Adapters macht die Autorisierung ungültig und erfordert eine neue.

Unterstützte Adapter

arbitrary-network-Ziele (generischer HTTP-POST, Webhooks) sind nicht implementiert, und die Adapter-Registrierung weigert sich, eines zu registrieren.

Sicherheitsannahmen und -einschränkungen

Klar ausgedrückt, weil ein Sicherheitstool, das sich selbst überverkauft, schlimmer ist als keins:

• Der Broker-Prozess sieht das Geheimnis. Das ist der Punkt: Etwas muss es, sonst ist Speicherung unmöglich. Die Garantie ist, dass nur die minimalen vertrauenswürdigen Transport- und Zielkomponenten es tun.

• CPython kann Speicher nicht zuverlässig löschen. SecretBuffer löscht den veränderlichen Puffer, den es besitzt, aber Prozent-Decodierung, str/bytes-Konvertierungen und Provider-SDKs erstellen unveränderliche Kopien, die der Interpreter bis zur Speicherbereinigung behalten kann. Veil minimiert und fabriziert diese Garantie nicht.

• Die Benutzeroberfläche ist Loopback-HTTP. Jeder Prozess, der als Ihr Benutzer auf Ihrem Rechner läuft, kann sie erreichen, und jeder solche Prozess könnte sie auch imitieren. Jeder Veil-Prozess gibt eine zufällige Identitätsphrase aus, die seine Seiten anzeigen (Anti-Spoofing-Hilfe, keine kryptografische Kontrolle). Das Vorenthalten des Links gegenüber dem Agenten erhöht die Hürde; es stoppt keinen Prozess, der die Konsolenausgabe von Veil lesen, das argv des Browsers auflisten oder Loopback-Ports scannen kann.

• Veil prüft das Ziel nicht. Wenn Sie eine Anmeldeinformation für ein Firestore-Dokument autorisieren, schreibt Veil sie dort hin und teilt Ihnen mit, dass es eine schlechte Idee ist; es hält Sie nicht davon ab.

• Die Vorabprüfung ist nach bestem Wissen und Gewissen. Ein Provider, der bei der Vorabprüfung nicht erreichbar ist, wird als nicht verfügbar gemeldet, anstatt geraten zu werden.

• Absturzsemantik. Ein Absturz zwischen dem Provider-Schreibvorgang und der Antwort kann dazu führen, dass eine Anmeldeinformation ohne lokale Erfolgsaufzeichnung geschrieben wird. Veil meldet die Anforderung als fehlgeschlagen; das Ziel ist die Quelle der Wahrheit.

Lokale Entwicklung

uv venv
uv pip install -e ".[dev]"

# run the server the way an MCP client would
uv run veil serve

# with optional providers
uv pip install -e ".[dev,gcp,firestore]"

Die Konfiguration wird aus Veils eigener Umgebung gelesen – niemals aus Tool-Argumenten:

MCP-Client-Konfiguration

{
  "mcpServers": {
    "veil": { "command": "uv", "args": ["run", "veil", "serve"] }
  }
}

Tests

uv run pytest                  # everything
uv run pytest tests/security   # the adversarial suite only
uv run ruff check .
uv run mypy

Die Sicherheitssuite ist eine Produktanforderung, keine Annehmlichkeit. Sie enthält Canary-Leckage-Erkennung über jeden beobachtbaren Kanal, bösartige Agententests, Prompt-Injection-Fixtures, TOCTOU- und Replay-Tests, 100-fache Nebenläufigkeits-Stresstests, Wettlaufsituationen, Absturzpfade, Provider-Fehler-Simulation, UI-Prüfungen und Fuzzing. Eine Veröffentlichung wird blockiert, wenn ein Canary ausläuft, eine Autorisierungsumgehung erfolgreich ist, eine Mutation nach der Genehmigung erfolgreich ist, eine abgeschlossene Anforderung wiederholbar ist, ein Geheimnis eine Anforderungsgrenze überschreitet, ein roher Provider-Fehler MCP erreicht oder eine Operation mit hohem Risiko die Bestätigung überspringt.

Siehe docs/SECURITY_MODEL.md für die Invarianten-zu-Test-Zuordnung.

Projektstatus

Version 0.1.0, erstellt gemäß SPEC.md, die im Repository als maßgebliche Beschreibung des beabsichtigten Verhaltens verbleibt. Jedes wesentliche Modul und jeder Test zitiert den Abschnitt, den es implementiert, sodass ein Prüfer den Code gegen die Anforderung prüfen kann, anstatt gegen eine Zusammenfassung davon.

Der MVP ist abgeschlossen und die vollständige Suite – einschließlich der adversariellen – besteht. Was bleibt, bevor jemand sich im Ernst darauf verlassen sollte: unabhängige Überprüfung, Human-Faktor-Tests der Bestätigungs-Benutzeroberfläche (SPEC.md §35) und signierte Veröffentlichungsartefakte (§43).

Mitwirken

Sicherheit ist hier das Produkt, daher ist die Hürde für Änderungen spezifisch und nicht bürokratisch:

• Eine Änderung, die die Handhabung von Anmeldeinformationen, die Autorisierung oder die MCP-Oberfläche betrifft, benötigt einen Test, der versucht, die Invariante zu brechen, die sie betrifft, nicht nur einen, der zeigt, dass sie funktioniert.

• Schwächen Sie niemals einen Sicherheitstest, um eine Suite bestehen zu lassen. Wenn ein Test einen architektonischen Fehler aufdeckt, ist es die Architektur, die sich ändert.

• Neue Laufzeitabhängigkeiten im Kern sind standardmäßig abzulehnen. Der Broker ist die vertrauenswürdige Rechenbasis für Anmeldeinformationsmaterial; Provider-SDKs gehören hinter eine optionale Erweiterung.

• Führen Sie ruff check ., ruff format --check ., mypy und pytest aus, bevor Sie einen Pull-Request öffnen.

Eine Sicherheitslücke gefunden? Bitte melden Sie sie privat über die Sicherheitshinweise von GitHub, anstatt ein öffentliches Issue zu eröffnen.

Lizenz

Apache License 2.0 © 2026 Eduardo Rosostolato.