Wie eine Ausführung isoliert wird, wie Zugangsdaten von Agenten ferngehalten werden, was wie lange gespeichert wird und wie Sie ein Problem melden. Diese Seite beschreibt den gehosteten Dienst unter ephemer.al. Eine selbst gehostete Installation betreibt dieselbe Engine auf Ihrer eigenen Infrastruktur; Aufbewahrung und Anbieter bestimmen dort Sie. Siehe Self-Hosting.
Isolation
| Grenze | So funktioniert es |
|---|---|
| Eine Maschine pro Ausführung | Jede Ausführung startet ihre eigene microVM aus einem festen Worker-Image. Endet die Ausführung, wird die Maschine zerstört, und der Datensatz der Ausführung zeigt, wann dies bestätigt wurde. |
| Lebensdauer | Die Maschine lebt höchstens so lange wie das Timeout der Ausführung plus eine Minute (das Timeout beträgt 1 bis 3.600 Sekunden). Abbrechen oder ein Timeout zerstört sie. |
| Netzwerk | Ein Worker hat keinen direkten Internetzugang. Alles nach außen läuft über eine Verbindung oder, falls die Ausführung ihn hat, über den Webzugriff, beides von Ephemeral geprüft. |
| Shell | Standardmäßig an. Mit shell auf false kann der Agent nur seine Dateien lesen und die Tools nutzen, die Sie ihm geben. Ist sie an, kann der Agent Befehle ausführen und in seinem Arbeitsverzeichnis Dateien schreiben, in einer Maschine ohne Netzwerk und ohne Ihre Zugangsdaten. |
| Nichts wird übernommen | Das Arbeitsverzeichnis verschwindet mit der Maschine. Eingebundene Dateien sind schreibgeschützt. Weder Maschine noch Datei noch Prozess wird zwischen Ausführungen oder zwischen Organisationen geteilt. |
Zugangsdaten
- Keine Zugangsdaten gelangen in die Maschine. Modellaufrufe und Verbindungsanfragen laufen über Ephemeral mit einem Token, das nur für diese Ausführung gilt und nur, solange sie läuft. Dem Worker werden Name, Typ, Tools und Anweisungen jeder Verbindung mitgeteilt, nie ihre URL oder Geheimnisse.
- Erlaubte Methoden und Tools. Ephemeral prüft jeden Aufruf gegen die Freigabe der Ausführung:
allowed_methodsbei HTTP-Verbindungen,allowed_toolsbei MCP-Servern. Eine Ausführung kann eine gespeicherte Verbindung einschränken, aber nie erweitern. - Aus Antworten entfernt. Ephemeral entfernt die genauen Werte der Zugangsdaten der Verbindungen einer Ausführung aus Antworten, Ereignissen und Ausgabe, bevor sie den Agenten oder das Protokoll erreichen. Erfasst werden die Werte selbst, nicht umgewandelte Kopien davon.
- Verschlüsselt gespeichert. Definitionen von Ausführungen samt Inline-Zugangsdaten und gespeicherte Verbindungseinstellungen samt OAuth-Tokens werden verschlüsselt, bevor sie gespeichert werden. API-Schlüssel und Sitzungs-Tokens werden nur als Hashes gespeichert.
- Apps, die Sie autorisieren. Eine Anwendung, die sich mit OAuth anmeldet, erhält für eine Organisation ein Zugriffstoken mit einer Stunde Gültigkeit und ein rotierendes Refresh-Token, nie Ihr Passwort. Beide werden nur als Hashes gespeichert, und Sie können jede autorisierte App auf Ihrer Kontoseite einsehen und widerrufen.
Webzugriff
- Aus, solange die Ausführung ihn nicht anfordert. Anfragen sendet Ephemeral, nicht die Maschine, als EphemeralBot, mit einer Anfrage-ID und veröffentlichten Adressen, damit Websitebetreiber ihn erkennen und blockieren können; er beachtet robots.txt-Regeln, die an ihn gerichtet sind.
- Erreichbar sind nur öffentliche Adressen. Private und reservierte Adressen werden abgelehnt, Weiterleitungen werden erneut geprüft, und eine Allowlist beschränkt eine Ausführung auf die von Ihnen genannten Sites.
- Jede Anfrage wird auf Angriffe, Spam und abfließende Daten geprüft, und jede Ausführung hat ein Anfragelimit. Alle Regeln stehen unter Webzugriff.
Budgets sind eine feste Grenze
Bevor eine Ausführung startet, reserviert Ephemeral ihr gesamtes Budget aus Ihrem Guthaben. Ein Modellaufruf oder eine Webanfrage, die die Ausführung über das Budget bringen könnte, wird vor dem Senden abgelehnt, und die nicht genutzte Reservierung wird anschließend freigegeben. Eine Ausführung kann nicht mehr als ihr max_cost_micros ausgeben. Siehe Budgets und Abrechnung.
Was gespeichert wird und wie lange
| Daten | Aufbewahrung |
|---|---|
| Ausführungen: Definition, Ausgabe, Ereignisse | 30 Tage nach Ende der Ausführung, dann gelöscht. Länger nur, solange Abrechnung, Callback-Zustellung oder Aufräumen der Maschine noch ausstehen. |
| Ausführungen mit Null-Datenspeicherung | Ausführungs-ID, Organisation, Status, Zeitstempel, Kosten und Nutzung sowie eine allgemeine Fehlerkategorie. Ereignisse werden wenige Minuten nach Ende der Ausführung gelöscht. Die Ausgabe wird einmal zurückgegeben und spätestens nach einer Stunde gelöscht. Die Definition wird nicht gespeichert. |
| Hochgeladene Dateien | Bis Sie sie löschen. Eine gelöschte oder ersetzte Datei kann bis zu 30 Tage brauchen, bis sie aus dem Speicher entfernt ist. |
| Backups | 30 Tage. Eine aus dem Dienst gelöschte Ausführung kann bis zu 30 weitere Tage in Backups bleiben. Ereignisse und Ausgaben mit Null-Datenspeicherung sind nie in einem Backup. |
| Konto- und Abrechnungsdaten | Wie in der Datenschutzerklärung beschrieben. Registrierungen, deren E-Mail-Adresse nie bestätigt wird, werden nach sieben Tagen gelöscht. |
Null-Datenspeicherung ist eine Einstellung einer Ausführung oder eines Workflows: zero_data_retention: true. Im gehosteten Dienst kosten solche Ausführungen 10 % mehr, was auf das Budget angerechnet wird. Siehe Ausführungen.
Die Daten werden in Japan gespeichert und bei der Übertragung und im Ruhezustand verschlüsselt.
Modellanbieter
Modellaufrufe werden mit den Inhalten, die der Agent in ihnen mitschickt, an den Anbieter gesendet, der das von Ihnen gewählte Modell bereitstellt.
- Eine Ausführung mit Null-Datenspeicherung nutzt nur Endpunkte, die die Anfrage weder speichern noch zum Training verwenden. Hat ein Modell keinen, wird die Ausführung mit
400abgelehnt, bevor etwas reserviert wird. Web-Sicherheitsprüfungen und Suchen nutzen bei jeder Ausführung Endpunkte, die keine Daten erheben. - Andere Ausführungen unterliegen der eigenen Datenrichtlinie des Modellanbieters. Nutzen Sie für sensible Arbeit die Null-Datenspeicherung.
Wir nutzen eine kleine Zahl von Dienstleistern, um den Dienst zu hosten und zu schützen, Zahlungen abzuwickeln (Stripe), E-Mails zu senden und Modelle auszuführen. Jeder erhält nur, was er für seine Aufgabe braucht. Die Datenschutzerklärung beschreibt sie.
Unser Zugriff
Mitarbeiter von Ephemeral greifen auf Kundendaten nur zu, um Support zu leisten, den Dienst sicher zu halten und die Abrechnung zu erledigen. Der Zugriff erfordert starke Authentifizierung und wird protokolliert, und Ausführungen mit Null-Datenspeicherung hinterlassen keine Inhalte, die sich ansehen ließen.
Kontosicherheit
| Bereich | So funktioniert es |
|---|---|
| E-Mail-Bestätigung | Ein Konto kann sich erst anmelden, nachdem Sie den per E-Mail gesendeten Link geöffnet haben. |
| Bots und Raten | Registrierung und Passwort-Wiederherstellung sind durch ein Captcha geschützt, wiederholte fehlgeschlagene Anmeldungen erfordern eines, und Authentifizierungsanfragen sind ratenbegrenzt. |
| Passwörter | Mindestens 12 Zeichen, nur als Hashes gespeichert. Zurücksetzen-Links funktionieren einmal und laufen nach 30 Minuten ab. Beim Zurücksetzen werden alle Sitzungen abgemeldet, beim Ändern die übrigen. |
| Sitzungen | Werden in einem sicheren HttpOnly-Cookie gehalten. Abmelden beendet die Sitzung sofort. |
| API-Schlüssel | Werden einmal angezeigt, sind sofort widerrufbar und haben die Rolle member oder admin. Ein Admin-Schlüssel kann weder Mitglieder noch Schlüssel noch die Abrechnung verwalten. Siehe Rollen und Schlüssel. |
Ein Problem melden
Melden Sie eine Sicherheitslücke über den Support im Dashboard: Erstellen Sie eine Anfrage und schreiben Sie "Security" in den Betreff. Beschreiben Sie, wie sich das Problem reproduzieren lässt, und fügen Sie keine Geheimnisse oder Daten anderer Kunden bei. Missbrauch durch EphemeralBot melden Sie über das Formular auf der EphemeralBot-Seite; dafür brauchen Sie kein Konto.