afka nutzt Analytics-Cookies, um zu sehen, wie Besucher die Website nutzen, und einen Service, der das Unternehmen identifizieren kann, für das ein Besucher arbeitet. Wir verkaufen deine Daten nicht. Lehne ab und nichts davon wird geladen.
afka führt Agenten aus, die sich mit deinen Tools verbinden und in deinem Namen handeln. Daher sind Sicherheit und Kontrolle in das Produkt integriert. Diese Seite fasst zusammen, wie wir deine Daten schützen und wie du die Kontrolle darüber behältst, was deine Agenten tun können.
afka gibt einem Unternehmen KI-Kollegen, die Arbeit in einem Chat-Kanal erhalten, diese planen, in seinen verbundenen Tools handeln und berichten. Die Antwort auf das erforderliche Vertrauen ist eine Architektur, in der das Gefährliche konstruktionsbedingt schwer zu tun ist. Drei Eigenschaften tragen das meiste Gewicht.
Das Modell sieht niemals einen Zugriffsschlüssel. Wenn ein Agent in einem verbundenen Tool handelt, hält oder sieht er niemals den Token, der die Aktion autorisiert. Er ruft das Tool nach Name auf, und ein Backend-Gateway injiziert den Zugriffsschlüssel zur Ausführungszeit auf dem Server, außerhalb des Kontexts des Modells. Ein Zugriffsschlüssel, den das Modell niemals gesehen hat, kann von ihm nicht offengelegt oder umgeleitet werden: der Schutz ist strukturell, nicht verhaltensbedingt.
Geld und irreversibler Schaden fragen immer einen benannten Menschen. Jeder Agent hat eine Autonomie-Einstellung, die der Kunde wählt, und darüber sitzen zwei unabhängige Ebenen, die er nicht senken kann. Geld, das das Konto des Kunden verlässt, und Entscheidungen, die einer Person irreversiblen Schaden zufügen, halten immer an und fragen zuerst einen benannten Menschen, egal wie der Regler eingestellt ist.
Alles wird dort geschrieben, wo es nicht bearbeitet oder gelöscht werden kann. Jede Aktion, von einem Agent oder einer Person, wird in ein Append-Only-Audit-Log im Workspace des Kunden geschrieben. Das Audit-Log kann nicht geändert oder gelöscht werden, auch nicht von afka.
Konform bedeutet, dass die Anforderung jetzt gilt und afka sie erfüllt. In Arbeit bedeutet, dass die Arbeit begonnen hat und nicht abgeschlossen ist. Geplant bedeutet, dass die Arbeit vorgesehen ist und noch nicht begonnen hat.
| Standard | Status | Was das bedeutet | Dokumentation verfügbar heute |
|---|---|---|---|
| SOC 2 Type I | In Arbeit | Die Arbeiten für die Prüfung laufen. Es gibt noch keinen Bericht, und afka behauptet nichts anderes. | Diese Seite; Anlage II der DPA; ein Fragebogen auf Anfrage. |
| SOC 2 Type II | In Arbeit | Ein Type-II-Bericht behandelt Kontrollen über einen Beobachtungszeitraum. Die Arbeiten laufen, und es gibt noch keinen Bericht. | Keine. |
| ISO/IEC 27001 | Geplant | afka hält kein Zertifikat und kein Zertifizierungsverfahren ist im Gange. | Eine Kontrollanpassung an die Anforderungen, die der Käufer benennt. |
| ISO/IEC 42001 | Geplant | afka hält kein Zertifikat für ein KI-Managementsystem und diese Arbeit hat nicht begonnen. | Abschnitte 6 und 7; die entsprechenden Einträge in Anlage II. |
| GDPR (Verordnung (EU) 2016/679) | Konform | afka ist Auftragsverarbeiter, der Kunde ist Verantwortlicher. Die DPA wird unter Standardbedingungen veröffentlicht, enthält die Verpflichtungen aus Artikel 28 vollständig und bezieht die Standardvertragsklauseln von 2021 ein. Eine Rechtsposition, keine Zertifizierung. | Die DPA und ihre Anlagen; die Datenschutzrichtlinie, die die Liste der Unterauftragsverarbeiter veröffentlicht. |
| UK GDPR und Data Protection Act 2018 | Konform | Die DPA behandelt das Vereinigte Königreich ausdrücklich und bezieht das International Data Transfer Addendum (Version B1.0) ein. | Die DPA, einschließlich ihrer Addendum-Wahlen. |
| CCPA und Datenschutzgesetze der Vereinigten Staaten | Konform | afka handelt als Dienstanbieter und verkauft oder teilt keine personenbezogenen Daten. Gleichwertige Bedingungen gelten für die Gesetze von Delaware, Virginia, Colorado, Connecticut, Texas und Oregon. | Die DPA (Bedingungen für Dienstanbieter); die Datenschutzrichtlinie. |
| Google API Services User Data Policy, einschließlich Limited Use | Konform | Nur Anmeldebereiche für den eigenen Google-Client von afka, zuzüglich des Bereichs der Google-Chat-Anwendung. Es wird kein Bereich zum Lesen von Postfächern angefordert. | Abschnitt 2.6 der DPA, der die Bereiche und Limited-Use-Verpflichtungen angibt. |
afka hält heute keinen SOC-2-Bericht eines beliebigen Typs und hält kein ISO/IEC-27001- oder ISO/IEC-42001-Zertifikat. Es gibt keine Bestätigung und keinen Bericht, der unter einer Geheimhaltungsvereinbarung verfügbar ist.
Was ein Käufer heute haben kann: die Kontrollanschreibungen auf dieser Seite; Anlage II der DPA, die angibt, wo eine Maßnahme von einem zugrunde liegenden Plattformanbieter bereitgestellt wird; eine Anpassung dieser Kontrollen an das Framework, das der Käufer benennt; die unterzeichnete DPA; und einen ausgefüllten Sicherheitsfragebogen. Schreiben Sie an support@afka.ai.
Workspaces sind in der Datenbank isoliert, nicht im Anwendungscode. Jede Mandantentabelle verfügt über Sicherheit auf Zeilenebene, die auf einen Business-Identifier-Claim basiert, den ein benutzerdefinierter Access-Token-Hook beim Anmelden in den Access-Token einfügt. Eine Abfrage mit dem Token eines Workspace kann keine Zeilen eines anderen zurückgeben, daher wird ein Anwendungsfehler nicht zu einer mandantenübergreifenden Exposition: die Grenze wird nicht von der Schicht durchgesetzt, die den Fehler hat.
Bei den Kerntabellen ist die Sicherheit auf Zeilenebene auf FORCE gesetzt und entfernt die Ausnahme, die eine gewöhnliche Richtlinie dem Tabelleneigentümer gewährt. Diese Tabellen sind tasks, runs, approvals, artefacts, das Audit-Log, das Credit-Ledger, connectors, workspace skills, agent watch data und proactive cards.
Die Mandantenisolation wird automatisch überprüft, bevor eine Änderung freigegeben wird.
Als Verteidigungsstrategie vertrauen serverseitige Funktionen niemals auf einen vom Client bereitgestellten Workspace-Identifier: Sie lösen den Mandanten aus dem verifizierten Token erneut auf.
Verbindungsreferenzen für verbundene Konten werden im Geheimnis-Tresor der verwalteten Datenbankplattform gespeichert: niemals in Umgebungsdateien, niemals im Frontend-Bundle, niemals in einer Build-Variable, die den Browser erreicht.
Für einen Connector, der von der Connector-Plattform verwaltet wird, wird die OAuth-Berechtigung selbst von dieser Plattform gespeichert; afka hält nur eine Referenz dazu. Das Trennen der Verbindung widerruft daher das Konto an der Quelle durch einen API-Aufruf an die Plattform, und afka schreibt eine Audit-Zeile, die dies dokumentiert.
API-Schlüssel werden als SHA-256-Hash gespeichert, einmal bei der Erstellung angezeigt und nie abrufbar; nur ein Präfix und die letzten vier Zeichen werden zur Anzeige beibehalten. Bereiche werden bei jedem Authentifizierungsaufruf mit den aktuellen Fähigkeiten des Erstellers neu abgeglichen, sodass ein Schlüssel nicht länger als die Berechtigungen des Erstellers bestehen kann, und der Schlüsselverwaltungsbereich kann nicht einem Schlüssel gewährt werden.
Das Modell erhält niemals eine rohe Anmeldedaten; das Backend-Tool-Gateway injiziert sie zur Ausführungszeit. Wenn ein Agent im Namen des Mitglieds handelt, das ein Tool verknüpft hat, wird das Token dieses Mitglieds pro Lieferung aus dem Tresor gelesen und der Connector postet unter dem Namen dieses Mitglieds.
Code, der von einem Sprachmodell geschrieben wird, ist ab dem Moment seiner Existenz nicht vertrauenswürdig. Er wird in einer isolierten Micro-VM mit einem Guest-Kernel pro Aufgabe ausgeführt, die nach der Ausführung zerstört und nie über Workspaces hinweg wiederverwendet wird. Jede Ausführung erhält kurzlebige begrenzte Token anstelle von langlebigen Geheimnissen.
Der Netzwerk-Egress aus der Sandbox ist standardmäßig deaktiviert.
Jede Ausführung ist durch CPU-, Speicher-, Wanduhr- und Gutschrift-Limits begrenzt.
Jeder Agent hat eine Autonomiestufe, die der Kunde festlegt und ändern kann. Bei Suggest schlägt er Arbeit vor und handelt nicht, bis ihm befohlen wird. Bei Review bereitet er eine Aktion vor und hält sie zur Genehmigung bereit. Bei Auto kann er Aktionen in den Risikoclassen ausführen, die der Kunde für ihn freigegeben hat, vorbehaltlich der nachstehenden Grenzen.
Gewöhnliche Arbeit trägt keine Risikoclassifizierung und fragt nie: Lesen, Recherchieren, Entwürfe erstellen, internen Status aktualisieren. Darüber liegen die vier Risicoclasses, die der Regler steuert: money, Geld ausgeben oder verschieben; send, Kommunikation außerhalb des Arbeitsbereichs; record, Datensätze in einem verbundenen Tool erstellen oder ändern; account, Konto- oder Arbeitsbereichseinstellungen ändern.
Über dem Regler liegt eine Reihe von Kategorien, die der Regler nicht freigeben kann. Geld, das das Kundenkonto verlässt, und Entscheidungen, die einer Person irreversiblen Schaden zufügen, fragen immer zuerst eine benannte Person. Die gesperrten Kategorien sind Rückerstattungen, Zahlungen, Auszahlungen und nachteilige Entscheidungen über eine Person mit einer benannten Aktionsliste: Verarbeitung einer Stornierung, Änderung eines Abonnements, eine Offboarding-Aktion, eine Kontoänderung, Geldausgaben. Eine zweite, unabhängige Regel deckt denselben Bereich ab: eine Geldmenge (Rückerstattungen, Gutschriften, Rabatte, Treuezuschüsse, Ausgaben, Kasse, Zahlungsbelastung und Erfassung, Abonnementänderungen, Werbeumverteilung) und eine Personenmenge (gesendete oder weitergeleitet Angebote, Einstellungsempfehlungen, Offboarding, alles als nachteilig gekennzeichnet).
Der Mechanismus ist eine Grenze und keine Untersagung. Eine gesperrte Aktion wird auf die Review-Stufe erzwungen, so dass eine benannte Person sie genehmigen muss, bevor sie ausgeführt wird, und der Genehmiger, die Aktion und das Ziel werden in das Audit-Protokoll geschrieben. Wenn niemand genehmigt, wird sie nicht ausgeführt. Eine Aktion, die das System nicht sicher klassifizieren kann, wird als gesperrt behandelt.
Die Lockerung der Autonomie ist dem Arbeitsbereichseigentümer vorbehalten, so dass eine Änderung der Risikosituation einer benannten Person zugeordnet werden kann. Ausstehende Genehmigungen verfallen nach einer Gültigkeitsdauer und werden gelöscht. Ausgabengrenzen werden über eine in Schritte aufgeteilte Aktion summiert, so dass eine Zerlegung nicht unter eine Grenze fällt. Jeder laufende Agent kann aus der Anwendung gestoppt werden.
Jede Aktion, die von einem Agenten oder einer Person durchgeführt wird, wird in ein unveränderliches Audit-Protokoll im Arbeitsbereich des Kunden geschrieben. Das Protokoll kann nicht geändert oder gelöscht werden, auch nicht von afka: Ein Versuch, einen Eintrag zu ändern oder zu löschen, wird abgelehnt.
Eine Zeile enthält den Akteur, die Aktion, das Ziel, den Zeitstempel, die Kreditkosten, die Run-Kennung, einen Verweis auf die erforderliche Genehmigung, falls vorhanden, und ob der Initiator ein Mensch oder ein Agent war.
Kunden exportieren das Protokoll selbst. Eine serverseitige Funktion überprüft das Token des Aufrufers, löst den Mandanten auf dem Server auf und prüft eine benannte Exportfunktion: Eigentümer und Administratoren verfügen immer darüber, ein Mitglied nur, wenn es gewährt wurde. Die Formate sind CSV und NDJSON, letzteres für ein System zur Verwaltung von Sicherheitsinformationen und Ereignissen. Der Export schreibt seine eigene Zeile in das Protokoll.
Der Export ist nicht kryptographisch signiert oder beglaubigt, und ein Kunde sollte einen Export gegenüber einem Gericht, einer Behörde oder einer Gegenpartei nicht als manipulationssicher darstellen.
Wenn die Meeting-Funktionalität aktiviert ist, tritt ein benannter Assistant dem Anruf als sichtbarer Teilnehmer bei und kündigt sich beim Beitreten an. afka tritt einem Anruf nicht verdeckt bei und bietet keinen Modus, in dem es dies täte.
afka transkribiert; afka zeichnet kein Video auf. Es gibt keine Videoaufzeichnung und keine Aufzeichnungsbibliothek. Was beibehalten wird, ist ein Transkript und abgeleitete Ergebnisse: Zusammenfassungen, Maßnahmen und Folgemaßnahmen.
Meeting-Transkripte und die rohen Spracherkennungsmuster werden in einem rollierenden Fenster von dreißig (30) Tagen durch einen automatischen täglichen Durchlauf gelöscht. Im gleichen Fenster werden die gespeicherte Eingabeaufforderung einer Aufgabe und der gespeicherte Kontext einer Genehmigung geleert, während die Datensätze selbst beibehalten werden. Sprachmuster befinden sich in einer Tabelle, die weder die anonyme noch die authentifizierte Datenbankrolle lesen kann.
Das Audit-Protokoll enthält keinen Sprach- oder Nachrichteninhalt.
Ein geplanter Beitritt kann vor dem Anruf storniert werden; der Assistant kann während eines Anrufs entfernt werden, was die Transkription beendet; und ein Anruf mit seinem Transkript kann danach gelöscht werden, eine Löschung, die das Produkt ablehnt, bis der Assistant entfernt wurde. Die Zustimmung liegt in der Verantwortung des Kunden: In einigen Gerichtsbarkeiten ist die Zustimmung aller Teilnehmer erforderlich. Der sich selbst ankündigende Teilnehmer ist kein Ersatz für diesen Prozess, wie in den Nutzungsbedingungen dargelegt.
afka speichert und verarbeitet Kundendaten routinemäßig in den Vereinigten Staaten. Die Anwendungsberechnung, d. h. das Anwendungs-Hosting, der Hintergrund-Worker und der Voice-Ingress laufen in den Vereinigten Staaten in der Region Oregon. Der Hot Cache, die Ratenbegrenzung und die Produktanalytik laufen ebenfalls in Regionen der Vereinigten Staaten.
Die primäre verwaltete Datenbank befindet sich in den Vereinigten Staaten in der Region East US (Nordvirginia).
afka bietet keine Datenspeicherung in der Europäischen Union an. Für Übertragungen aus dem Europäischen Wirtschaftsraum, dem Vereinigten Königreich und der Schweiz enthält die DPA die Standardvertragsklauseln und das Addendum für das Vereinigte Königreich.
Der gesamte Datenverkehr zu afka wird über TLS übertragen. Verschlüsselung im Ruhezustand wird durch die zugrunde liegenden verwalteten Datenbanken, Speicher- und Hosting-Anbieter bereitgestellt. Browser-seitige Antworten enthalten diese Header:
Eine Content-Security-Policy wird durchgesetzt. Parallel dazu wird eine strengere Richtlinie im Report-Only-Modus ausgeführt und meldet Verstöße an einen dedizierten Endpunkt, damit strengere Regeln anhand des tatsächlichen Datenverkehrs gemessen werden, bevor sie durchgesetzt werden; diese Berichte werden nach dreißig (30) Tagen gelöscht. Öffentliche Formulare werden durch eine verwaltete Bot-Erkennungs-Herausforderung am Edge geschützt.
Der Zugriff auf Produktionsplattformen wird nach dem Prinzip der minimalen Berechtigung gewährt, bei jedem Anbieter authentifiziert und widerrufen, wenn er nicht mehr erforderlich ist. Es gibt keinen routinemäßigen Zugriff auf Kundeninhalte: Ein Mitglied des afka-Personals liest Kundeninhalt von Nachrichten nicht im normalen Betrieb des Dienstes. Der Support-Zugriff ist auf das beschränkt, was die aufgeworfene Angelegenheit erfordert. Jede Person, die berechtigt ist, Kundendaten zu verarbeiten, unterliegt einer schriftlichen Vertraulichkeitsverpflichtung, die über das Ende ihrer Tätigkeit hinaus gilt.
Der Verwaltungsdatenbankschlüssel wird nur serverseitig verwendet und wird niemals dem Browser oder einer Sandbox ausgesetzt.
SAML 2.0 Single sign-on ist enthalten, basiert auf der verwalteten Authentifizierungsplattform und funktioniert mit jedem SAML 2.0 Identity Provider. Es ist an eine Unternehmensdomäne gebunden, die vor der Verwendung verifiziert werden muss, eine Domain pro Workspace.
Erzwingung, d.h. das Ausschalten der Passwort-Anmeldung für die verifizierte Domain, wird deaktiviert ausgeliefert und kann erst aktiviert werden, nachdem eine erfolgreiche Single sign-on abgeschlossen wurde, sodass die Erzwingung einen Administrator nicht aus einem Workspace sperren kann, in dem es noch nie funktioniert hat. Single sign-on ist im höchsten Self-Service-Plan und in Enterprise-Plänen verfügbar, nicht in den niedrigeren Plänen.
SCIM-Verzeichnissynchronisierung ist nicht enthalten. Es gibt keine automatisierte verzeichnisgesteuerte Bereitstellung oder Aufhebung der Bereitstellung. Das Entfernen einer Person erfolgt in der Anwendung oder, wenn die Erzwingung aktiviert ist, beim Identity Provider.
afka nutzt Kundendaten nicht zum Training von allgemeinen KI-Modellen. afka verkauft Kundendaten nicht und nutzt sie nicht für Werbung oder kontextübergreifendes Verhaltens-Profiling.
afkas Zusagen über das Verhalten seiner KI-Anbieter spiegeln die mit jedem von ihnen geltenden vertraglichen Vereinbarungen wider, und ein Anbieter kann seine Bedingungen einseitig ändern. Sollte afka feststellen, dass eine solche Änderung den Schutz von Kundendaten wesentlich verringern würde, wird es im Rahmen des Prozesses zur Änderung von Unterauftragsverarbeitern in der DPA im Voraus Mitteilung machen, was eine Frist von dreißig (30) Tagen, ein Einspruchsrecht und eine Möglichkeit zur Beendigung des betroffenen Teils des Service mit sich bringt. Die DPA verpflichtet afka auch dazu, dass seine KI-Anbieter Kundenpersonendaten nicht zum Training von allgemeinen Modellen nutzen.
afka nutzt eine kleine Anzahl von KI-Modell-Anbietern unter Vertrag: Anthropic für die primären Sprachmodelle, die immer dann verwendet werden, wenn ein Agent läuft; Moonshot als Live-Fallback-Ebene für diese Modelle; OpenAI nur für Sprache-zu-Text; Voyage AI für die Embeddings, die zum Indexieren und Abrufen von Workspace-Wissen verwendet werden; und Tavily für den Web-Research-Schritt. Diese Anbieter sind in der Liste der Unterauftragsverarbeiter aufgeführt, die in der Datenschutzrichtlinie veröffentlicht wird, die Teil der DPA ist, und eine Änderung dieser Liste wird im Voraus durch den oben beschriebenen Prozess mitgeteilt.
Wenn Sie ein Sicherheitsproblem in afka gefunden haben, teilen Sie uns dies mit. Schreiben Sie an support@afka.ai mit ausreichend Details, um es zu reproduzieren, und afka wird den Bericht bestätigen und Sie informiert halten, während er untersucht und behoben wird. afka wird einen Forscher nicht verfolgen, der in gutem Glauben meldet, den Zugriff auf oder die Zerstörung von Daten anderer Personen vermeidet und afka eine angemessene Gelegenheit gibt, das Problem zuerst zu beheben.
afka führt kein bezahltes Bug-Bounty-Programm durch. Was afka bietet, ist eine schnelle Bestätigung, eine echte Behebung und öffentliche Anerkennung, wenn Sie dies wünschen.
Schreiben Sie an support@afka.ai und afka sendet ohne Anruf und ohne Qualifizierungsprozess: die DPA unter Standardbedingungen, unterzeichnungsbereit, mit Anlage II als detailliertes Kontrollverzeichnis; eine Zuordnung der Kontrollen von afka zu dem von Ihnen genannten Framework; Ihren eigenen ausgefüllten Sicherheitsfragebogen; und eine direkte Antwort zu jeder Kontrolle auf dieser Seite.
Siehe auch die Nutzungsbedingungen, die Autonomie, Genehmigungen und Verantwortung für die Handlungen eines Agenten regeln, und die Datenschutzrichtlinie. Soweit diese Seite und die DPA abweichen, gilt die DPA.