Skip to content

Piano Operativo Completo di Ottimizzazione Token

Scopo

Questo documento descrive tutto quello che implementerei per ridurre in modo aggressivo il consumo token del progetto, con un vincolo assoluto:

  • nessuna riduzione reale della copertura
  • nessuna riduzione del numero di finding trovati
  • nessuna riduzione della qualità di reasoning, verification, chaining o reporting

Il principio guida è:

eliminare solo costo inutile, costo duplicato, costo statico non selettivo e costo speso in sessioni impossibili o già fallite.

Questo documento è pensato per essere revisionato da Opus High prima dell'implementazione.

Materiale di riferimento

Vincoli non negoziabili

Qualsiasi cambiamento deve preservare:

  1. copertura della superficie di attacco
  2. hit rate sui crown jewels
  3. profondità di test su IDOR/Auth/SSRF/Injection/Logic/API
  4. qualità di exploit verification
  5. qualità e completezza delle evidenze
  6. qualità del chain discovery
  7. qualità del loop di apprendimento

Regola di approvazione

Una modifica entra solo se:

  • findings parity >= baseline
  • endpoint coverage parity >= baseline
  • crown jewel coverage parity >= baseline
  • verification parity >= baseline
  • no aumento del FP rate
  • token per finding confermato migliora in modo netto

Baseline da cui partiamo

Sintomi già misurati

  • bugbounty/PERPETUAL-HUNTING.log mostra 540 session start nell'ultima ora loggata
  • bugbounty/perpetual-hunting-console.log contiene 391 eventi out of extra usage
  • bugbounty/.prompt-*: 7160 file
  • bugbounty/.session-prompt-*: 2021 file
  • ProxySession.auto_analyze è True di default
  • proxy_analyzer_loop() parte automaticamente all'avvio backend

Peso statico stimato dei prompt principali

Stima conservative chars / 4.

  • CLAUDE.md: ~6.6K token
  • pentest/SKILL.md: ~41.6K token
  • test-injection + support: ~107.4K token
  • test-auth + support: ~82.4K token
  • test-access + support: ~57.5K token
  • test-client + support: ~30.0K token
  • test-logic + support: ~25.7K token
  • test-api + support: ~24.0K token
  • test-ssrf + support: ~19.7K token

Conclusione operativa

Le root cause da attaccare sono:

  1. bug bounty loop non quota-aware e non single-flight
  2. static prompt tax eccessivo
  3. parallelismo che moltiplica quel costo fisso
  4. proxy analyzer sempre acceso
  5. rediscovery non differenziale sui programmi di ritorno

Strategia generale

Dividerò il lavoro in due lane:

Lane A: Conservative, immediatamente safe

Nessun downgrade di modello e nessun taglio di copertura. Si agisce su:

  • orchestration
  • scheduling
  • dedupe
  • lock
  • cooldown
  • prompt compaction strutturale
  • context capsules
  • background AI gating

Lane B: Shadow-gated, ulteriore risparmio

Valida in shadow mode prima del rollout. Qui rientrano:

  • routing di task deterministici su modello più economico
  • attivazione automatica di tokens_optimizer equivalente
  • novelty thresholds più aggressivi
  • optional default-off per certe analisi AI background

Workstream 0: Misurazione Prima di Cambiare

Obiettivo

Misurare in modo affidabile dove vanno i token prima di cambiare semantica.

File da toccare

Cosa implementare

  1. Scrivere un record JSONL per ogni invocazione claude -p con:
  2. timestamp
  3. caller
  4. command family (bb-loop, bb-hunt, pentest, proxy-analyzer, runner)
  5. engagement/program/session id
  6. prompt file path o prompt digest
  7. prompt char count
  8. estimated prompt tokens
  9. max-turns
  10. model
  11. start/stop
  12. exit status
  13. rate-limit flag

  14. session classified outcome

  15. Se il stream-json finale espone metriche token, salvarle; altrimenti usare stima locale.

  16. Classificare ogni run in:

  17. useful
  18. rate_limited_immediate
  19. rate_limited_midrun
  20. dead_run_short
  21. error

Nuovi artifact runtime

Proposta:

  • bugbounty/.runtime/metrics/claude-invocations.jsonl
  • engagements/<name>/runtime/claude-invocations.jsonl
  • dashboard/data/runtime/proxy-analysis-metrics.jsonl

Acceptance

