afka utilizza cookie di analisi per vedere come i visitatori utilizzano il sito e un servizio che può identificare l'azienda per cui lavora un visitatore. Non vendiamo i tuoi dati. Rifiuta e niente di tutto ciò si carica.
afka esegue agenti che si connettono ai tuoi strumenti e agiscono per tuo conto, quindi la sicurezza e il controllo sono integrati nel prodotto. Questa pagina riassume come proteggiamo i tuoi dati e come rimani in controllo di ciò che i tuoi agenti possono fare.
afka fornisce a un'azienda colleghi AI che ricevono il lavoro in un canale di chat, lo pianificano, agiscono nei suoi strumenti connessi e riferiscono i risultati. La risposta alla fiducia che questo richiede è un'architettura in cui la cosa pericolosa è difficile da fare per costruzione. Tre proprietà portano la maggior parte di quel peso.
Il modello non vede mai una credenziale. Quando un agente agisce in uno strumento connesso non possiede né vede il token che autorizza l'azione. Chiama lo strumento per nome, e un gateway backend inietta la credenziale al momento dell'esecuzione, sul server, al di fuori del contesto del modello. Una credenziale che il modello non ha mai visto non può essere divulgata o reindirizzata da esso: la protezione è strutturale, non comportamentale.
Il denaro e il danno irreversibile chiedono sempre a una persona nominata. Ogni agente ha un'impostazione di autonomia che il cliente sceglie, e al di sopra di essa si trovano due piani indipendenti che non può abbassare. Il denaro che esce dal conto del cliente, e le decisioni che causano a una persona un danno irreversibile, si fermano sempre e chiedono prima a una persona nominata, qualunque sia l'impostazione.
Tutto è scritto dove non può essere modificato o eliminato. Ogni azione, di un agente o di una persona, è scritta in un registro di audit append-only nello spazio di lavoro del cliente. Il registro di audit non può essere alterato o eliminato, nemmeno da afka.
Conforme significa che il requisito è in vigore ora e afka lo rispetta. In corso significa che il lavoro è iniziato e non è terminato. Pianificato significa che il lavoro è programmato e non è ancora iniziato.
| Standard | Stato | Cosa significa | Documentazione disponibile oggi |
|---|---|---|---|
| SOC 2 Type I | In corso | Il lavoro verso l'esame è in corso. Non esiste ancora alcuna relazione, e afka non ne dichiara alcuna. | Questa pagina; Allegato II del DPA; un questionario su richiesta. |
| SOC 2 Type II | In corso | Una relazione di Type II copre i controlli su un periodo di osservazione. Il lavoro è in corso e non esiste ancora alcuna relazione. | Nessuno. |
| ISO/IEC 27001 | Pianificato | afka non possiede alcun certificato e nessun processo di certificazione è in corso. | Una mappatura dei controlli rispetto ai requisiti indicati dall'acquirente. |
| ISO/IEC 42001 | Pianificato | afka non possiede alcun certificato per un sistema di gestione dell'IA e quel lavoro non è ancora iniziato. | Sezioni 6 e 7; le corrispondenti voci dell'Allegato II. |
| GDPR (Regolamento (UE) 2016/679) | Conforme | afka è responsabile del trattamento, il cliente è titolare del trattamento. Il DPA è pubblicato su termini standard, contiene integralmente gli obblighi dell'Articolo 28 e incorpora le Clausole Contrattuali Standard del 2021. Una posizione legale, non una certificazione. | Il DPA e i suoi Allegati; la Politica sulla Privacy, che pubblica l'elenco dei sub-responsabili del trattamento. |
| UK GDPR e il Data Protection Act 2018 | Conforme | Il DPA copre il Regno Unito espressamente e incorpora l'International Data Transfer Addendum (versione B1.0). | Il DPA, incluso il suo Addendum. |
| CCPA e le leggi sulla privacy dei singoli stati degli Stati Uniti | Conforme | afka agisce come fornitore di servizi e non vende o condivide informazioni personali. Termini equivalenti coprono gli statuti del Delaware, Virginia, Colorado, Connecticut, Texas e Oregon. | Il DPA (termini del fornitore di servizi); la Politica sulla Privacy. |
| Google API Services User Data Policy, incluso Limited Use | Conforme | Solo ambiti di accesso per il client Google di afka, più l'ambito dell'applicazione Google Chat. Non viene richiesto alcun ambito di lettura della casella di posta. | Sezione 2.6 del DPA, che indica gli ambiti e gli impegni di Limited Use. |
afka non possiede oggi una relazione SOC 2 di alcun tipo, e non possiede un certificato ISO/IEC 27001 o ISO/IEC 42001. Non esiste alcuna attestazione e nessuna relazione disponibile secondo un accordo di non divulgazione.
Ciò che un acquirente può avere oggi: le descrizioni dei controlli su questa pagina; Allegato II del DPA, che indica dove una misura è fornita da un fornitore di piattaforma sottostante; una mappatura di tali controlli al framework indicato dall'acquirente; il DPA, firmato; e un questionario di sicurezza completato. Scrivi a support@afka.ai.
I workspace sono isolati nel database, non nel codice dell'applicazione. Ogni tabella tenant dispone di sicurezza a livello di riga basata su un'attestazione di identificatore aziendale che un hook di token di accesso personalizzato inserisce nel token di accesso al momento dell'accesso. Una query effettuata con il token di un workspace non può restituire le righe di un altro, quindi un bug dell'applicazione non diventa un'esposizione tra tenant: il confine non è applicato dal livello che contiene il bug.
Sulle tabelle principali, la sicurezza a livello di riga è impostata su FORCE, rimuovendo l'esenzione che una policy ordinaria concede al proprietario della tabella. Queste tabelle sono tasks, runs, approvals, artefacts, il log di audit, il ledger di credito, connectors, workspace skills, agent watch data e proactive cards.
L'isolamento dei tenant è verificato automaticamente prima di qualsiasi rilascio di modifiche.
Come difesa in profondità, le funzioni lato server non si fidano mai di un identificatore di workspace fornito dal client: ri-risolvono il tenant dal token verificato.
I riferimenti di connessione per gli account connessi sono conservati nel vault dei segreti della piattaforma di database gestita: mai in file di ambiente, mai nel bundle frontend, mai in una variabile di build che raggiunge il browser.
Per un connettore gestito dalla piattaforma del connettore, la concessione OAuth stessa è tenuta da quella piattaforma; afka tiene solo un riferimento ad essa. La disconnessione quindi revoca l'account all'origine, tramite una chiamata API alla piattaforma, e afka scrive una riga di audit registrandola.
Le chiavi API sono archiviate come hash SHA-256, mostrate una sola volta al momento della creazione e mai recuperabili; solo un prefisso e gli ultimi quattro caratteri vengono conservati, per la visualizzazione. Gli ambiti vengono reincrociati con le capacità live del creatore ad ogni chiamata di autenticazione, quindi una chiave non può sopravvivere alle autorizzazioni del suo creatore, e l'ambito di gestione delle chiavi non può essere concesso a una chiave.
Il modello non riceve mai una credenziale grezza; il gateway dello strumento backend la inietta al momento dell'esecuzione. Quando un agente agisce per conto del membro che ha collegato uno strumento, il token di quel membro viene letto dal vault per ogni consegna e il connettore pubblica con il nome di quel membro.
Il codice scritto da un modello linguistico non è affidabile dal momento della sua creazione. Viene eseguito in una microVM isolata con un kernel guest per attività, distrutto dopo l'esecuzione e mai riutilizzato tra gli spazi di lavoro. Ogni esecuzione riceve token con ambito a breve termine anziché segreti a lungo termine.
L'uscita di rete dalla sandbox è negata per impostazione predefinita.
Ogni esecuzione è limitata da limiti di CPU, memoria, tempo reale e crediti.
Ogni agente ha un livello di autonomia che il cliente imposta e può modificare. A Suggest propone il lavoro e non agisce fino a quando non gli viene detto di farlo. A Review prepara un'azione e la trattiene in attesa di approvazione. A Auto può eseguire azioni nelle classi di rischio che il cliente ha rilasciato ad esso, soggetto ai limiti di seguito.
Il lavoro ordinario non comporta alcuna classificazione di rischio e non chiede mai: lettura, ricerca, redazione, aggiornamento dello stato interno. Al di sopra di esso si trovano le quattro classi di rischio che il selettore governa: money, spesa o trasferimento di denaro; send, comunicazione al di fuori dell'area di lavoro; record, creazione o alterazione di record in uno strumento connesso; account, modifica delle impostazioni dell'account o dell'area di lavoro.
Al di sopra del selettore si trova un insieme di categorie che il selettore non può rilasciare. Il denaro che esce dall'account del cliente e le decisioni che causano un danno irreversibile a una persona chiedono sempre prima a una persona nominata. Le categorie controllate sono rimborsi, pagamenti, versamenti e decisioni avverse su una persona, con un elenco di azioni nominato: elaborazione di un annullamento, modifica di un abbonamento, un'azione di offboarding, una modifica dell'account, spesa di denaro. Una seconda regola indipendente copre lo stesso terreno: un insieme di denaro (rimborsi, crediti, sconti, concessioni di fedeltà, spesa, checkout, addebito e acquisizione di pagamento, modifiche dell'abbonamento, riallocazione pubblicitaria) e un insieme di persone (offerte inviate o instradate, raccomandazioni di assunzione, offboarding, qualsiasi cosa contrassegnata come avversa).
Il meccanismo è un limite piuttosto che un divieto. Un'azione controllata è forzata al livello Review, quindi una persona nominata deve approvarla prima che venga eseguita, e l'approvatore, l'azione e il target vengono scritti nel registro di audit. Se nessuno approva, non viene eseguita. Un'azione che il sistema non può classificare con sicurezza è trattata come controllata.
L'allentamento dell'autonomia è riservato al proprietario dell'area di lavoro, quindi una modifica della postura di rischio è attribuibile a una persona nominata. Le approvazioni in sospeso scadono su un time to live e vengono eliminate. I limiti di spesa sono sommati su un'azione suddivisa in passaggi, quindi la scomposizione non passa sotto un limite. Qualsiasi agente in esecuzione può essere arrestato dall'applicazione.
Ogni azione intrapresa da un agente o da una persona viene scritta in un registro di audit di sola aggiunta nello spazio di lavoro del cliente. Il registro non può essere alterato o eliminato, nemmeno da afka: un tentativo di alterare o eliminare una voce viene rifiutato.
Una riga contiene l'attore, l'azione, l'oggetto, il timestamp, il costo in crediti, l'identificatore dell'esecuzione, un riferimento all'approvazione autorizzante ove richiesta, e se l'iniziatore era un umano o un agente.
I clienti esportano il registro autonomamente. Una funzione lato server verifica il token del chiamante, risolve il tenant sul server e controlla una capacità di esportazione denominata: i proprietari e gli amministratori la possiedono sempre, un membro solo se concessa. I formati sono CSV e NDJSON, quest'ultimo per un sistema di gestione delle informazioni e degli eventi di sicurezza. L'esportazione scrive la propria riga nel registro.
L'esportazione non è firmata crittograficamente o autenticata da un notaio, e un cliente non dovrebbe rappresentare un'esportazione a un tribunale, un'autorità di regolamentazione o una controparte come a prova di manomissione.
Quando la funzionalità di riunione è abilitata, un assistente denominato si unisce alla chiamata come partecipante visibile e si annuncia al momento dell'accesso. afka non si unisce a una chiamata in modo nascosto e non offre alcuna modalità in cui lo farebbe.
afka trascrive; afka non registra video. Non c'è registrazione video e nessuna libreria di registrazioni. Ciò che viene conservato è una trascrizione e i risultati derivati: riassunti, azioni e lavoro di follow-up.
Le trascrizioni delle riunioni e i campioni grezzi del riconoscimento vocale vengono eliminati su una finestra mobile di trenta (30) giorni da una pulizia automatica giornaliera. Nella stessa finestra il prompt memorizzato di un'attività e il contesto memorizzato di un'approvazione vengono svuotati mentre i record stessi vengono conservati. I campioni vocali si trovano in una tabella che né il ruolo di database anonimo né quello autenticato possono leggere.
Il registro di audit non contiene contenuti vocali o di messaggi.
Un accesso programmato può essere annullato prima della chiamata; l'assistente può essere rimosso durante una chiamata, il che termina la trascrizione; e una chiamata con la sua trascrizione può essere eliminata successivamente, un'eliminazione che il prodotto rifiuta fino a quando l'assistente non è stato rimosso. Il consenso è responsabilità del cliente: alcune giurisdizioni richiedono il consenso di ogni partecipante. Il partecipante che si auto-annuncia non è un sostituto per quel processo, come indicato nei Termini di servizio.
afka archivia ed elabora regolarmente i dati dei clienti negli Stati Uniti. L'elaborazione dell'applicazione, ovvero l'hosting dell'applicazione, il worker di background e l'ingresso vocale, vengono eseguiti negli Stati Uniti, nella regione dichiarata come Oregon. La cache attiva, il rate limiting e l'analisi dei prodotti vengono eseguiti anche in regioni degli Stati Uniti.
Il database gestito primario si trova negli Stati Uniti, nella regione East US (Virginia del Nord).
afka non offre residenza dei dati nell'Unione Europea. Per i trasferimenti al di fuori dello Spazio economico europeo, del Regno Unito e della Svizzera, il DPA incorpora le Clausole contrattuali standard e l'Addendum del Regno Unito.
Tutto il traffico verso afka viene trasportato su TLS. La crittografia a riposo è fornita dai provider di database gestiti, archiviazione e hosting sottostanti. Le risposte rivolte al browser contengono questi header:
Una content security policy è applicata. Insieme ad essa una policy più ristretta viene eseguita in modalità report-only, segnalando le violazioni a un endpoint dedicato, in modo che le regole più ristrette vengono misurate rispetto al traffico reale prima dell'applicazione; questi report vengono eliminati ogni trenta (30) giorni. I moduli pubblici sono protetti da una sfida di rilevamento bot gestita al perimetro.
L'accesso alle piattaforme di produzione è concesso secondo il principio del privilegio minimo, autenticato presso ogni provider, e revocato quando non più necessario. Non c'è accesso ordinario ai contenuti dei clienti: un membro del personale di afka non legge il contenuto dei messaggi dei clienti nel corso ordinario della gestione del servizio. L'accesso al supporto è limitato a quanto richiesto dalla questione sollevata. Ogni persona autorizzata a elaborare i dati dei clienti è soggetta a un obbligo di riservatezza scritto che sopravvive alla fine del suo rapporto.
La chiave del database amministrativo è utilizzata solo lato server e non è mai esposta al browser o a una sandbox.
Il single sign-on SAML 2.0 è fornito, costruito sulla piattaforma di autenticazione gestita, e funziona con qualsiasi provider di identità SAML 2.0. È associato a un dominio aziendale che deve essere verificato prima dell'uso, un dominio per workspace.
L'applicazione, ovvero disattivare l'accesso con password per il dominio verificato, viene fornita disabilitata e non può essere abilitata fino al completamento di un single sign-on riuscito, quindi l'applicazione non può bloccare un amministratore dall'accesso a un workspace in cui non ha mai funzionato. Il single sign-on è disponibile sul piano self-serve più alto e sui piani enterprise, non sui piani inferiori.
La sincronizzazione della directory SCIM non è integrata. Non esiste provisioning o deprovisioning automatico basato sulla directory. La rimozione di una persona viene eseguita nell'applicazione o, dove l'applicazione è abilitata, presso il provider di identità.
afka non utilizza i dati dei clienti per addestrare modelli di AI per uso generale. afka non vende i dati dei clienti e non li utilizza per la pubblicità o la profilazione comportamentale tra contesti diversi.
Gli impegni di afka riguardanti il comportamento dei suoi provider di AI riflettono gli accordi contrattuali in vigore con ciascuno di essi, e un provider può modificare unilateralmente i suoi termini. Se afka viene a conoscenza di una modifica che ridurrebbe materialmente la protezione applicabile ai dati dei clienti, fornirà un preavviso attraverso il processo di modifica dei sub-processori nella DPA, che prevede un periodo di preavviso di trenta (30) giorni, un diritto di obiezione e una strada per terminare la parte interessata del servizio. La DPA vincola inoltre afka a richiedere che i suoi provider di AI non utilizzino i dati personali dei clienti per addestrare modelli per uso generale.
afka utilizza un numero limitato di provider di modelli di AI in base a contratto: Anthropic per i modelli di linguaggio primari, utilizzati ogni volta che un agente viene eseguito; Moonshot come livello di fallback live per tali modelli; OpenAI solo per la conversione da voce a testo; Voyage AI per gli embedding utilizzati per indicizzare e recuperare le conoscenze dell'area di lavoro; e Tavily per il passaggio di ricerca web. Questi provider sono elencati nell'elenco dei sub-processori pubblicato nella Privacy Policy, che fa parte della DPA, e una modifica a tale elenco viene notificata in anticipo attraverso il processo descritto sopra.
Se hai trovato un problema di sicurezza in afka, per favore comunicacelo. Scrivi a support@afka.ai con dettagli sufficienti per riprodurlo, e afka riconoscerà la segnalazione e ti terrà informato mentre viene investigato e risolto. afka non perseguirà un ricercatore che segnala in buona fede, evita di accedere o distruggere i dati di altre persone, e dà ad afka una ragionevole opportunità di risolvere il problema prima.
afka non gestisce un programma di bug bounty retribuito. Quello che afka offre è un riconoscimento veloce, una vera correzione, e credito pubblico se lo desideri.
Scrivi a support@afka.ai e afka invierà, senza una chiamata e senza un processo di qualificazione: il DPA su termini standard, pronto per la firma, con l'Allegato II come inventario dei controlli dettagliato; una mappatura dei controlli di afka a qualsiasi framework tu nomini; il tuo questionario di sicurezza completato; e una risposta diretta su qualsiasi controllo in questa pagina.
Vedi anche i Termini di Servizio, che disciplinano l'autonomia, le approvazioni e la responsabilità per le azioni di un agente, e l'Informativa sulla Privacy. Laddove questa pagina e il DPA differiscono, il DPA prevale.