Privacy notice — uso LLM

In una frase

Quando esegui una Discovery, il codice sorgente del tuo software viene inviato in HTTPS ad Anthropic Inc. (provider di Claude) per produrre la sezione "Cosa fa l'app" e le proposte di rimedio. Per non-procurement / non-DPO: questo è il single most important fact da conoscere prima di adottare Hermes.

Il resto di questo documento spiega: cosa esattamente esce, cosa NON esce, su che base contrattuale, come puoi disattivare la chiamata LLM (modalità degraded "no LLM"), e come funziona la modalità bring-your-own-key (oggi disponibile, vedi §6.A).

Cosa viene inviato ad Anthropic

Selezione deterministica: stack-detector.ts SOURCE_RE filtra le estensioni source (ts/js/py/java/cs/php/go/cpp/c/rb/rs/kt/scala/sh/yml/ xml/asmx), ESCLUDE node_modules/.git/vendor/dist/build/target/ __pycache__ e file binari. code-comprehension.ts ordina per "score" euristico (entrypoint > moduli con framework hint > file root).

Cosa NON viene inviato

• File non-source (binari, immagini, lockfile, asset).
• Cartelle escluse: node_modules, .git, vendor, target, build, dist, coverage, __pycache__, .gradle, .idea, .vscode.
• Cronologia git (commit, blame, tag, branch diversi da HEAD).
• Altri repo / file fuori dal clone temporaneo della Discovery in corso.
• Credenziali OASI (deploy key, PAT GitHub) — sono cifrate AES-256-GCM, decifrate solo in-process per il clone, mai inviate ad Anthropic.

Cosa succede ai dati lato Anthropic

Nota Sprint 2-4: questa sezione descrive il default SaaS OASI (Anthropic SDK con chiave globale OASI). Casi in cui questa sezione NON si applica:

• Tenant ha la sua chiave Anthropic (§6.A): vale il contratto Anthropic del cliente — incluso eventuale ZDR — non OASI.
• Deploy on-prem con Bedrock (§6.C): vale il contratto AWS del cliente. Region EU, DPA AWS UE.
• Deploy on-prem con Vertex (§6.D): vale il contratto GCP del cliente. Region EU, DPA GCP UE.
• Deploy on-prem con Ollama (§6.E): nessun trasferimento extra perimetro — il modello gira nella DMZ cliente.

OASI usa Anthropic in modalità API standard tier (SaaS default). Per default:

• Niente training: secondo l'Anthropic Commercial Terms of Service vigenti, i prompt e le completion delle chiamate API NON sono utilizzati per addestrare modelli futuri. Riferimento: https://www.anthropic.com/legal/commercial-terms (sezione "Inputs and Outputs").
• Retention: Anthropic conserva i log delle chiamate API per finalità di "abuse detection and safety" per 30 giorni (default), poi sono eliminati. Su richiesta enterprise sono disponibili Zero- Data-Retention agreement (Hermes non ha attualmente uno ZDR con Anthropic; pianificato per piano Enterprise vedi §6).
• Data residency: chiamate verso api.anthropic.com (US-region per default). Anthropic offre opzionalmente AWS Bedrock (EU regions disponibili) e Google Vertex (regions varie) — Hermes può swap-are il provider via messagesCreate iniettabile (engine-side), ma in produzione SaaS è oggi US-default.

Base giuridica

OASI ha sottoscritto con Anthropic le Anthropic Commercial Terms + Data Processing Addendum (DPA) (vedi /legal/subprocessors). Per il cliente che utilizza Hermes, OASI è titolare del trattamento autonomo (rispetto al dato di operatore / billing) e responsabile del trattamento rispetto al codice del cliente che transita in Anthropic — ai sensi dell'Art. 28 GDPR.

Il cliente, se titolare di dati personali eventualmente contenuti nel codice sorgente (es. file fixture con email reali, dataset di test), deve valutare se l'invio ad Anthropic via Hermes è ammissibile per la propria base giuridica e finalità. La raccomandazione OASI è: non lasciare PII in chiaro nei file source — Hermes lo segnala peraltro come notable_risk.