Prima di qualunque ottimizzazione, dobbiamo poter calcolare:

  • spawn/hour
  • prompt tax per family
  • dead-run ratio
  • rate-limit ratio
  • token per useful run
  • token per confirmed finding

Workstream 1: Harden del Bug Bounty Loop

Obiettivo

Fermare subito il burn inutile da orchestration difettosa senza toccare la qualità dell'hunting.

File da toccare

Modifiche richieste

1. Single-instance lock

Implementare lock atomico globale per loop bug bounty.

Semantica:

  • una sola istanza attiva per workspace/account
  • se esiste lock vivo: niente nuovo start
  • se lock è stale: recovery controllato con takeover loggato

Possibile path:

  • bugbounty/.runtime/loop.lock

2. Control plane unico

Rendere bb-loop/SKILL.md il front door ufficiale e far convergere:

  • PERPETUAL-HUNTING-LOOP.sh
  • loop-manager.sh
  • skill /bb-loop

su una sola semantica.

Regola:

  • un solo launcher
  • un solo pid/lock
  • un solo log di stato
  • un solo meccanismo di resume/backoff

3. Cooldown globale sul rate limit

Se un subprocess riporta out of extra usage o pattern equivalente:

  • marcare stato globale rate_limited
  • nessun nuovo claude -p finché il cooldown non scade
  • usare reset time se disponibile
  • fallback su backoff progressivo

Proposta:

  • 1° evento: attendi reset parseato o 15 min
  • 2° evento ravvicinato: 30 min
  • eventi continui: blocco fino a finestra reale

4. Classificazione sessioni "morte"

Una sessione viene classificata dead_run_short se:

  • <= 3 turni
  • oppure < 90s
  • oppure terminazione immediata con rate limit
  • oppure nessun comando reale eseguito

Queste sessioni:

  • non avanzano il loop normalmente
  • non incrementano ranking heuristics
  • attivano backoff, non restart immediato

5. Quota-aware scheduler

Il loop non deve essere "perpetual a prescindere", ma "perpetual entro finestra utile".

Semantica:

  • se quota disponibile: normal schedule
  • se quota incerta: riduci concurrency
  • se quota esaurita: pausa globale

6. Prompt dump/log hygiene

Spostare i dump fuori dal root operativo:

  • bugbounty/.runtime/prompts/
  • bugbounty/.runtime/logs/

Rotazione:

  • ultimi N giorni
  • opzionalmente compressione
  • cleanup sicuro al boot

Implementazione consigliata

Estrarre la logica di parse rate limit da pentest-autoresume.py e riusarla nel loop bug bounty, invece di avere due logiche separate.

Acceptance

  • massimo 1 orchestratore attivo
  • zero spawn durante cooldown globale
  • zero restart ogni 10 secondi in quota esaurita
  • run dead non contano come hunt reali

Saving atteso

Questo è il workstream con ROI maggiore.

Stima:

  • 40-85% di riduzione del burn attuale del BB loop, se il problema principale è davvero lo spawn storm in rate limit

Workstream 2: Context Slimming e Prompt Capsules

Obiettivo

Ridurre il costo statico per subprocess senza perdere metodologia.

File da toccare

Modifiche richieste

1. Distillare CLAUDE.md

Tenere in CLAUDE.md solo:

  • regole globali
  • safety invariants
  • orchestration invariants
  • poche convenzioni davvero always-on

Spostare il resto in helper on-demand.

2. Router + micro-pack per le skill pesanti

Esempio per test-injection:

  • router leggero
  • pack sqli
  • pack xss
  • pack ssti
  • pack xxe
  • pack cmdi

La route decide quali pack caricare in base a:

  • scope dispatch
  • signal dal fingerprint
  • tipo endpoint
  • tech stack

Stessa strategia per:

  • test-auth: session / jwt / oauth / password-reset / account-prehijack
  • test-access: idor / horizontal / vertical / multi-tenant / admin exposure

3. Supporting files lazy-load

I supporting files non devono essere tutti implicitamente attivi sempre.

Regola:

  • caricare solo i micro-pack rilevanti per il subtype
  • non caricare cheatsheet o knowledge di classi non attive

4. Prompt capsules compilate

Creare summary compatti, size-capped, deterministici per:

  • brief-compact.json
  • policy-compact.json
  • knowledge-compact.json
  • attack-surface-compact.json
  • findings-compact.json

Path proposti:

  • engagements/<name>/runtime/
  • bugbounty/programs/<platform>/<handle>/runtime/

