Lasă AI să acționeze.
Păstrează controlul.
Flamecloak este stratul de autorizare a acțiunilor pentru agenți AI, oameni și automatizări: lasă-i să acționeze și controlează ce au voie să facă
Disponibil la cerere. Fiecărei cereri îi răspunde un om.
Software-ul autonom are acum voie să acționeze în numele tău. Ce anume poate face se decide tot o singură dată, la intrare, pentru o sesiune întreagă. Cu Flamecloak se decide acțiune cu acțiune.
Orice organizație are API-uri care returnează lucruri de care nimeni nu ar trebui să se atingă în treacăt — exporturi în masă de date despre clienți, descărcări de documente, decizii de creditare, scrieri ireversibile. Controlul accesului spune cine poate ajunge la sistem. Nimic nu spune că această acțiune anume, chiar acum, are nevoie de un om care să zică da.
Această lipsă este vectorul clasic de risc din interior și se agravează, pentru că numărul lucrurilor care îți dețin credențialele crește.
Flamecloak se potrivește cu proxy-ul pe care îl rulezi deja — Envoy, NGINX, Traefik, gateway-ul tău de API — sau cu propriul tău cod, printr-un SDK mic. Pornește în mod de observare, fără să blocheze nimic, și în treizeci de minute îți spune care endpointuri au returnat date personale, către cine și cât. Apoi alegi cele câteva care contează, iar de atunci încolo niciuna nu se mai întâmplă până când o persoană care răspunde de ea nu a spus da.
Nimic din toate acestea nu a avut nevoie de o spargere.
Patru forme de pierdere, fiecare dintre ele dusă la capăt de un cont care avea voie să o facă.
- Export masiv, credențiale valide
- Documente descărcate unul câte unul
- Plăți eliberate nesupravegheat
- Agenți care acționează cu cheile tale
Toate patru sunt permise. Aceasta este problema.
Trei cifre, un singur raport și pagina fiecăreia.
- 48%
dintre breșe au implicat un terț, în creștere de la 30% cu un an înainte.
- 36%
dintre breșe au implicat folosirea unor credențiale furate, acolo unde cifra stă de ani de zile.
- 45%
dintre angajați folosesc acum în mod regulat AI pe dispozitivele de serviciu, în creștere de la 15% cu un an înainte.
Contul care face paguba are, de obicei, dreptul să o facă.
Cele mai multe pierderi grave de date implică acreditări reale, o permisiune valabilă și o cerere care arăta ca oricare alta din ziua respectivă. Nimeni nu a spart nimic. Cineva care avea voie a făcut-o, la o scară la care nu se gândise nimeni, iar sistemul a făcut exact ce fusese configurat să facă.
Nu este o greșeală de configurare. Permisiunile se acordă oamenilor și sistemelor, niciodată acțiunilor individuale. Cine are nevoie să citească fișe de clienți ca să-și facă treaba poate, prin același drept, să le citească pe toate deodată. Un script cu o cheie validă nu devine mai suspect a zecea mie oară când rulează. Întrebarea a fost pusă o dată, la ușă, și niciodată după aceea.
Așa că întrebarea utilă nu se pune, pentru că nu are unde. Nu "are voie contul acesta" — la asta orice sistem răspunde deja, instantaneu și corect, și nu este întrebarea. Cea care contează este dacă lucrul acesta anume, la dimensiunea aceasta, chiar acum, ar trebui făcut.
Organizații în care unele acțiuni nu trebuie să se întâmple până când o persoană anume spune da.
Agentul căruia i s-a dat un obiectiv, nu o listă
Software care își decide singur pasul următor are acum credențialele tale. I s-a spus ce să obțină, nu ce apeluri are voie să facă pentru asta, așa că limita în care lucrează este tot ce permite cheia. Nimeni nu urmărește sesiunea în care se află, pentru că nu există nicio sesiune și nicio persoană în ea.
Ținut până când o persoană a văzut care agent cere și pentru ce.
nicio obligație nu numește încă acest caz
Exportul la care nu se mai uită nimeni
Un analist extrage date despre clienți ca să răspundă la o întrebare. Aceeași permisiune care returnează un rând returnează patru sute de mii, cu date de naștere și coduri numerice personale printre ele. Nimeni nu a spart nimic și nicio regulă nu a fost încovoiată.
Ținut până când cineva responsabil vede cât de mare este.
GDPR Art. 5(1)(f) · Art. 32
Plata care nu poate fi retrasă
O sarcină programată eliberează un lot de plăți la patru dimineața. Persoana care răspunde pentru ea nu a văzut niciodată una plecând.
Ținută până când persoana care răspunde pentru ea a văzut una plecând.
controale financiare: separarea atribuțiilor
Ștergerea care trebuia să fie un singur rând
Un script de mentenanță, o clauză lipsă și un tabel în loc de o înregistrare. Diferența dintre un inconvenient și un incident este dacă a stat ceva între intenție și efect.
Ținută până când forma a ceea ce urmează să dispară este pe ecranul cuiva.
GDPR Art. 5(1)(f) · păstrare și integritate
Documentul care a plecat pe picioare
Un instrument de suport permite deschiderea unui contract după id. Nimic nu împiedică cererea id-urilor în ordine. Într-un weekend pleacă tot dosarul: acorduri semnate, pachete de identitate, scanările pe care cineva le-a trimis o dată și le-a uitat. Fiecare cerere a fost permisă și fiecăreia i s-a răspuns corect.
Ținut de prima dată când este cerut. Nu există un al zecelea pe care să-l aștepte și, deci, niciun prag sub care să te menții.
GDPR Art. 32
Contul care nu era al lor
Parola unui coleg este furată, iar târziu în noapte cineva intră cu ea și începe să citească înregistrări, câte o persoană pe rând. Până dimineață sunt sute de mii, și fiecare cerere a arătat ca o zi obișnuită de lucru. Nimic de aici nu găsește breșa prin care a intrat, iar cineva destul de răbdător încât să păstreze orele și ritmul obișnuite este încetinit, nu oprit.
Refuzat în afara orelor în care este folosit și peste ritmul obișnuit, iar cineva este anunțat în aceeași oră.
GDPR Art. 32 · Art. 33
Decizia care a schimbat viața cuiva
O decizie de eligibilitate este eliberată fără nicio persoană pe ea. O linie de credit, o cerere de daună, un loc pe o listă. Este corectă cât de des este corect modelul, iar persoana căreia i s-a întâmplat nu are pe cine să întrebe, pentru că nimeni nu a decis. Ce este ținut aici este eliberarea, nu judecata: înregistrarea spune că o persoană anume a răspuns, niciodată că răspunsul a fost corect.
Ținută până când o persoană anume a răspuns, iar înregistrarea spune cine.
GDPR Art. 22
Unde stă și ce semnează.
Rulează în calea pe care o ia cererea, în fața sistemelor pe care le protejează — rulat de noi sau în propria ta rețea. Începe în modul de observare, fără să țină nimic, și raportează ce se cere de fapt.
Privește înainte să țină ceva.
Primul lucru pe care îl primești este o descriere a propriului trafic: care endpoint-uri returnează cel mai mult, care returnează date personale și cine le apelează. De acolo decizi ce merită ținut, nu dintr-o listă scrisă de noi.
Apoi decide o persoană, iar registrul spune care.
O acțiune ținută se oprește și nu ajunge niciodată la sistemele tale până când cineva îndreptățit să o autorizeze nu a spus da, iar registrul spune cine. Cel care răspunde vede din cerere atât cât alegi să îi arăți, așa că un da nu se dă pe nevăzute.
| endpoint | apeluri | rânduri returnate | date personale | apelanți |
|---|---|---|---|---|
| GET /v1/invoices | 8.417 | 412.006 | 1 | 22 |
| GET /documents/{id} | 22.940 | 22.940 | 3 | 4 |
| DELETE /records | 94 | 1.890 | 2 | 5 |
| GET /v1/customers?limit= | 6 | 2.400.000 | 4 | 1 |
| POST /payments/runs/{id}/release | 31 | 31 | 0 | 3 |
| GET /v1/customers/{id} | 1.204 | 1.204 | 4 | 9 |
Două căi: în fața API-ului tău sau în propriul tău cod.
Proxy-ul reține apelurile HTTP care trec deja printr-un proxy. SDK-ul reține tot restul: un job în fundal, un worker de coadă, apelul unui agent către un instrument, o plată care nu atinge niciodată o rută de-a ta. Amândouă întreabă aceleași persoane și scriu în același registru.
În fața API-ului tău
Pentru apelurile care trec deja printr-un proxy sau un gateway de API. Un apel reținut se oprește acolo și nu ajunge la sistemele tale până nu spune da o persoană. API-ul tău nu se schimbă: cel care apelează pur și simplu așteaptă răspunsul, iar un singur tag de script sau SDK-ul se ocupă de așteptare în locul lui.
În propriul tău cod
Pentru tot ce un proxy nu vede niciodată. Codul tău pune o întrebare înainte să acționeze și face acțiunea doar când răspunsul este da. Nu ai de adăugat nicio rută și nimic de schimbat în rețea.
Nicio schimbare în infrastructură.
Un pachet și un apel, acolo unde codul tău decide deja să acționeze. Fără proxy, fără rută, fără bloc nginx.
Acțiuni cu nume, fiecare cu oamenii ei.
refund, payout, export: fiecare are regula ei, aprobatorii ei și ordinea în care sunt întrebați, stabilite în panoul tău și semnate cu o passkey înainte să intre în vigoare.
Reguli pe valorile trimise de codul tău.
O rambursare de peste 500 așteaptă o persoană, iar una mai mică merge mai departe imediat. Regula citește suma pe care o trimite codul tău, așa că tu decizi ce merită timpul unui om.
Acoperă și ce nu are un apel HTTP.
Sarcinile programate, cozile și apelurile unui agent către instrumente sunt reținute la fel ca un apel de API și ajung în același registru.
Alături de proxy.
Un cont le poate folosi pe amândouă: proxy-ul în fața API-ului și SDK-ul în workerii din spatele lui.
Un răspuns clar când nu ne poate contacta.
Cât timp nu putem fi contactați, acțiunile pe care doar le urmărești merg mai departe, iar cele care au nevoie de o persoană sau sunt interzise sunt refuzate, nu lăsate să treacă.
Un apel înainte ca acțiunea să ruleze
npm install flamecloak-sdk
import { Flamecloak } from 'flamecloak-sdk';
const flamecloak = new Flamecloak(process.env.FLAMECLOAK_KEY);
const decision = await flamecloak.authorize({
action: 'refund',
parameters: { amount },
});
if (decision.allowed) {
// Do it here, with decision.decisionId as its idempotency key.
}JavaScript și TypeScript, Python și PHP. Pachetele sunt publice; cheia de care au nevoie vine cu Flamecloak, care este disponibil la cerere. Răspunsul poate veni și printr-un webhook, în loc de așteptare.
Patru lucruri pentru care vom răspunde.
Nimic din toate acestea nu poate fi verificat încă, pentru că nu există nimic de rulat. Când va exista, pagina aceasta o va spune și se va schimba.
Rulat de noi sau în propria ta rețea.
Cele mai multe echipe ne lasă pe noi să îl rulăm. Echipele care nu pot trimite trafic prin altcineva îl rulează în propria infrastructură, în fața sistemelor pe care le protejează, fără nicio legătură activă cu noi și fără vreun cont la noi a cărui indisponibilitate să le oprească activitatea. Oricum ar fi, nu păstrăm nicio copie a traficului tău în afară de ce alegi să le arăți celor care aprobă, cât timp alegi, iar registrul îți aparține.
Fiecare decizie lasă o înregistrare pe care o poți verifica fără noi.
Cine a cerut, ce anume urma să se întâmple, cine avea dreptul să răspundă, cine a răspuns și când. Înregistrarea este rezistentă la modificări, iar un auditor poate verifica întreaga succesiune independent — cu un instrument care nu ne contactează niciodată și nu are nevoie de permisiunea noastră.
- cine a cerut
- svc-reporting (script), în numele a.dumitru
- ce urma să se întâmple
- un export în masă de date despre clienți · 400.000 de rânduri
- cine era îndreptățit
- responsabil cu protecția datelor, șef suport, CTO
- cine a răspuns
- M. Ceban · confirmat pe propriul dispozitiv
- când
- 2026-03-11 09:41:57 UTC
- integritate
- orice modificare ulterioară poate fi detectată
Nu decide niciodată. Decide o persoană anume.
Nu există niciun model aici și niciun scor. Gateway-ul stabilește care oameni au efectiv dreptul să autorizeze această acțiune anume și pune întrebarea unuia dintre ei. Judecata le aparține, răspunderea le aparține, iar înregistrarea spune cine dintre ei a fost.
Unitatea este acțiunea, nu sesiunea.
Controlul accesului decide cine poate fi în încăpere. Acesta decide ce se poate întâmpla cât timp este acolo — acest export, la această dimensiune, chiar acum. Pune întrebarea pe care controalele tale actuale o pun o dată, la ușă, și niciodată după aceea.
Când un singur da nu ajunge.
Unele acțiuni merită atenția mai multor oameni, iar unele apeluri se trădează prin momentul în care vin sau prin câte vin, nu prin ce cer.
Mai mulți oameni, nu unul.
O acțiune poate avea nevoie de mai mult de un da: de la toți cei pe care îi numești sau de la câți dintre ei alegi. Un telefon furat sau un cont împrumutat nu o poate aproba singur, pentru că ceilalți tot trebuie să fie de acord, iar nimeni nu își aprobă propria cerere.
În afara orelor obișnuite, așteaptă.
Spune când este apelată de obicei o acțiune. Un apel la două noaptea, către un API apelat mereu doar ziua, ajunge la o persoană sau este refuzat, cum ai ales, în loc să treacă pentru că nu era nimeni treaz să îl vadă.
Un val brusc este oprit.
Spune câte apeluri primește de obicei o acțiune. Când un endpoint care primește câteva apeluri pe oră primește brusc mii, surplusul așteaptă o persoană sau este refuzat, în loc să treacă. Cei care aprobă sunt anunțați o dată, nu pentru fiecare apel.
De ce să îl rulezi cu noi.
Cele mai multe echipe ne lasă pe noi să îl rulăm, iar motivul nu este comoditatea. O pază e la fel de puternică precum locul în care stă.
Paza nu stă pe serverul pe care îl păzește.
Dacă cineva preia unul dintre serverele tale, deține codul și cheile lui, dar nu și poarta din fața API-ului tău. Nu o poate opri, nu îi poate slăbi regulile și nu își poate aproba propriile apeluri, pentru că nimic din toate acestea nu se întâmplă pe mașina pe care a preluat-o.
Nici cei care aprobă nu sunt pe acel server.
O aprobare vine de pe dispozitivul celui care aprobă, semnată cu o passkey a lui. Un server compromis poate întreba de câte ori vrea; nu poate răspunde în locul lor.
Registrul stă acolo unde un atacator nu îl poate modifica.
Fiecare decizie este scrisă la noi, într-un registru pe care nimic nu îl mai poate schimba după aceea. Cineva care își acoperă urmele pe serverele tale nu poate rescrie cine a aprobat ce și nici nu poate face să dispară un refuz.
În propria ta rețea, dacă ai nevoie.
Echipele care nu pot trimite trafic prin altcineva îl rulează în propria infrastructură, în fața sistemelor pe care le protejează, fără nicio legătură activă cu noi. Ținut pe mașini separate de serverele pe care le păzește, păstrează aceeași distanță față de ele.
Ce nu va face.
Nu decide nimic. Pune întrebarea în fața unei persoane; judecata este a ei și responsabilitatea la fel. Cine vă vinde judecată automată despre oameni identificați vă vinde o altă problemă, mult mai mare.
Nu știe dacă persoana a avut dreptate. Poate consemna că a fost întrebată, ce i s-a arătat și ce a răspuns. Dacă răspunsul a fost cel corect nu este ceva ce știe un program.
Nu poate vedea ce nu trece prin el. Datele scoase direct dintr-o bază de date de cineva cu acces direct nu lasă nimic de reținut, și nicio configurare nu schimbă asta. O implementare care dă o siguranță falsă este mai rea decât niciuna.
Nu se vinde de pe raft. Este disponibil la cerere: îl cereți dintr-un cont Tunnel, vă răspunde un om, iar ce primiți se stabilește împreună cu dumneavoastră. Nu există o listă de prețuri.
Lăsați o adresă pentru noutăți.
Fără newsletter, fără secvențe de e-mailuri și fără apel de vânzări. Un mesaj când se schimbă ceva ce ați vrea să știți, și puteți ieși de pe listă din orice e-mail primit.
Sau cereți acces.
Creați un cont Tunnel și cereți Flamecloak din panoul dumneavoastră. O persoană vă va contacta ca să îl configurați împreună. Cererea nu vă obligă la nimic.
Creați un contÎntrebări pe care ni le pune lumea despre asta
Pot să îl folosesc astăzi?
Da, la cerere. Creați un cont Tunnel și cereți-l din panoul dumneavoastră, iar o persoană vă va contacta ca să îl configurați împreună. Ce primiți se stabilește împreună cu dumneavoastră și nu există o listă de prețuri. Dacă nu sunteți încă pregătit, lăsați o adresă și vă scriem când avem noutăți. Niciunul nu vă ține un loc la rând, pentru că nu există niciun rând.
Cum se va implementa?
În două feluri, și le poți folosi pe amândouă. În fața API-ului: rulat de noi sau în propria ta rețea, alături de proxy-ul sau gateway-ul care stă deja în fața sistemelor tale, unde doar acțiunile pe care alegi să le reții trec prin el și nimic altceva. Sau în propriul tău cod: un SDK în JavaScript, Python sau PHP întreabă înainte ca o acțiune să ruleze, fără vreo rută de adăugat și fără vreo schimbare în rețea. Nu e de cumpărat niciun echipament. Te costă o rută sau un apel și o decizie despre ce acțiuni merită reținute.
Ce îmi va arăta înainte să rețin ceva?
Mai întâi privește și nu reține nimic. În modul de observare raportează care dintre punctele tale de acces au returnat date cu caracter personal, cui, cât de multe și cât de des, iar nicio cerere nu se comportă altfel în acest timp. Primul rezultat util este o listă de puncte de acces despre care nu știai ce returnează. Nimic nu este reținut până nu numești tu ceva de reținut.
Trebuie să treacă totul prin el?
Nu, și este construit pornind de la ideea că nu trebuie. Sunt afectate doar acțiunile pe care cineva a ales anume să le rețină; restul rămâne neatins. Un control care trebuie să stea în fața a tot este un control pe care nu îl instalează nimeni.
Îl putem folosi fără să ne atingem de proxy?
Da. SDK-ul reține o acțiune din interiorul propriului tău cod: instalezi pachetul, numești acțiunea în panoul tău și apelezi authorize() înainte ca acțiunea să ruleze. Nu ai de schimbat niciun proxy, de adăugat nicio rută și nimic în rețea. Proxy-ul este cealaltă cale, pentru apelurile HTTP care trec deja printr-unul.
Ce limbaje suportă SDK-ul?
JavaScript și TypeScript (Node 20 sau mai nou), Python și PHP: flamecloak-sdk pe npm și PyPI și flamecloak/flamecloak pe Packagist. Alte limbaje se adaugă când un client cere unul. Pachetele sunt publice; cheia de care au nevoie vine cu Flamecloak, care este disponibil la cerere.
Ce se întâmplă cu codul nostru dacă Flamecloak nu poate fi contactat?
Primește un răspuns clar. Cât timp nu putem fi contactați, o acțiune pe care doar o urmărești merge mai departe, iar una care are nevoie de o persoană sau care este interzisă este refuzată, nu lăsată să treacă. Nu se deschide niciodată de la sine pentru acțiunile pe care ai ales să le protejezi.
Pot fi folosite împreună proxy-ul și SDK-ul?
Da, în același cont: proxy-ul în fața API-ului și SDK-ul în joburile și agenții din spatele lui. O acțiune reținută este decisă la fel, oricare ar fi calea prin care a venit, de aceleași persoane, și ajunge în același registru. Panoul arată pe care dintre cele două le folosești.
Ce se întâmplă când persoana care ar trebui să aprobe nu este disponibilă?
Dreptul de a aproba aparține unui grup de oameni, nu unui singur individ, așa că indisponibil trebuie să fie adevărat despre toți înainte să fie adevărat deloc. Dacă este, acțiunea reținută nu continuă. Acesta este modul onest de a eșua și înseamnă o întârziere, nu o pierdere, pentru că cererea poate fi făcută din nou. Tot de aceea alegerea a ce se reține îți aparține, acțiune cu acțiune. Poți pune și oamenii într-o ordine, ca o decizie să nu aștepte niciodată după o singură persoană.
Ce vede cel care aprobă?
Atât cât alege organizația dumneavoastră să arate. Aplicația poate spune cine a cerut și ce se schimbă, iar cel care aprobă citește asta primul, marcat ca declarație a aplicației, pentru că Flamecloak nu o verifică. În spatele proxy-ului poate vedea și cererea însăși, element cu element, pe măsură ce le permiteți: adresa de la care a venit și aproximativ unde se află, dispozitivul și ce conținea. Nimic nu se arată până când cineva nu permite asta și nu semnează cu o passkey, iar parolele și tokenurile de autentificare nu se arată niciodată. Ce declară aplicația rămâne în registrul semnat; restul se păstrează doar cât timp alegeți. Notificările nu poartă niciodată nimic din toate acestea: un e-mail, un mesaj Telegram sau Slack și ecranul blocat al unui telefon spun doar că o decizie așteaptă.
Va încetini lucrurile?
Pentru acțiunile pe care nimeni nu a ales să le rețină, nu se schimbă nimic. Pentru o acțiune reținută, întârzierea este exact cât îi ia persoanei să răspundă, iar asta este produsul, nu un cost al lui. Vom publica întârzierea de pe calea nereținută când va exista ceva față de care să o măsurăm, nu înainte.
Este același lucru cu managementul accesului privilegiat?
Nu, și nu îl înlocuiește. Managementul accesului decide cine poate fi într-un sistem și pentru cât timp. Aici este vorba despre acțiunile individuale făcute între timp — altă unitate de autorizare. Dacă nu aveți încă management al accesului, acela este lucrul mai urgent.
Ce se întâmplă dacă serviciul vostru pică?
Nimeni nu ar trebui să accepte o companie de mărimea noastră ca punct unic de eșec în calea sa de producție, și nu ne așteptăm să o facă cineva. Dacă îl rulăm noi și serviciul nostru nu poate fi contactat, acțiunile pe care doar le urmărești merg mai departe, iar cele reținute sunt refuzate, nu lăsate să treacă: o autorizare pe care nu o poți obține nu este una pe care o ai. Dacă nicio dependență de noi nu este acceptabilă, rulează-l în propria rețea, unde nimic de-al nostru nu stă în calea traficului tău. Faptul că poate fi scos este o cerință a produsului, nu o liniștire dintr-o discuție de vânzare.
Cum este aprobat un agent AI?
Este întrebată o persoană, la fel ca pentru orice alt solicitant. Ce vede acea persoană este care agent întreabă, acțiunea exactă și domeniul pe care îl cere. Ce nu primește este un scor. Produsul nu îți va spune dacă intenția agentului pare benignă, pentru că aceasta este o judecată despre ceva ce nimeni nu poate inspecta, iar vânzarea ei ar însemna vânzarea exact a judecății automate împotriva căreia argumentează această pagină.
De ce nu spuneți cum funcționează?
Pentru că ceea ce este reținut este designul intern, nu forma implementării. Unde rulează, ce îți arată înainte să rețină ceva, ce se întâmplă când nu răspunde nimeni și cât costă cererile pe care nu le-ai reținut sunt toate pe această pagină, pentru că acestea sunt lucrurile pentru care ne-ai trage la răspundere și rămân adevărate indiferent de direcția implementării. Cum este construită reținerea este o altă întrebare, iar răspunsul la ea îi dă unui concurent designul în schimbul a nimic din ce îți trebuie ție înainte să existe ceva de încercat.
Ce anume ajunge într-o înregistrare pe care nu o poți șterge?
Înregistrarea unei acțiuni reținute păstrează forma apelului și ceea ce sistemele tale au ales să declare despre el — o sumă, o monedă, o referință de comandă. Este doar de adăugare, intenționat: este menită să fie o dovadă, așa că nimeni, nici noi, nu poate modifica sau șterge o intrare ulterior. De aceea, ce declară sistemele tale este o decizie care merită luată cu grijă, iar produsul te ajută să o iei: îți arată câte date personale a acumulat propria implementare, nu scurtează pe ascuns ce primește, iar o acțiune poate fi setată să refuze de-a dreptul datele personale. Unde poți, declară o referință în locul lucrului însuși.
Poate fi ceva interzis de-a dreptul, nu trimis cuiva spre aprobare?
Da, și este altceva decât o aprobare severă. În mod obișnuit, o acțiune reținută așteaptă ca o persoană să decidă. Poți însă marca o acțiune drept una pe care nimeni nu o poate decide: este refuzată, nimeni nu este întrebat, nimic nu ajunge în coada cuiva și nu există niciun buton care să o elibereze. Asta contează la patru dimineața, când diferența dintre „cineva trebuie să aprobe asta” și „nimeni nu poate aproba asta” este diferența dintre un control și un om obosit. Registrul spune totuși ce regulă a refuzat și de ce, ca să poți număra ce se încearcă. Un cost onest: o regulă de acest fel refuză în loc să întrebe când nu poate fi sigură, așa că merită scrisă îngust, iar produsul îți arată unde s-ar putea întâmpla asta.
Unde se ia de fapt decizia — pe mașinile noastre sau pe ale voastre?
Oricare, iar alegerea vă aparține. Implicit îl rulăm noi; echipele care au nevoie îl rulează în întregime în propria rețea, decizia luându-se pe echipamentul lor, fără nicio legătură activă cu noi. În ambele cazuri dovezile rămân la voi: registrul a ce s-a întâmplat și aprobările din el vă aparțin și ne supraviețuiesc. Costul onest când îl rulăm noi: când serviciul nostru nu poate fi contactat, acțiunile reținute sunt refuzate, nu lăsate să treacă. O autorizare pe care nu o puteți obține nu este o autorizare pe care o aveți, iar noi preferăm să oprim o plată decât să o lăsăm să treacă pentru că ceva de-al nostru a căzut. Panoul vă spune în orice moment care dintre cele două variante rulează.
Unde este compania?
"STILL BETA TECH" SRL, înregistrată în Chișinău, Republica Moldova. Moldova nu este stat membru al Uniunii Europene; prelucrăm date cu caracter personal conform GDPR și Legii nr. 133/2011 a Republicii Moldova, și spunem asta în loc să sugerezi un sediu pe care nu îl avem.