L'elefante nella stanza: i segreti hardcoded

Se il codice del cliente contiene credenziali, password, API key, private key, o altri segreti hardcoded, Hermes non li maschera prima di inviarli a Claude. Il file source viene inviato tale e quale. Razionale:

• Mascherare prima del prompt distrugge l'informazione che serve a Claude per dire al cliente "ecco il segreto incriminato". Senza vedere vertigo / c@mm3ll0! Claude non può scrivere "Credenziali SMTP hardcoded in Service1.asmx.cs (utente 'vertigo', password 'c@mm3ll0!')" — che è esattamente il valore di sicurezza che produciamo.
• Il segreto È già compromesso se è in repo, indipendentemente da Hermes (chiunque acceda al repo lo vede; in molti casi il repo è già pubblico o è stato leak-ato in qualche backup).
• Tracking: il finding rientra in notable_risks con severità critical; la proposta di rimedio §1 è sempre "ruotare immediatamente il segreto compromesso".

Implicazione operativa: se hai un repo con segreti che NON sono mai stati esposti fuori dalla tua organizzazione (es. repo on-prem, mai uplodato altrove), e vuoi mantenere quella postura → fai prima una rotazione dei segreti, poi esegui la Discovery Hermes. La sezione "5 · Soluzioni proposte" segnalerà comunque "credenziali in chiaro, ruotare", solo che a quel punto stai trattando un finding già rimediato.

Tempistica e auditabilità

Ogni chiamata LLM è:

• registrata in HermesAuditLog come action: discovery.run, metadata.primaryStack, metadata.durationMs;
• attribuita all'userId dell'operatore + tenantId del repo;
• correlabile ai byte spediti via la durata.

Il cliente può richiedere a OASI un report dei volumi di trasmissione LLM per il proprio tenant, su domanda scritta a privacy@oasi.systems.

Opzione "no LLM" (modalità degraded)

Se ANTHROPIC_API_KEY non è configurata sul deploy:

• CodeComprehender restituisce status: "llm_unavailable" → sezione 1 del Report mostra una nota onesta "non eseguita".
• RemediationPlanner restituisce solo le proposte di upgrade delle dipendenze (deterministiche, no LLM); sezione 5 mostra solo quelle.
• Le altre sezioni del Report (Stack detection, Vulnerability scan, Telemetry plan) sono prodotte normalmente.

Questa modalità è oggi disponibile solo a livello di deploy (OASI configura la chiave). Per il cliente che voglia "no LLM per default, LLM opt-in per Discovery specifiche", la roadmap include un toggle per-Discovery (vedi §6.B).

Sovranità — opzioni disponibili e roadmap

A · Per-tenant Anthropic key — DISPONIBILE (Sprint 2, rb47). Il cliente porta la propria chiave Anthropic. La superAdmin OASI o un ADMIN del tenant la configura in /tenants/<id> (sezione "Chiave Anthropic propria"). Effetti:

• Le chiamate LLM CodeComprehender + RemediationPlanner per quel tenant escono dal contratto Anthropic del cliente, NON da quello di OASI.
• OASI smette di essere il responsabile del trattamento verso Anthropic per quel tenant (vedi /legal/dpa art. "Subprocessor Anthropic — esclusione condizionale").
• Se il cliente ha sottoscritto Zero-Data-Retention (ZDR) con Anthropic, lo ZDR si applica alle chiamate Hermes per il suo tenant (è il contratto del cliente che governa).
• La chiave è persistita cifrata AES-256-GCM (stessa crypto delle deploy key) e non viene mai restituita in chiaro dall'API.
• Audit: ogni tenant.set_anthropic_key / tenant.delete_anthropic_key è registrato in HermesAuditLog (no key fingerprint per evitare leak partial in log indelebile).

