docs: sez. 11.7 accesso condiviso — rischio e criteri per chiavi per-scope future

docs/playbook.md

@@ -359,6 +359,27 @@ pi install git:git.enne2.net/enne2/<repo>
 - Verificato sul server (2026-08-16): istanza di test su 8083, collection
   `memories_test`, produzione intatta (328 punti)
 
+### 11.7 Accesso condiviso: rischio e criteri futuri (decisione 2026-08-16)
+
+**Scelta attuale**: una chiave API con accesso COMPLETO in lettura/scrittura per
+l'intera conoscenza; `agent_id` è solo provenienza, non isolamento. Ambiente
+personale con agenti fidati (7 agenti, 2026-08-16).
+
+**Rischio documentato**: nessun namespace per tenant/agente con enforcement
+dell'autorizzazione (best practice AWS/OWASP: actor scoping su ogni read/write).
+Un agente compromesso o malevolo può leggere/scrivere/correggere qualsiasi
+record, incluso supersedere memorie altrui.
+
+**Criteri per passare a chiavi per-scope** (quando uno di questi si verifica):
+1. Entrano agenti di terze parti o non pienamente fidati
+2. Il numero di agenti supera ~10 o i progetti superano ~30
+3. Si registra un incidente di sicurezza o un accesso anomalo
+4. Serve audit per-agente affidabile (oggi l'agent_id è auto-dichiarato)
+
+**Implementazione futura suggerita**: mappa chiave→scope/permessi nel gateway
+(es. `API_KEYS=readonly:xxx,write:yyy` o chiavi con claim), filtro obbligatorio
+per scope/kind/project_id in base alla chiave, senza cambiare l'API pubblica.
+
 ### 11.5 project_id obbligatorio
 
 - Dal gateway v2.4.0 / estensione v1.4.0: `project_id` è **obbligatorio** in `POST /v1/memories` (Pydantic `min_length=1`) e nello schema del tool `qmem_store` (Type.String, non più Optional)