Zugangsdaten für Claude-Agenten sicher verwalten

TL;DR

Ein Tresor speichert Zugangsdaten, die nie in die Sandbox gelangen. Der Agent sieht einen undurchsichtigen Platzhalter; der echte Wert wird erst beim Verlassen der Umgebung eingesetzt. Damit kann Code in der Sandbox — auch vom Modell erzeugter — das Geheimnis nicht auslesen, selbst bei erfolgreicher Prompt-Injektion.

Das Problem

Ein Agent soll ein Ticketsystem abfragen, eine Nachricht senden oder ein Kommandozeilenwerkzeug aufrufen. Alle drei brauchen einen Zugangsschlüssel.

Der naheliegende Weg — den Schlüssel in den Systemprompt oder in eine Nachricht zu schreiben — ist der schlechteste. Prompts und Nachrichten liegen in der Ereignishistorie der Sitzung, sind über die Ereignisliste abrufbar und landen in Verdichtungs-Zusammenfassungen. Ein dort abgelegtes Geheimnis ist für die Lebensdauer der Sitzung dauerhaft lesbar.

Wie der Tresor das löst

Sandbox                    Anthropic-Ausgang           Zielsystem
────────                   ─────────────────           ──────────
curl -H "Authorization:    Platzhalter wird durch      empfängt den
Bearer <PLATZHALTER>"  ──► echtes Geheimnis      ───►  echten Schlüssel
                           ersetzt

Der Container sieht ausschließlich den Platzhalter. Die Ersetzung passiert nach dem Verlassen der Sandbox. Das ist eine bewusste Sicherheitsgrenze: Code, der in der Sandbox läuft — einschließlich allem, was der Agent selbst schreibt — kann das Geheimnis nicht lesen und nicht ausleiten.

Zwei Arten von Zugangsdaten

MCP-Zugangsdaten werden über die Server-Adresse zugeordnet. Verbindet sich der Agent mit einem MCP-Server unter dieser Adresse, wird das Token automatisch eingesetzt. OAuth-Token werden dabei selbstständig erneuert.

Die Zuordnung ist normalisiert, nicht bytegenau: Schema und Host werden kleingeschrieben, Standardports und abschließende Schrägstriche entfernt. Ein anderer Pfad, eine andere Subdomain oder ein abweichender Port brechen die Zuordnung dagegen — und dann läuft die Verbindung unauthentifiziert.

Umgebungsvariablen werden über den Variablennamen zugeordnet und in ausgehende Anfragen eingesetzt. Das ist der Weg für alles, was nicht MCP ist: Kommandozeilenwerkzeuge, SDKs, direkte Aufrufe aus der Shell.

{
  "display_name": "Twilio-Schlüssel für Sandbox",
  "auth": {
    "type": "environment_variable",
    "secret_name": "TWILIO_API_KEY",
    "secret_value": "sk-...",
    "networking": {
      "type": "limited",
      "allowed_hosts": ["api.twilio.com", "*.twilio.com"]
    },
    "injection_location": {"header": true}
  }
}

Die vier Fallen

Falle 1: zwei Netzwerkebenen. allowed_hosts am Zugangsdatum steuert, für welche Hosts das Geheimnis eingesetzt wird — nicht, welche Anfragen erlaubt sind. Der Agent muss den Host zusätzlich auf Umgebungsebene erreichen dürfen. Fehlt der Host auf einer der beiden Ebenen, scheitert der Aufruf.

Falle 2: Kopf oder Rumpf. injection_location steuert, wo im Aufruf ersetzt wird. Über die API bedeutet ein weggelassenes Feld: beide Orte aktiv. In der Konsole angelegte Zugangsdaten sind dagegen standardmäßig nur im Kopf aktiv.

Die Folge, wenn Ihr Client den Schlüssel im Rumpf sendet — etwa bei einer formkodierten Token-Anfrage: Der Platzhalter geht wörtlich durch, und das Zielsystem antwortet mit einem eigenen Authentifizierungsfehler. Ein Platzhalter an einem deaktivierten Ort wird weder ersetzt noch entfernt.

Falle 3: Geheimnisse im Pfad gehen nicht. Ersetzt wird in Kopfzeilen und Rumpf — nicht im URL-Pfad. Dienste, deren Authentifizierung über einen Pfad-Bestandteil läuft, etwa eingehende Webhook-Adressen bei Chatdiensten, lassen sich damit nicht absichern. Weichen Sie auf kopfbasierte Authentifizierung aus.

Falle 4: clientseitige Formatprüfung. Manche Werkzeuge prüfen das Format eines Schlüssels lokal, bevor sie eine Netzwerkanfrage stellen — etwa auf ein bestimmtes Präfix. Die sehen den Platzhalter und brechen ab, bevor überhaupt eine Ersetzung stattfinden könnte.