5. Eliminare duplicazione testuale

Molte sezioni ripetono:

  • safety
  • output format
  • evidence rules
  • boilerplate

Queste vanno centralizzate una sola volta e referenziate con contratti compatti.

Semantica da preservare

Il comportamento della skill deve rimanere identico.

Deve cambiare solo:

  • quanto testo statico viene caricato per raggiungere quel comportamento

Acceptance

  • stessa lista di check reali eseguiti
  • stessa coverage per vuln class
  • stessa qualità di findings
  • prompt size medio per subprocess significativamente più basso

Saving atteso

Stima prudente:

  • 20-40% di riduzione per subprocess nei flow pesanti

Workstream 3: Skinny Context Prima del Fork

Obiettivo

Mantenere il parallelismo ma senza ereditare contesto grasso.

File da toccare

Modifiche richieste

Prima di ogni dispatch, il parent deve costruire un run-brief compatto con:

  • target
  • scope
  • credentials availability
  • crown jewels
  • endpoint subset assegnato
  • policy compact
  • prior blockers
  • prior successful techniques
  • next steps rilevanti

I child non devono ereditare:

  • log lunghi
  • findings storici completi
  • session history verbosa
  • boilerplate non rilevante per il proprio scope

Output suggerito

  • runtime/dispatch-brief.json

Acceptance

  • stesso numero di child utili
  • stesso assignment coverage
  • meno prompt duplication tra child

Workstream 4: Differential Rediscovery per Programmi di Ritorno

Obiettivo

Smettere di pagare ogni volta discovery completa quando la superficie non è cambiata.

File da toccare

Modifiche richieste

1. Freshness manifest

Salvare per ogni programma:

  • homepage hash
  • robots/sitemap hash
  • JS manifest hash
  • tech stack fingerprint
  • auth surface fingerprint
  • GraphQL presence/hash
  • endpoint set hash

2. Freshness check leggero all'inizio

Ogni ritorno su programma già noto esegue un delta check economico.

3. Decisione differenziale

Se il delta supera soglia:

  • full rediscovery

Se non supera soglia:

  • reuse baseline
  • delta crawl
  • focus su:
  • untested endpoints
  • next steps storici
  • nuovi artifact differenziali

Trigger per full rediscovery

  • nuova route di login
  • nuovi JS bundle
  • nuovo subdomain
  • cambio auth headers/cookies
  • nuovi sitemap entries
  • nuovo GraphQL/schema surface
  • change monitor ad alto priority boost

Acceptance

  • nessuna perdita di new asset detection
  • meno discovery ridondante sui programmi stabili

Saving atteso

Sui programmi di ritorno:

  • 30-70% nei cicli dove la superficie è stabile

Workstream 5: Proxy Analyzer Recall-Oriented ma Molto Più Economico

Obiettivo

Ridurre drasticamente il costo AI background sul traffico proxy mantenendo la capacità di segnalare le request davvero interessanti.

File da toccare

Lane A: Conservative

Tenere analyzer attivo ma con novelty gate.

1. Semantic dedupe

Fingerprint per request cluster:

  • method
  • normalized route template
  • param names
  • auth present/absent
  • status bucket
  • response content-type
  • response shape/hash

2. Batch solo su novelty o signal forte

Inviare a Claude solo:

  • nuovi cluster
  • cluster con delta significativo
  • errori interessanti
  • reflection
  • token leakage
  • redirect params
  • callback/webhook/url params
  • GraphQL
  • upload
  • admin/internal endpoints

3. Keep manual realtime

L'analisi single-request realtime resta disponibile sempre.

Lane B: Shadow-gated

Valutare dopo parity:

  • default auto_analyze=False per nuove sessioni
  • o default on solo per sessioni esplicitamente AI-assisted

Non lo farei prima della validazione.

Acceptance

  • stessa o migliore precisione su request davvero interessanti
  • riduzione forte di batch inutili
  • nessuna perdita sulle request ad alto signal

Saving atteso

  • 60-95% del costo del proxy background, se il traffico è molto ripetitivo

Workstream 6: Workspace e Search Hygiene

Obiettivo

Ridurre il rischio che file enormi e output locali rientrino nel contesto tool in modo inutile.

File da toccare

Modifiche richieste

Escludere di default da search e ispezione ampia:

  • .claude/worktrees/
  • dashboard/frontend/node_modules/
  • payloads/ non rilevanti per il task
  • prompt dump runtime
  • log runtime

Nota

