Seif

Kodwen Vault îți păstrează credențialele criptate pe propriile dispozitive: clienții sigilează fiecare element (XChaCha20-Poly1305, chei împachetate cu hibridul post-cuantic X-Wing) înainte de încărcare, deci în mod implicit /v1/vault/* stochează și sincronizează text cifrat pe care Kodwen nu îl poate citi. Seiful este zero-knowledge în mod implicit, cu o singură excepție, dezactivată implicit și setată pentru fiecare element: proprietarul unui seif poate marca un element ca utilizabil în cloud (PUT /v1/vault/items/{id}/cloud). Clientul trimite atunci elementul decriptat, iar gateway-ul păstrează o a doua copie, sigilată cu o cheie KMS Kodwen, pe care o poate deschide ca să servească cererile agenților (/v1/vault/http, /v1/vault/resolve, /v1/vault/derive) cât timp dispozitivele tale sunt offline. Doar proprietarul seifului o poate activa sau dezactiva; dezactivarea, modificarea elementului sau ștergerea lui elimină acea copie. Agenții nu primesc niciodată valori secrete. Ei văd un catalog de handle-uri ({{vault:<slug>}}), cer o decizie de politică (niveluri t0-t4 sau deny), așteaptă aprobarea ta când nivelul o cere și apelează endpoint-uri HTTPS intermediate al căror răspuns este redactat.

SDK-urile expun toată suprafața ca codai.vault (TypeScript și Python), iar cheile de dispozitiv sub codai.vault.devices.

Elemente: sincronizare, scriere și roluriCopiază linkul secțiunii

Citirea și sincronizarea elementelorCopiază linkul secțiunii

GET /v1/vault/items răspunde { items, server_time, has_more }. Fiecare element este rândul stocat: id, vault_id, revision, wrapped_key, ciphertext, kind, slug, agent_meta, honeytoken, cloud_usable, deleted_at, last_used_at, created_at, updated_at.

• Lista completă (fără since): doar elementele active, cele mai recent modificate primele, cel mult 5000. has_more este adevărat când există peste 5000 de elemente active.
• Modificări (?since=<dată și oră ISO 8601>): fiecare element modificat după since, inclusiv cele șterse (deleted_at este setat: elimină elementul local), cele mai vechi primele, cel mult 1000 pe apel.
• Elemente șterse: un element șters de mai mult de 30 de zile păstrează doar un rând de marcaj, iar wrapped_key și ciphertext ale lui sunt șiruri goale, deci un client nu trebuie să decripteze niciodată un rând care are deleted_at.
• has_more: true: apelează din nou imediat cu since = server_time primit, care este atunci updated_at al ultimului element întors. Bazează-te pe has_more, nu pe numărul de elemente: o pagină nu este tăiată niciodată în interiorul unei milisecunde, deci poate avea mai puțin de 1000 de elemente și are peste 1000 doar când mai mult de 1000 de elemente s-au modificat în aceeași milisecundă.
• has_more: false: ești la zi. server_time este ceasul bazei de date, citit înaintea elementelor, minus 5 secunde; păstrează-l ca since al următoarei sincronizări. Poate fi mai devreme decât since-ul trimis de tine. Un element modificat în acele ultime secunde poate sosi din nou: înlocuiește copia ta a acelui id.
• Un since care nu poate fi citit ca dată și oră, inclusiv o valoare goală, răspunde 400 invalid_since. Momentele se compară la milisecundă.

Scrierea elementelorCopiază linkul secțiunii

PUT /v1/vault/items/{id} { vault_id, revision, wrapped_key, ciphertext, kind, slug?, agent_meta?, honeytoken? } răspunde 201 { id, revision } pentru un element nou și 200 { id, revision } pentru o actualizare. Corpul nu are id: calea numește elementul, iar o cheie pe care ruta nu o cunoaște răspunde 400.

• Un element nou trimite revision: 1; o actualizare trimite revizia stocată + 1. Orice altceva răspunde 409 { error: { code: 'revision_conflict' }, revision } cu revizia stocată: reîncarcă elementul și reîncearcă.
• 409 item_deleted: elementul a fost șters pe alt dispozitiv și rămâne șters. Elimină-l local; ca să îi păstrezi conținutul, creează un element nou cu un id nou.
• kind și seiful unui element sunt fixate la creare; o schimbare răspunde 400.
• Expunerea către agenți (slug și agent_meta, trimise mereu împreună) și honeytoken sunt decizii ale proprietarului sau ale unui manager al seifului. Un editor care creează un element cu ele sau le schimbă primește 403. Fiecare actualizare trimite înapoi neschimbate slug, agent_meta și honeytoken stocate; omiterea lor contează ca schimbare.
• Un slug deja folosit în același seif răspunde 400. O schimbare de conținut elimină copia pentru cloud a elementului.

DELETE /v1/vault/items/{id} păstrează rândul ca element șters pentru sincronizare, revocă toate permisiunile pe el și îi elimină copia pentru cloud. Ștergerea unui element deja șters răspunde același 200 { deleted: true } și nu schimbă nimic.

Înregistrarea unei folosiri localeCopiază linkul secțiunii

POST /v1/vault/items/{id}/used { via } înregistrează că un passkey sau o autentificare a fost folosită pe un dispozitiv (via: windows_plugin, android_provider, ios_provider, desktop sau phone) și răspunde { id, last_used_at }. Se stochează doar momentul, niciodată conținutul. Ruta păstrează o singură marcare pe element la 60 de secunde: o repetare în acest interval răspunde 200 cu last_used_at stocat, nu scrie nimic și nu înregistrează niciun eveniment item.used. Nu răspunde niciodată 429. Un element necunoscut, șters sau inaccesibil răspunde 404.

Ce poate face fiecare rol pe elementeCopiază linkul secțiunii

Un apelant care nu este membru al seifului primește 404, același răspuns ca pentru un seif care nu există.

Răspunsuri 429Copiază linkul secțiunii

Fiecare 429 are corpul { error: { message, type: 'rate_limit_error', code } } și un antet Retry-After în secunde.

Chei de dispozitiv și confirmare dovedităCopiază linkul secțiunii

O aprobare dovedește cine a decis. Pe lângă semnătura v1 a cheii seifului, o decizie poate purta o dovadă v2 de la o cheie de dispozitiv protejată hardware (Android Keystore pe telefon și ceas, Windows Hello pe desktop) sau de la un passkey. Cheile de dispozitiv sunt doar chei publice; cheia privată nu părăsește niciodată hardware-ul securizat al dispozitivului.

ÎnrolareaCopiază linkul secțiunii

1. POST /v1/vault/devices/challenge întoarce un nonce de unică folosință (32 de octeți aleatori, base64url), valabil 5 minute.
2. Dispozitivul își creează cheia, iar cheia seifului și cheia dispozitivului semnează amândouă mesajul de înrolare: codai-vault/device-enroll/v1|<device_id>|<kind>|<spki_sha256>|<nonce>, unde spki_sha256 este base64url(SHA-256(SubjectPublicKeyInfo DER)).
3. POST /v1/vault/devices trimite device_id (android-…, wear-…, desktop-…, ios-… sau cli-…), kind (android_keystore, windows_hello, ios_secure_enclave sau cli_ed25519), name, surface (phone, wear, desktop sau cli), public_key, nonce, vault_signature, device_signature și, când există, o attestation. Răspunsul este 201 { device }.

Reînrolarea aceluiași device_id îi înlocuiește cheia. GET /v1/vault/devices listează cheile tale (inclusiv cele revocate), PATCH /v1/vault/devices/{id} redenumește una, iar DELETE /v1/vault/devices/{id} o revocă imediat: următoarea ei dovadă primește 403 device_revoked.

Toate valorile binare sunt base64url fără padding. Android semnează cu ECDSA P-256 SHA-256 (DER); Windows Hello semnează cu RSASSA-PKCS1-v1_5 SHA-256; cli_ed25519 (cheia software creată de codaid vault enroll) semnează cu Ed25519 (semnătură brută de 64 de octeți, public_key = SubjectPublicKeyInfo DER Ed25519).

Tipuri de atestareCopiază linkul secțiunii

Cheile Android trebuie să trimită attestation: { android_chain: [...] } (frunza prima); provocarea de atestare este formată din octeții nonce-ului, iar cheia atestată trebuie să fie egală cu public_key. Cheile Windows Hello pot trimite attestation: { tpm: { attestation, cert_chain } }; fără ea cheia este hello-unattested, cu una invalidă înrolarea eșuează. Cheile de iPhone (ios_secure_enclave) nu trimit deloc attestation (cu una, înrolarea eșuează cu attestation_invalid); semnătura este ECDSA P-256 SHA-256 în DER, ca la Android. Erori: 400 invalid_nonce, possession_failed, attestation_required, attestation_invalid; 403 invalid_signature; 409 device_id_taken; 503 revocation_unavailable (lista de revocare Google nu a putut fi verificată, reîncearcă mai târziu).

Mesajele de aprobareCopiază linkul secțiunii

• v1 (cheia seifului): codai-vault/approve/v1|<approval_id>|<action_hash>|<decision>|<scope>, trimis ca signature.
• v2 (cheie de dispozitiv sau passkey): codai-vault/approve/v2|<approval_id>|<action_hash>|<decision>|<scope>|<device_id>, trimis ca proof: { type: 'device', device_id, signature }.
• v3 (cheie de dispozitiv sau passkey + potrivirea numărului): codai-vault/approve/v3|<approval_id>|<action_hash>|<decision>|<scope>|<device_id>|<preview_digest>|<match_number>, trimis cu match_number lângă proof. preview_digest este base64url(SHA-256) al textului canonic al request.preview (codai-vault/preview/v1, apoi title, agent, mode, host, action, purpose, task ca linii cheie=valoare, cu \, linie nouă și CR escapate), deci semnătura acoperă exact ce a văzut aprobatorul.
• passkey: provocarea WebAuthn este base64url(SHA-256(mesajul v2 cu id-ul de dispozitiv passkey)), trimisă ca proof: { type: 'passkey', response }.

Trimite cel mult unul dintre signature și proof. step_up_acr este încă acceptat, dar ignorat: o confirmare declarată de client nu dovedește nimic.

Reguli pe niveluriCopiază linkul secțiunii

• Refuzul nu cere dovadă (butonul Refuză din notificare este suficient).
• Aprobarea T3 acceptă o semnătură v1 validă, o dovadă de dispozitiv sau o dovadă passkey.
• Aprobarea T4 cere o dovadă de dispozitiv sau passkey; o semnătură v1 primește 403 step_up_required. Toate tipurile de atestare de mai sus sunt acceptate astăzi.
• Ceasul Wear aprobă doar T3: o cheie de ceas nu poate fi atestată ca legată de biometrie, deci o dovadă de la un dispozitiv wear pe o aprobare T4 primește 403 wear_t3_only.
• Potrivirea numărului: fiecare cerere T3/T4 primește un match_number din 2 cifre, întors doar agentului (/vault/use, /vault/http, /vault/resolve). Aprobatorul vede request.preview și trei request.match_choices, niciodată numărul. O aprobare T4 pe o astfel de cerere cere match_number cu o dovadă v3: fără număr primește 403 match_required; un număr greșit refuză imediat cererea și primește 403 match_mismatch. Aprobările T3 și refuzurile acceptă în continuare v1/v2.

Alte erori de dovadă (403): invalid_signature, unknown_device, device_revoked, passkey_invalid.

Dovada pentru resolve (brokeri locali)Copiază linkul secțiunii

POST /v1/vault/resolve întoarce valori unui broker local (codaid, desktop) care le injectează într-un proces copil și îi redactează ieșirea. Brokerul trebuie să dovedească faptul că deține o cheie de dispozitiv înrolată; antetul x-codai-agent singur nu este de încredere.

1. POST /v1/vault/resolve/challenge întoarce un challenge de unică folosință, valabil 120 s.
2. Brokerul semnează codai-vault/resolve/v1|<challenge>|<device_id>|<digest> cu cheia dispozitivului, unde digest = base64url(SHA-256(handles unite cu \n, apoi \n\n, apoi action)), cu handle-urile exact cum sunt trimise și în aceeași ordine.
3. Corpul cererii resolve poartă proof: { device_id, challenge, signature }.

Erori: 400 proof_required (fără dovadă), 400 invalid_challenge (necunoscut, folosit sau expirat), 403 invalid_device_proof (cheie care nu e a ta, revocată sau semnătură greșită), 403 broker_only (nu este un broker Kodwen). Evenimentul de audit use.resolved înregistrează device_id.

Protecții la anomaliiCopiază linkul secțiunii

Fiecare utilizare de către un agent este verificată și față de protecțiile tale la anomalii, citite din GET /v1/vault/account (guards) și schimbate cu PATCH /v1/vault/settings { default_tier?, guards? } (trimite cel puțin unul; guards este parțial și se combină cu valorile curente, iar răspunsul este { default_tier, guards } efectiv).

O anomalie forțează decizia la t4: utilizatorul aprobă cu o cheie de dispozitiv sau un passkey (inclusiv potrivirea numărului), iar permisiunile existente care nu au fost aprobate la t4 sunt ignorate pentru acea utilizare. Un deny rămâne deny.

Blocare de urgență și deblocareCopiază linkul secțiunii

POST /v1/vault/lock (corp opțional, { via? }) este butonul de panică: revocă toate permisiunile active, refuză toate aprobările în așteptare și blochează seiful, răspunzând { locked_at, grants_revoked, approvals_denied }. Cheile dispozitivelor rămân înrolate ca să poți debloca. Apelul este idempotent. Cât timp e blocat, GET /v1/vault/account arată locked_at și lock_reason (panic sau honeytoken), iar orice utilizare de către agenți este refuzată cu motivul vault_locked (/v1/vault/http și /v1/vault/resolve răspund 403 vault_denied).

Deblocarea cere o dovadă protejată hardware peste o provocare de unică folosință:

1. POST /v1/vault/unlock/challenge întoarce { challenge, expires_at, message_template } (32 de octeți aleatori, base64url, valabilă 5 minute).
2. Construiește mesajul codai-vault/unlock/v1|<challenge>|<device_id|passkey>:
   • cheie de dispozitiv (telefon, desktop): cheia semnează mesajul UTF-8 cu id-ul dispozitivului tău, trimis ca proof: { type: 'device', device_id, signature }. Cheile de ceas sunt refuzate (wear_t3_only).
   • passkey (hub): provocarea WebAuthn este base64url(SHA-256(mesajul cu passkey în locul id-ului de dispozitiv)), trimisă ca proof: { type: 'passkey', response }.
3. POST /v1/vault/unlock { challenge, proof, via? } răspunde { unlocked: true }. Erori (403): challenge_invalid, unknown_device, device_revoked, wear_t3_only, invalid_signature, passkey_invalid.

Jurnalul de audit înregistrează vault.locked, vault.unlocked, vault.unlock_failed și use.locked.

Momeli (honeytokens)Copiază linkul secțiunii

Un element marcat honeytoken este o momeală pe care niciun agent legitim nu ar trebui să o atingă. O utilizare a lui este refuzată și declanșează o alarmă, iar acum blochează și seiful (lock_reason: 'honeytoken') și trimite o notificare de date fiecărui dispozitiv activ: { kind: 'vault.alarm', reason: 'honeytoken', locked: '1', title?, agent?, host? } (o blocare de urgență trimite aceeași alarmă cu reason: 'panic'). Deblochează ca mai sus după ce știi ce s-a întâmplat.

Limite per handleCopiază linkul secțiunii

Limitează cât de des pot agenții folosi un element. GET /v1/vault/limits listează { limits: [{ item_id, per_minute, per_day, units_per_day }] }; PUT /v1/vault/items/{id}/limits { per_minute, per_day, units_per_day } le setează (toate cele trei chei sunt obligatorii, null elimină o limită, toate null elimină limitele; rol de editor sau mai mare pe seiful elementului).

Se numără doar utilizările permise. O utilizare http costă 2 unități, orice alt mod 1. Peste o limită, /v1/vault/use, /v1/vault/http și /v1/vault/resolve răspund 429 { error: { code: 'vault_rate_limited', type: 'rate_limit_error', message } } cu Retry-After (60 s pentru limita pe minut, 3600 s pentru limitele zilnice), iar jurnalul de audit înregistrează use.limited.

Permisiunile se încheie odată cu sarcinaCopiază linkul secțiunii

O permisiune creată pentru o sarcină (scope task sau orice permisiune care poartă task-ul trimis la /v1/vault/use) este revocată când sarcina se încheie: la POST /v1/tasks/{id}/confirm, la DELETE /v1/sessions/{id} și de un proces de curățare la fiecare 5 minute pentru sarcinile închise. Agenții și brokerii le pot încheia explicit cu POST /v1/vault/grants/revoke-task { task }, care răspunde { revoked: n }. GET /v1/vault/grants rămâne neschimbat; clienții grupează rândurile după task ca să arate permisiunile active.

Cereri de adăugareCopiază linkul secțiunii

Când un agent are nevoie de o credențială pe care seiful nu o are, nu trebuie niciodată să-ți ceară s-o lipești în chat. În schimb creează o cerere de adăugare, iar tu introduci valoarea într-o pagină Kodwen unde este criptată în browser (sau în aplicația desktop) înainte de salvare.

• POST /v1/vault/add-requests { kind, title, slug?, hosts?, env_var?, fields?, purpose, task? } răspunde 201 { id, url, status, expires_at }. url este https://hub.codai.ro/vault/add?req=<token>; tokenul apare doar în acest răspuns. fields sunt numele câmpurilor cerute (cel mult 10), niciodată valori. O cerere trăiește 10 minute; pot fi cel mult 20 de cereri în așteptare per utilizator.
• GET /v1/vault/add-requests/{id} răspunde { id, status, slug, handle, item_id, expires_at }, unde status este pending, completed, cancelled sau expired, iar handle este {{vault:<slug>}} după finalizare.
• DELETE /v1/vault/add-requests/{id} o anulează.
• POST /v1/vault/add-requests/lookup { token } întoarce cererea doar utilizatorului autentificat căruia îi aparține (linkuri directe pe desktop și telefon); oricine altcineva primește 404.
• POST /v1/vault/add-requests/{id}/complete { item_id } o marchează finalizată; elementul trebuie să fie într-unul dintre seifurile tale. Repetarea apelului cu același element nu mai schimbă nimic.

Aplicația desktop deschide codai://vault/add?req=<token> când este instalată; telefonul deschide pagina din hub într-un Custom Tab. Jurnalul de audit înregistrează add.requested, add.completed și add.cancelled.

Din terminal, codaid vault add --title <t> [--kind api_key] [--slug s] [--host h]… [--env-var NAME] [--field f]… [--purpose p] [--json] creează aceeași cerere și afișează linkul de deschis.

Din MCP: elicitare prin URLCopiază linkul secțiunii

Setul de unelte MCP vault (în gateway și în codaid vault mcp) are două unelte pentru asta: vault_add_secret (aceleași intrări ca apelul REST) și vault_add_status { id }.

• initialize răspunde cu un antet Mcp-Session-Id care reține dacă clientul tău a declarat capabilities.elicitation.url. Antetul este semnat și fără stare pe server (v1.<payload>.<HMAC-SHA256>, valabil 30 de zile); trimite-l înapoi la apelurile următoare.
• Dacă elicitarea prin URL este declarată, tools/call vault_add_secret răspunde cu eroarea JSON-RPC -32042 și data.elicitations = [{ mode: 'url', elicitationId, url, message }], așa cum o definește specificația MCP (2025-11-25). Clientul afișează linkul; după ce adaugi secretul, agentul apelează vault_add_status (sau din nou vault_add_secret cu același slug sau titlu în 10 minute, ceea ce refolosește cererea) și primește handle-ul.
• Alternativă: fără această capabilitate (sau fără id de sesiune), unealta întoarce un rezultat obișnuit cu linkul și instrucțiunea „deschide-l, apoi apelează vault_add_status”.

SecuritateCopiază linkul secțiunii

• URL-ul conține doar un token de unică folosință de 32 de octeți; serverul păstrează SHA-256 al lui, niciodată tokenul însuși.
• Linkul nu este preautentificat: pagina din hub cere autentificare și arată cererea doar utilizatorului pentru care a fost creată. Oricine altcineva vede „nu a fost găsită”.
• Pagina nu primește nimic secret de la server. Sigilează elementul în browser cu cheile seifului tău și îl salvează pe calea obișnuită pentru elemente; agentul vede doar handle-ul.

Acces de urgențăCopiază linkul secțiunii

Numește un alt utilizator Kodwen care poate citi seifurile alese dacă tu nu mai poți, după o perioadă de așteptare pe care o controlezi.

• GET /v1/vault/emergency răspunde { outgoing, incoming }.
• POST /v1/vault/emergency { email, delay_hours, vault_ids? } răspunde mereu 202 { id }, cu aceeași formă indiferent dacă adresa are sau nu cont Kodwen, deci nu poate fi folosit pentru a descoperi conturi. delay_hours este 24, 48 sau 72; vault_ids este implicit seiful tău personal. Cel mult 5 contacte.
• POST /v1/vault/emergency/accept { token } (contactul): are nevoie de un cont de seif (404 vault_not_setup) și nu poate fi propria ta invitație.
• PUT /v1/vault/emergency/{id}/seal { grantee_fingerprint, sealed_keys } (tu): sealed_keys trebuie să acopere exact vault_ids. Dacă amprenta cheii contactului nu este cea pe care ai verificat-o, răspunsul este 409 fingerprint_changed. Compară amprenta afișată pe ambele dispozitive înainte de sigilare.
• PATCH /v1/vault/emergency/{id} { delay_hours?, vault_ids? } (tu): schimbarea seifurilor șterge cheile sigilate și readuce contactul în accepted.
• DELETE /v1/vault/emergency/{id}: tu revoci sau contactul refuză.
• POST /v1/vault/emergency/{id}/request { reason? } (contactul, stare sealed), apoi POST /v1/vault/emergency/{id}/deny sau /approve (tu, stare requested). Un proces de curățare acordă accesul după ce a trecut release_at.
• GET /v1/vault/emergency/{id}/vault-data (contactul, stare granted) întoarce textul cifrat al seifurilor alese și cheile sigilate; contactul decriptează local. Accesul este doar pentru citire și nu se extinde niciodată la agenți; fiecare citire apare ca emergency.accessed în jurnalul tău de audit.

Fiecare tranziție anunță cealaltă parte: notificare FCM de date { kind: 'vault.emergency', contact_id, event, other_name, release_at } pe telefon, Web Push în hub și un email. Jurnalul de audit înregistrează emergency.invited|accepted|sealed|requested|denied|approved|granted|revoked|accessed.

Rotire și monitorizarea scurgerilorCopiază linkul secțiunii

Verificarea scurgerilor (HIBP)Copiază linkul secțiunii

GET /v1/vault/hibp/range/{prefix} intermediază API-ul de intervale Pwned Passwords cu k-anonimitate: clientul calculează local SHA-1 pentru fiecare parolă, trimite doar primele 5 caractere hex și compară singur sufixul în răspuns. Gateway-ul nu vede niciodată o parolă sau un hash complet. Răspunsurile folosesc Add-Padding: true, ca mărimea lor să nu dezvăluie prefixul, sunt păstrate în cache 24 de ore și sunt limitate la 300 de apeluri per utilizator pe oră (429 peste limită, 503 hibp_unavailable când serviciul extern nu răspunde). Clientul raportează apoi POST /v1/vault/rotation/breach-report { results: [{ item_id, count }] } (cel mult 500); un element nou compromis trimite o notificare vault.breach.

Coada de rotireCopiază linkul secțiunii

• GET /v1/vault/rotation listează { items: [{ item_id, slug, title, kind, interval_days, rotated_at, due_at, overdue, breached, breach_count, breach_checked_at, snoozed_until, provider, create_url }] }: întâi cele compromise, apoi cele întârziate, apoi cele cu termenul cel mai apropiat.
• PUT /v1/vault/items/{id}/rotation { interval_days?, provider?, snoozed_until? } setează programul (1–730 de zile) și furnizorul; POST /v1/vault/items/{id}/rotated înregistrează o rotire și șterge marcajul de compromis.
• Valori implicite: 90 de zile pentru elementele api_key, oauth_token și env; autentificările sunt doar verificate pentru scurgeri; elementele cu derivator sunt omise (credențialele lor sunt de scurtă durată).
• Un proces de curățare la fiecare 6 ore trimite câte o notificare vault.rotation per element întârziat per ciclu (nu cât timp este amânat).
• Cheile care nu pot fi rotite printr-un API rămân statice, iar lista trimite la pagina unde creezi una nouă:

Credențiale JITCopiază linkul secțiunii

Un derivator transformă o credențială rădăcină într-una de scurtă durată, cu drepturi restrânse, la fiecare utilizare, astfel încât secretul de lungă durată nu ajunge niciodată la comandă.

• GET /v1/vault/derivers, PUT /v1/vault/items/{id}/deriver { provider, config, max_ttl_s } (300–43200 s), DELETE /v1/vault/items/{id}/deriver. config nu conține secrete.

{{vault:slug}} pe un element derivat este primul câmp derivat; {{vault:slug.<câmp>}} alege unul anume.

POST /v1/vault/derive este doar pentru brokerii Kodwen (codaid, desktop): corpul { handle, action, purpose?, provenance?, task?, ttl_s?, proof }, cu aceeași dovadă de dispozitiv ca la /v1/vault/resolve, peste handles = [handle]. Dovada este verificată înaintea oricărei decizii de politică; fără ea răspunsul este 400 proof_required, iar un apelant care nu este broker primește 403 broker_only. După politica obișnuită (modul env, inclusiv aprobările), elementul trebuie să fie utilizabil în cloud (409 not_cloud_usable) și să aibă un derivator (409 no_deriver). Răspunsul este { provider, values, env, expires_at } cu Cache-Control: no-store; o eroare a furnizorului răspunde 502 derive_failed, cu mesajul curățat de orice seamănă cu un token. Jurnalul de audit înregistrează derive.issued { provider, expires_at, device_id }, niciodată valoarea.

Elementele care nu sunt utilizabile în cloud sunt derivate în brokerul local (codaid vault run, desktop), cu aceiași furnizori; brokerul injectează variabilele de mediu în procesul copil și redactează orice valoare derivată din ieșirea lui.

/v1/vault/http pe un element cu derivator gcp_sa, cloudflare sau github_app injectează tokenul bearer derivat în locul secretului rădăcină. Tokenul este păstrat în memoria gateway-ului până cu 60 de secunde înainte să expire.

Completare automată de către agentCopiază linkul secțiunii

Browserul agentului din desktop se poate autentifica pe site-uri fără ca modelul să vadă parola. În browser_type, scrie {{vault:slug.câmp}} (username, password, totp sau orice alt câmp). Aplicația desktop apoi:

1. citește originea paginii prin CDP și verifică hosturile legate ale elementului (agent_meta.hosts); un host nelegat eșuează cu vault_host_mismatch;
2. cere o decizie de politică în modul autofill, cu host = hostul paginii (aprobare pe dispozitivul tău când nivelul o cere);
3. decriptează local, verifică dacă pagina este încă pe aceeași origine și injectează valoarea; unealta răspunde { ok, filled: true } fără valoare.

Instantaneele nu arată niciodată valoarea unui câmp de parolă, iar ieșirea browser_eval și a clicurilor este redactată pentru fiecare valoare completată în acea sesiune de browser ([vault:<slug>]).

Extensia de browser acceptă și cereri agent_fill de la aplicația desktop prin native messaging și completează doar când fila activă este exact pe originea cerută.

Extensia de browser și passkey-uri în WindowsCopiază linkul secțiunii

Kodwen Vault pentru Chrome și Edge (Manifest V3, distribuită nelistată în Chrome Web Store și ascunsă în Edge Add-ons):

• Funcționează singură: criptografia seifului este inclusă ca WASM (fără cod de la distanță). Deblochezi cu parola și Secret Key; sesiunea deblocată trăiește doar în memoria service worker-ului și se blochează implicit după 10 minute de inactivitate.
• Completează doar pe originea legată de autentificare: service worker-ul verifică originea filei, iar scriptul de conținut verifică din nou location.origin înainte să scrie un câmp.
• Native messaging opțional către aplicația desktop (host ro.codai.vault): deblocare cu Windows Hello pe desktop, completare din seiful desktop (candidates, fill) și completări cerute de agent. allowed_origins din manifestul hostului conține doar id-urile extensiei din magazine, iar aplicația desktop verifică din nou id-ul extensiei și originea paginii la fiecare cerere.
• Permisiuni: storage, scripting, activeTab, contextMenus, alarms, nativeMessaging, idle; accesul la toate site-urile este opțional și cerut la rulare pentru completarea în pagină. Apelurile către gateway folosesc via: 'extension'.

Furnizor de passkey-uri în Windows 11: versiunea din Microsoft Store (MSIX) a aplicației desktop se înregistrează ca furnizor de passkey-uri, astfel încât Windows poate crea și folosi passkey-uri păstrate ca elemente passkey în seiful tău, după Windows Hello. Fiecare cerere de la Windows este verificată cu cheia de semnare a operațiilor pe care Windows a înregistrat-o pentru plugin. Instalările NSIS nu îl înregistrează și afișează „disponibil în versiunea din Microsoft Store”.

Android: parole și passkey-uri pentru alte aplicațiiCopiază linkul secțiunii

Aplicația Kodwen pentru Android descărcată de pe GitHub (nu versiunea din Play) este furnizor Credential Manager pe Android 14+ și serviciu de completare automată pe Android 11–13. Îl activezi din Setări › Parole și conturi (sau Serviciu de completare automată).

• Completare: autentificările potrivite (androidapp://<pachet> sau domeniul site-ului și subdomeniile lui) sunt oferite cât timp seiful e deblocat; fiecare completare cere o confirmare biometrică.
• Salvare: când îți creezi un cont sau schimbi parola într-o altă aplicație sau într-un browser, telefonul îți propune să o salvezi în seif: implicit în primul seif personal, sau în orice seif în care ești owner, manager sau editor. Dacă există deja o autentificare cu același nume de utilizator și aceeași adresă, îți propune să o actualizezi. Elementul este sigilat pe telefon și urcat doar ca text cifrat (PUT /v1/vault/items/:id); nu este niciodată vizibil agenților (fără handle).
• Passkey-uri: site-urile și aplicațiile pot crea și folosi passkey-uri (ES256) păstrate ca elemente passkey în seif, în același format ca furnizorul din Windows, deci un passkey creat pe telefon funcționează și pe desktop. Cheia privată rămâne în elementul din seif; semnarea are loc în nucleul seifului de pe dispozitiv după confirmarea biometrică, iar contorul de semnături este salvat înapoi în element. Cererile din browser sunt acceptate doar de la browserele din lista Google de browsere privilegiate și doar când id-ul relying party se potrivește cu originea paginii.
• Nucleul CTAP / WebAuthn (authenticator data, cheie COSE, atestare none, aserțiune) este comun pentru furnizorul din desktop și telefon (crates/codai-vault, funcționalitatea passkey).

Seifurile organizațieiCopiază linkul secțiunii

Un proprietar sau administrator al organizației creează un seif partajat cu POST /v1/vault/vaults { id, encrypted_meta, sealed_key, org_id } (kind: shared). GET /v1/vault/vaults arată apoi, pentru fiecare seif, org_id, role-ul tău (owner, manager, editor, viewer), quorum, rotation_needed_at și key_epoch. Serverul nu vede niciodată o cheie de seif: fiecare membru primește propria copie, sigilată pentru cheia lui publică X-Wing de clientul unui proprietar sau manager.

• GET /v1/vault/vaults/{id}/members (orice membru): { members: [{ user_id, email, name, role, fingerprint, key_epoch, added_at }] }.
• GET /v1/vault/vaults/{id}/candidates (proprietar/manager): membrii organizației care au cont de seif și nu sunt încă în seif, cu public_keys și fingerprint.
• PUT /v1/vault/vaults/{id}/members/{userId} { role, sealed_key, fingerprint } (proprietar/manager): arată amprenta candidatului, cere confirmarea ei (pe alt canal, ca la contactele de urgență), sigilează cheia seifului pentru public_keys și încarc-o. Dacă cheile membrului s-au schimbat de când a fost citită amprenta, răspunsul este 409 fingerprint_changed; un utilizator din afara organizației primește 403. Rândul proprietarului nu poate fi modificat.
• PATCH /v1/vault/vaults/{id}/members/{userId} { role } schimbă rolul (manager, editor sau viewer).
• DELETE /v1/vault/vaults/{id}/members/{userId} (proprietar/manager sau membrul care pleacă) șterge imediat rândul și setează rotation_needed_at. Eliminarea cuiva din organizație face același lucru pe toate seifurile acelei organizații.

Rotirea cheiiCopiază linkul secțiunii

Un membru eliminat poate avea încă o copie veche a cheii seifului, așa că după orice eliminare seiful afișează un banner până când un proprietar sau manager îl rotește. Clientul generează o cheie nouă de seif, o resigilează pentru fiecare membru rămas, reîmpachetează cheia fiecărui element și trimite totul într-un singur apel:

POST /v1/vault/vaults/{id}/rotate { key_epoch, encrypted_meta, members: [{ user_id, sealed_key }], items: [{ id, revision, wrapped_key, ciphertext }] }

key_epoch este epoca curentă + 1, iar revision al fiecărui element este revizia lui curentă + 1. Cererea trebuie să acopere fiecare membru actual și fiecare element activ (cel mult 2000): altfel răspunsul este 409 rotation_incomplete cu id-urile lipsă și nu se schimbă nimic. Totul rulează într-o singură tranzacție și șterge rotation_needed_at.

Aprobări cu cvorumCopiază linkul secțiunii

Pe un seif al organizației, proprietarul poate cere ca mai multe persoane să aprobe utilizările sensibile: PUT /v1/vault/vaults/{id}/quorum { m, scope }, cu m între 2 și 9 și scope critical (doar elementele critice) sau high (ridicate și critice); { m: null } dezactivează cvorumul. m nu poate depăși numărul de membri proprietari/manageri (400).

Când un agent cere o utilizare t3 sau t4 a unui element potrivit, aprobarea este creată cu quorum_m = m și expiră după 24 de ore. Dacă există mai puțin de m aprobatori eligibili (proprietari și manageri, alții decât solicitantul, cu cont de seif), utilizarea este refuzată imediat cu motivul quorum_unavailable. Fiecare aprobator eligibil primește o notificare, iar GET /v1/vault/approvals listează cererea cu quorum: { m, approvals, needed, voted }.

• Votezi cu POST /v1/vault/approvals/{id}/vote { decision, proof }. Fiecare vot are propria dovadă peste approve/v4: codai-vault/approve/v4|<approval_id>|<action_hash>|<decision>|once|<approver_user_id>|<device_id>|<preview_digest> semnată de una dintre cheile de dispozitiv ale aprobatorului (proof: { type: 'device', device_id, signature }) sau ca passkey a cărui provocare WebAuthn este base64url(SHA-256(mesajul cu id-ul de dispozitiv passkey)). Id-ul utilizatorului care aprobă face parte din mesaj, deci dovada unui aprobator nu poate fi refolosită ca a altuia. Cheile software sunt refuzate; t4 cere un dispozitiv atestat sau un passkey. Nu există număr de potrivire: aprobatorii nu sunt lângă agent.
• Orice refuz încheie cererea (denied). A m-a aprobare distinctă o marchează approved și creează o singură permisiune once pentru solicitant; evenimentul de audit approval.approved listează dispozitivul fiecărui votant. Fiecare vot apare ca approval.vote.
• Erori: 409 already_voted, 409 not_pending, 403 pentru o dovadă greșită sau un aprobator neeligibil. POST /v1/vault/approvals/{id}/decide pe o aprobare cu cvorum răspunde 409 quorum_required.

Ce semnează aprobatorul (previzualizare v2)Copiază linkul secțiunii

Previzualizarea aprobării include acum lanțul de delegare al agentului (cine pe cine a rugat, cel mai exterior primul, unit prin >, tăiat la 300 de caractere). Textul canonic este codai-vault/preview/v2, urmat de title, agent, mode, host, action, purpose, task, chain ca linii key=value, cu aceeași escapare ca la v1. Un obiect de previzualizare al cărui chain este un șir folosește v2; altfel v1. Hub-ul, desktopul și telefonul arată lanțul lângă cerere, iar fiecare eveniment de utilizare îl stochează.

Tranziție: până la următoarea versiune de desktop și telefon, gateway-ul stochează și rezumatul v1 al aceleiași previzualizări (fără chain). O dovadă v3 este verificată întâi cu rezumatul v2, apoi cu cel v1; o dovadă v4 trebuie să folosească rezumatul v2.

Aprobări offline prin cod QRCopiază linkul secțiunii

Când telefonul nu are rețea, desktopul poate transporta aprobarea în ambele sensuri prin coduri QR:

1. Desktopul afișează un QR de cerere (JSON compact, UTF-8, corecție de erori M): { "v": "codai-vault-qr/1", "t": "req", "id", "h": "<action_hash>", "tier": "t3|t4", "u": "<id-ul solicitantului>", "p": { ...previzualizare... }, "c": ["47","12","83"] }.
2. Telefonul refuză un QR al cărui u nu este utilizatorul autentificat, recalculează singur rezumatul previzualizării din p (nu are încredere în niciun rezumat din QR), afișează p și îți cere să apeși numărul pe care ți-l arată agentul (unul dintre c; numărul nu apare în QR).
3. Telefonul semnează approve/v3 (v2 când nu există număr) cu cheia de dispozitiv și afișează un QR de răspuns: { "v": "codai-vault-qr/1", "t": "res", "id", "d": "approve|deny", "s": "once|task|1h|8h", "dev": "<id-ul dispozitivului>", "m": "<număr sau gol>", "sig": "<base64url>" }.
4. Desktopul îl citește cu camera web și trimite POST /v1/vault/approvals/{id}/decide { decision, scope, via: 'qr', match_number, proof: { type: 'device', device_id, signature } }. Gateway-ul verifică dovada dispozitivului exact ca și cum ar fi trimis-o telefonul.

Simulatorul de politiciCopiază linkul secțiunii

Înainte să-ți schimbi regulile, vezi ce ar fi făcut. POST /v1/vault/policy/simulate { rules?, default_tier?, since?, limit? } reevaluează utilizările trecute ale agenților tăi sub o politică propusă: rules înlocuiește regulile actuale, default_tier nivelul implicit; since este implicit acum 30 de zile, iar limit implicit 200 (cel mult 500). Este doar pentru citire și răspunde:

{ evaluated, changed, grants: 'none', rows: [{ event_id, at, item_id, title, agent, chain, mode, host, current_tier, simulated_tier, reasons, source }] }

Sursele sunt evenimentele use.allowed, use.denied și approval.requested (care stochează de acum chain, mode, host, action_hash, purpose, task și provenance, niciodată acțiunea brută), plus cererile stocate ale aprobărilor t3/t4 mai vechi (source: 'approval'). Sensibilitatea și hosturile legate provin din metadatele actuale ale fiecărui element. Permisiunile și protecțiile la anomalii nu sunt reevaluate. Aceeași verificare este disponibilă agenților prin unealta MCP doar pentru citire vault_policy_simulate.

Chitanțe semnateCopiază linkul secțiunii

Evenimentele relevante pentru securitate sunt semnate: use.allowed, use.denied, approval.approved, approval.denied, approval.vote și honeytoken. Fiecare are un plic DSSE la payload.receipt în jurnalul de audit:

• payloadType: application/vnd.codai.vault-receipt+json;
• conținut: { v: 1, event, user_id, item_id, agent, tier, action_hash, reasons, device_id, approval_id, at } (doar metadate, niciodată o valoare);
• signatures: [{ keyid, sig }], ECDSA P-256 SHA-256 cu o cheie Cloud KMS.

Pentru verificare, citește GET /v1/vault/receipts/keys ({ keys: [{ kid, alg: 'ES256', pem }] }, păstrat în cache 1 oră), alege cheia al cărei kid este egal cu keyid și verifică semnătura peste codificarea de preautentificare DSSE DSSEv1 <len(type)> <type> <len(payload)> <payload>. Hub-ul face asta în browser și afișează un ecuson „semnat”. Dacă semnarea nu este disponibilă, evenimentul este stocat totuși, nesemnat; verificarea nu acceptă niciodată o chitanță nesemnată sau modificată.

Rezumatul săptămânalCopiază linkul secțiunii

În fiecare luni la 07:10 (ora României), utilizatorii cu activitate în seif în acea săptămână primesc un email prin poșta Kodwen: utilizări, refuzuri, aprobări, dispozitive noi, elemente scadente pentru rotire. Îl oprești din linkul de dezabonare, din setarea din hub sau cu PATCH /v1/vault/settings { digest_opt_out: true }; GET /v1/vault/account arată digest_opt_out.

Chei API cu scopuriCopiază linkul secțiunii

O cheie API poate avea scopes; null (orice cheie existentă) înseamnă cheie completă. O cheie cu scopuri poate apela doar:

Orice altceva răspunde 403 key_scope_forbidden. Conectează extensia de browser din pagina de chei a hub-ului emite o cheie cu vault.read + vault.add, valabilă 180 de zile, după o autentificare recentă, și o afișează o singură dată. Extensia o păstrează criptată cu o cheie AES-GCM neexportabilă ținută în IndexedDB, niciodată în clar. GET /v1/vault/account întoarce key_scopes pentru cheia care apelează, iar extensia avertizează când rulează cu o cheie completă.

Momeli în depoziteCopiază linkul secțiunii

codaid vault import --apply plantează și 2 elemente-momeală pentru fiecare depozit importat (numite după --repo sau după folder): elemente api_key vizibile agenților și marcate honeytoken, precum aws-prod-legacy, stripe-live-old, github-deploy-old sau openai-prod-old, legate de hostul real al furnizorului și completate cu valori aleatoare în formatul furnizorului (niciodată reale). Alegerea este deterministă pentru fiecare depozit și sare peste slug-urile pe care le ai deja; o rulare de probă le listează ca decoy. Fișierele din depozit nu sunt atinse niciodată. Orice utilizare declanșează calea de momeală de mai sus (refuz, blocare, notificare vault.alarm). Folosește --no-honeytokens ca să le omiți.

curl -X GET 'https://ai.codai.ro/v1/vault/account'

{  "bundle": {},  "fingerprint": "string",  "default_tier": "t1",  "revision": 0,  "locked_at": "2019-08-24T14:15:22Z",  "lock_reason": "panic",  "guards": {    "new_host": true,    "burst_max": 0,    "burst_window_s": 10,    "hour_start": 0,    "hour_end": 1,    "tz": "string"  },  "key_scopes": [    "vault.read"  ],  "digest_opt_out": true}

curl -X PUT 'https://ai.codai.ro/v1/vault/account' \  -H 'Content-Type: application/json' \  -d '{  "bundle": {}}'

{}

curl -X PATCH 'https://ai.codai.ro/v1/vault/settings' \  -H 'Content-Type: application/json' \  -d '{}'

{  "default_tier": "t1",  "guards": {    "new_host": true,    "burst_max": 0,    "burst_window_s": 10,    "hour_start": 0,    "hour_end": 1,    "tz": "string"  },  "digest_opt_out": true}

curl -X POST 'https://ai.codai.ro/v1/vault/lock' \  -H 'Content-Type: application/json' \  -d '{}'

{  "locked_at": "2019-08-24T14:15:22Z",  "grants_revoked": 0,  "approvals_denied": 0}

curl -X POST 'https://ai.codai.ro/v1/vault/unlock/challenge'

{  "challenge": "string",  "expires_at": "2019-08-24T14:15:22Z",  "message_template": "string"}

curl -X POST 'https://ai.codai.ro/v1/vault/unlock' \  -H 'Content-Type: application/json' \  -d '{  "challenge": "string",  "proof": {    "type": "device",    "device_id": "string",    "signature": "string"  }}'

{  "unlocked": true}

curl -X GET 'https://ai.codai.ro/v1/vault/limits'

{  "limits": [    {      "item_id": "4d8cd62e-a579-4dae-af8c-3172f96f8f7c",      "per_minute": 1,      "per_day": 1,      "units_per_day": 1    }  ]}

curl -X PUT 'https://ai.codai.ro/v1/vault/items/497f6eca-6276-4993-bfeb-53cbbbba6f08/limits' \  -H 'Content-Type: application/json' \  -d '{  "per_minute": 1,  "per_day": 1,  "units_per_day": 1}'

{  "limits": {    "item_id": "4d8cd62e-a579-4dae-af8c-3172f96f8f7c",    "per_minute": 1,    "per_day": 1,    "units_per_day": 1  }}

curl -X GET 'https://ai.codai.ro/v1/vault/vaults'

{  "vaults": [    {      "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",      "kind": "personal",      "owner_user_id": "65139110-7c3c-4777-b692-80c218be3b9d",      "org_id": "a40f5d1f-d889-42e9-94ea-b9b33585fc6b",      "encrypted_meta": "string",      "role": "owner",      "sealed_key": {},      "quorum": {        "m": 2,        "scope": "critical"      },      "rotation_needed_at": "2019-08-24T14:15:22Z",      "key_epoch": 1,      "updated_at": "2019-08-24T14:15:22Z"    }  ]}

curl -X POST 'https://ai.codai.ro/v1/vault/vaults' \  -H 'Content-Type: application/json' \  -d '{  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "encrypted_meta": "string",  "sealed_key": {}}'

{}

curl -X GET 'https://ai.codai.ro/v1/vault/items'

{  "items": [    {      "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",      "vault_id": "432b199b-1f71-42bf-ba0b-33d512afa9de",      "revision": 1,      "wrapped_key": "string",      "ciphertext": "string",      "kind": "login",      "slug": "string",      "agent_meta": {},      "honeytoken": true,      "cloud_usable": true,      "deleted_at": "2019-08-24T14:15:22Z",      "last_used_at": "2019-08-24T14:15:22Z",      "created_at": "2019-08-24T14:15:22Z",      "updated_at": "2019-08-24T14:15:22Z"    }  ],  "server_time": "2019-08-24T14:15:22Z",  "has_more": true}

curl -X PUT 'https://ai.codai.ro/v1/vault/items/497f6eca-6276-4993-bfeb-53cbbbba6f08' \  -H 'Content-Type: application/json' \  -d '{  "vault_id": "432b199b-1f71-42bf-ba0b-33d512afa9de",  "revision": 1,  "wrapped_key": "string",  "ciphertext": "string",  "kind": "login"}'

{  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "revision": 1}

curl -X DELETE 'https://ai.codai.ro/v1/vault/items/497f6eca-6276-4993-bfeb-53cbbbba6f08'

{  "deleted": true}

curl -X PUT 'https://ai.codai.ro/v1/vault/items/497f6eca-6276-4993-bfeb-53cbbbba6f08/cloud' \  -H 'Content-Type: application/json' \  -d '{  "item": {}}'

{  "cloud_usable": true}

curl -X GET 'https://ai.codai.ro/v1/vault/rules'

{  "rules": [    {      "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",      "userId": "2c4a230c-5085-4924-a3e1-25fb4fc5965b",      "itemId": "f11b669d-7201-4c21-88af-d85092f0c005",      "agent": "string",      "mode": "env",      "tier": "t0",      "createdAt": "2019-08-24T14:15:22Z",      "updatedAt": "2019-08-24T14:15:22Z"    }  ]}

curl -X POST 'https://ai.codai.ro/v1/vault/rules' \  -H 'Content-Type: application/json' \  -d '{  "tier": "t0"}'

{  "rule": {    "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",    "userId": "2c4a230c-5085-4924-a3e1-25fb4fc5965b",    "itemId": "f11b669d-7201-4c21-88af-d85092f0c005",    "agent": "string",    "mode": "env",    "tier": "t0",    "createdAt": "2019-08-24T14:15:22Z",    "updatedAt": "2019-08-24T14:15:22Z"  }}

curl -X DELETE 'https://ai.codai.ro/v1/vault/rules/497f6eca-6276-4993-bfeb-53cbbbba6f08'

{}

curl -X GET 'https://ai.codai.ro/v1/vault/grants'

{  "grants": [    {      "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",      "userId": "2c4a230c-5085-4924-a3e1-25fb4fc5965b",      "itemId": "f11b669d-7201-4c21-88af-d85092f0c005",      "agent": "string",      "mode": "env",      "host": "string",      "task": "string",      "usesLeft": 0,      "expiresAt": "2019-08-24T14:15:22Z",      "revokedAt": "2019-08-24T14:15:22Z",      "approvalId": "23bbe807-dea1-4601-b208-07fd1aaad2b6",      "createdAt": "2019-08-24T14:15:22Z"    }  ]}

curl -X POST 'https://ai.codai.ro/v1/vault/grants/revoke-task' \  -H 'Content-Type: application/json' \  -d '{  "task": "string"}'

{  "revoked": 0}

curl -X DELETE 'https://ai.codai.ro/v1/vault/grants/497f6eca-6276-4993-bfeb-53cbbbba6f08'

{}

curl -X GET 'https://ai.codai.ro/v1/vault/events'

{  "events": [    {      "id": 0,      "userId": "2c4a230c-5085-4924-a3e1-25fb4fc5965b",      "kind": "string",      "itemId": "f11b669d-7201-4c21-88af-d85092f0c005",      "agent": "string",      "tier": "string",      "payload": {},      "createdAt": "2019-08-24T14:15:22Z"    }  ]}

curl -X GET 'https://ai.codai.ro/v1/vault/approvals'

{  "approvals": [    {      "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",      "quorum": {        "m": 2,        "approvals": 0,        "needed": 0,        "voted": true      },      "userId": "2c4a230c-5085-4924-a3e1-25fb4fc5965b",      "itemId": "f11b669d-7201-4c21-88af-d85092f0c005",      "agent": "string",      "tier": "t3",      "request": {},      "actionHash": "string",      "reasons": [        "string"      ],      "status": "pending",      "expiresAt": "2019-08-24T14:15:22Z",      "createdAt": "2019-08-24T14:15:22Z"    }  ]}

curl -X GET 'https://ai.codai.ro/v1/vault/approvals/497f6eca-6276-4993-bfeb-53cbbbba6f08'

{  "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",  "status": "pending",  "tier": "t3",  "expiresAt": "2019-08-24T14:15:22Z",  "grantScope": "string",  "decidedDeviceId": "string",  "quorum": {    "m": 2,    "approvals": 0,    "needed": 0,    "voted": true  },  "vault_id": "432b199b-1f71-42bf-ba0b-33d512afa9de"}

curl -X POST 'https://ai.codai.ro/v1/vault/approvals/497f6eca-6276-4993-bfeb-53cbbbba6f08/decide' \  -H 'Content-Type: application/json' \  -d '{  "decision": "approve",  "scope": "once"}'

{}

curl -X POST 'https://ai.codai.ro/v1/vault/devices/challenge'

{  "nonce": "string",  "expires_at": "2019-08-24T14:15:22Z"}

curl -X GET 'https://ai.codai.ro/v1/vault/devices'

{  "devices": [    {      "id": "string",      "kind": "android_keystore",      "name": "string",      "surface": "phone",      "public_key": "string",      "attestation": "android-strongbox",      "attestation_info": {},      "created_at": "2019-08-24T14:15:22Z",      "last_used_at": "2019-08-24T14:15:22Z",      "revoked_at": "2019-08-24T14:15:22Z"    }  ]}

curl -X POST 'https://ai.codai.ro/v1/vault/devices' \  -H 'Content-Type: application/json' \  -d '{  "device_id": "string",  "kind": "android_keystore",  "name": "string",  "surface": "phone",  "public_key": "string",  "nonce": "string",  "vault_signature": "string",  "device_signature": "string"}'

{  "device": {    "id": "string",    "kind": "android_keystore",    "name": "string",    "surface": "phone",    "public_key": "string",    "attestation": "android-strongbox",    "attestation_info": {},    "created_at": "2019-08-24T14:15:22Z",    "last_used_at": "2019-08-24T14:15:22Z",    "revoked_at": "2019-08-24T14:15:22Z"  }}

curl -X PATCH 'https://ai.codai.ro/v1/vault/devices/string' \  -H 'Content-Type: application/json' \  -d '{  "name": "string"}'

{  "device": {    "id": "string",    "kind": "android_keystore",    "name": "string",    "surface": "phone",    "public_key": "string",    "attestation": "android-strongbox",    "attestation_info": {},    "created_at": "2019-08-24T14:15:22Z",    "last_used_at": "2019-08-24T14:15:22Z",    "revoked_at": "2019-08-24T14:15:22Z"  }}

curl -X DELETE 'https://ai.codai.ro/v1/vault/devices/string'

{  "ok": true}

curl -X GET 'https://ai.codai.ro/v1/vault/catalog'

{}