A.bis · Upload zip mono-shot — DISPONIBILE (Sprint 2, rb47). Cliente che non vuole / non può esporre un git remote (codice on-prem, folder Windows mai pubblicata) carica il bundle (.zip o .tar.gz, max 100 MB) via /discovery tab "Carica zip". Il bundle è estratto in tempdir isolata, analizzato, cancellato al termine (finally{} route + cleanup orfani > 60 min all'entrypoint container). Lo stesso flusso LLM si applica: se il tenant ha la sua chiave Anthropic (§A) le chiamate escono dal suo contratto.

B · Toggle LLM per Discovery (roadmap) — checkbox "Skip LLM analysis" sul form di Discovery; status risultante llm_unavailable ma operatore-chosen, audit-logged.

C · AWS Bedrock (Claude in EU-region) — DISPONIBILE (Sprint 4, rb49). Hermes può girare con HERMES_LLM_PROVIDER=bedrock, region configurabile (default eu-central-1 Frankfurt; alternativa eu-west-3 Paris). Le chiamate CodeComprehender+RemediationPlanner escono su bedrock-runtime.<region>.amazonaws.com con credenziali AWS standard (AWS_ACCESS_KEY_ID+AWS_SECRET_ACCESS_KEY o IAM role). Mapping payload: il body Anthropic Messages API è praticamente identico (campo anthropic_version: "bedrock-2023-05-31"). Modello identificato da Bedrock-style ID (es. eu.anthropic.claude-opus-4-7-20251111-v1:0).

D · Google Cloud Vertex AI (Claude in EU-region) — DISPONIBILE (Sprint 4, rb49). HERMES_LLM_PROVIDER=vertex + HERMES_LLM_GCP_PROJECT + region EU (europe-west1 o europe-west4). Le chiamate escono su <region>-aiplatform.googleapis.com. Auth: access token OAuth2 GCP gestito esternamente (il refresh integrato con google-auth-library è evoluzione prevista). Mapping: anthropic_version: "vertex-2023-10-16".

E · Ollama / LLM locale on-prem (air-gapped) — DISPONIBILE (Sprint 4, rb49). HERMES_LLM_PROVIDER=ollama + HERMES_LLM_OLLAMA_ENDPOINT=http://...:11434. Modello a scelta (Qwen 2.5-Coder, Llama 3.x, Mistral, ecc.). Nessuna chiamata outbound: il modello gira sul box stesso o su un GPU node raggiungibile via rete privata. Mapping API: Ollama /api/chat → trasformato in shape Messages API per compatibilità con l'engine.

Quality trade-off Ollama vs Claude: al 2025-mid i modelli open (Qwen 2.5-Coder, Llama 3.3) sono inferiori a Claude opus-4-7 sulla code-comprehension multilingue (italiano in particolare) e sulle proposte di remediation strutturate. Sufficienti per StackDetector

• vuln summary; meno affidabili sui passi di rimedio "concreti". Best-effort come tutti gli altri provider (status llm_unavailable se il modello non risponde).

F · Pre-redaction opt-in (roadmap) — modalità per ambienti regolati estremi: i finding di segreti vengono mascherati prima dell'invio al LLM (<REDACTED:secret>); il Report indica la presenza del segreto ma NON il valore. Costa qualità della narrativa (vedi §"L'elefante" sopra). Vale per qualunque provider §C/D/E.

Cosa si firma fra OASI e il cliente

• Il DPA template (vedi /legal/dpa) include articolo specifico "Trasferimento del codice cliente ad Anthropic come subprocessor", da controfirmare dal cliente.
• Se il cliente è soggetto NIS2, il DPA è uno degli artefatti che ricade nell'art. 21(2)(d) (supply chain security).

Contatti

Per domande puntuali su questo flusso: privacy@oasi.systems. Per richiedere ZDR / Bedrock / on-prem / pre-redaction: hermes@oasi.systems.

Questa notice descrive lo stato attuale (rb49 — Sprint 4). Le modifiche significative al flusso LLM sono comunicate via email ai clienti attivi con preavviso ≥30 giorni. Per cliente on-prem (Sprint 4 §C/D/E), eventuali modifiche sono distribuite via release notes contestuali alla minor version del software.