Questo non è il driver principale del billing modello, ma aiuta molto a non sporcare il contesto operativo.

Workstream 7: Model Routing Solo Dove Non C'è Rischio

Obiettivo

Fare tutto il possibile, ma senza tagliare qualità.

Lane A

Nessun downgrade obbligatorio.

Lane B

Shadow-gated:

  • fingerprinting
  • policy parsing
  • surface diff
  • clustering
  • route preparation
  • batch normalization

possono passare a:

  • codice deterministico
  • oppure modello più economico

Opus resta mandatory per:

  • exploit reasoning
  • stuck resolution
  • verification
  • chain discovery
  • final finding acceptance

File coinvolti

Ordine di esecuzione consigliato

Fase 1

  • Workstream 0
  • Workstream 1

Questi due vanno fatti subito.

Fase 2

  • Workstream 2
  • Workstream 3

Qui si attacca il prompt tax vero.

Fase 3

  • Workstream 5
  • Workstream 4

Prima il proxy analyzer, poi il rediscovery differenziale.

Fase 4

  • Workstream 6
  • Workstream 7 Lane B

Priorità dei file pesanti da decomporre

  1. test-injection
  2. test-auth
  3. test-access
  4. pentest
  5. test-client
  6. test-logic

Piano di shadow validation

Dataset

Usare:

  • lab/eval con ground truth
  • 2-3 programmi BB storici con finding reali
  • 1 flusso con proxy analyzer attivo
  • 1 ritorno su programma già noto

Metriche mandatory

  • total token
  • token per subprocess family
  • token per finding confermato
  • prompt size medio
  • dead-run ratio
  • rate-limit ratio
  • endpoint coverage
  • crown jewel coverage
  • findings confirmed
  • findings accepted o ready-to-submit
  • FP rate

Modalità

Per ogni workstream:

  1. baseline run
  2. optimized run in shadow
  3. diff strutturato
  4. rollback immediato se coverage/findings parity fallisce

Rollback Plan

Ogni workstream deve essere feature-flagged.

Flag suggerite

  • BB_LOOP_SINGLETON_LOCK=1
  • BB_GLOBAL_RATE_LIMIT_GUARD=1
  • BB_DIFFERENTIAL_REDISCOVERY=1
  • PROXY_AI_NOVELTY_GATE=1
  • PROMPT_CAPSULES=1
  • SKINNY_FORK_CONTEXT=1
  • SKILL_LAZY_LOAD=1

Regola

Se qualsiasi flag porta:

  • finding drop
  • coverage drop
  • chain drop
  • verify degradation

si rollbacka solo quel workstream, non tutto il programma di ottimizzazione.

Risparmio atteso per workstream

Queste sono stime, non promesse:

  • loop hardening: 40-85%
  • prompt compaction: 20-40% per subprocess pesante
  • skinny fork context: 10-25%
  • differential rediscovery: 30-70% sui programmi di ritorno
  • proxy analyzer novelty gate: 60-95% del background proxy burn
  • routing non-Opus per task deterministici: ulteriore 10-30% in lane shadow

Cosa NON farei subito

Per prudenza non farei immediatamente:

  1. spegnere del tutto l'analyzer proxy di default senza shadow parity
  2. spostare troppe fasi su modelli più economici senza benchmark
  3. comprimere il loop riducendo programmi o ore per hunt
  4. ridurre il numero di skill o di wave senza dimostrare equivalenza

Richiesta esplicita a Opus High

Voglio che Opus High valuti:

  1. se questa sequenza di rollout è la più sicura
  2. se i workstream proposti sono davvero trasparenti rispetto alla qualità
  3. quali micro-pack vanno creati prima
  4. se il novelty gating del proxy analyzer è abbastanza recall-oriented
  5. se il differential rediscovery proposto è abbastanza conservativo
  6. se ci sono altre ottimizzazioni strutturali possibili senza regression

Decisione finale proposta

Se dovessi partire domani, farei in questo ordine:

  1. misurazione completa
  2. singleton lock + cooldown globale sul bug bounty loop
  3. classificazione run morte + backoff reale
  4. prompt capsules + skinny fork context
  5. decomposizione test-injection, test-auth, test-access
  6. novelty gate sul proxy analyzer
  7. differential rediscovery per programmi già noti
  8. solo dopo: model routing più aggressivo in shadow

Questa è, a mio avviso, la massima ottimizzazione possibile senza intaccare il valore offensivo del progetto.