Wenn der Tresor nicht passt

Zwei Fälle: selbst betriebene Sandboxen (dort gibt es keinen Anthropic-Ausgang, an dem ersetzt werden könnte) und Clients, die an Falle 4 scheitern.

Dann bleibt das eigene Werkzeug. Der Agent meldet einen Werkzeugaufruf, Ihr Orchestrierer führt den authentifizierten Aufruf mit seinen eigenen Zugangsdaten aus und gibt das Ergebnis zurück:

for event in stream:
    if event.type == "agent.custom_tool_use" and event.name == "ticket_abfragen":
        ergebnis = ticketsystem.abfragen(event.input["id"])   # eigener Schlüssel
        client.beta.sessions.events.send(session.id, events=[{
            "type": "user.custom_tool_result",
            "custom_tool_use_id": event.id,
            "content": [{"type": "text", "text": json.dumps(ergebnis)}],
        }])

Das öffnet keinen Endpunkt nach außen: Der Werkzeugaufruf kommt über den Ereignisstrom, den Ihr Orchestrierer ohnehin mit Ihrem Schlüssel offen hält. Ihr Orchestrierer ist ein Client, kein Server.

Weitere Regeln

• Schlüssel je Tresor eindeutig — Server-Adresse beziehungsweise Variablenname dürfen nicht doppelt vorkommen, sonst Fehler 409
• Schlüssel unveränderlich — Geheimniswert und Anzeigename lassen sich ändern; für eine andere Adresse oder einen anderen Variablennamen archivieren Sie und legen neu an
• Höchstens 20 Zugangsdaten je Tresor
• Keine Prüfung vor Sitzungslaufzeit — ein ungültiges Zugangsdatum verhindert das Anlegen der Sitzung nicht; der Fehler erscheint erst bei der Nutzung als Ereignis
• Rechte eng schneiden — der Agent kann alles, was der Schlüssel erlaubt

Häufig gestellte Fragen

Sieht der Agent meine API-Schlüssel?

Nein, bei Tresor-Zugangsdaten nicht. Der Container sieht einen undurchsichtigen Platzhalter; das echte Geheimnis wird erst beim Verlassen der Sandbox eingesetzt. Das ist eine bewusste Sicherheitsgrenze — auch vom Modell erzeugter Code kann das Geheimnis nicht auslesen.

Warum wird mein Geheimnis nicht eingesetzt?

Meist wegen einer der beiden Netzwerkebenen: allowed_hosts am Zugangsdatum steuert nur, für welche Hosts eingesetzt wird — der Host muss zusätzlich auf Umgebungsebene erreichbar sein. Die zweite häufige Ursache ist der Einsetzungsort: In der Konsole angelegte Zugangsdaten sind standardmäßig nur im Kopf aktiv, während über die API ein weggelassenes Feld beide Orte aktiviert.

Kann ich API-Schlüssel in den Systemprompt schreiben?

Nein. Prompts und Nachrichten liegen in der Ereignishistorie der Sitzung, sind über die Ereignisliste abrufbar und landen in Verdichtungs-Zusammenfassungen. Ein dort abgelegtes Geheimnis ist für die Lebensdauer der Sitzung dauerhaft lesbar — genau das, was der Tresor verhindert.

Funktionieren Tresor-Zugangsdaten mit selbst betriebenen Sandboxen?

Umgebungsvariablen-Zugangsdaten derzeit nicht: Sie brauchen den von Anthropic verwalteten Ausgang, an dem die Ersetzung stattfindet — und bei einer selbst betriebenen Sandbox gehört der Ausgang Ihnen. Nutzen Sie dort ein eigenes Werkzeug, dessen authentifizierten Aufruf Ihr Orchestrierer ausführt.

Was tun, wenn ein Werkzeug den Platzhalter ablehnt?

Manche Clients prüfen das Format eines Schlüssels lokal, bevor sie eine Netzwerkanfrage stellen — die sehen den Platzhalter und brechen ab, bevor eine Ersetzung stattfinden könnte. In diesem Fall führt der Weg über ein eigenes Werkzeug, bei dem Ihr Orchestrierer den Aufruf host-seitig mit dem echten Schlüssel ausführt.

Der nächste Schritt

Suchen Sie in Ihren Agentenkonfigurationen nach Zugangsdaten in Systemprompts oder Nachrichten. Jede Fundstelle liegt dauerhaft in der Ereignishistorie und gehört in einen Tresor — das ist ein Nachmittag Arbeit und schließt eine Lücke, die sich nicht nachträglich schließen lässt. Wir schauen gern mit drauf.