Sikkerhetsteam som har kastet en repo til en frontier-LLM og bedt den «finne bugene» kjenner igjen resultatet: en vegg av blandede skarpe innsikter og hallusinerte funn, uten måte å vite hva som ble oversett. Cisco mener mønsteret er kjent nok til at de har skrevet ned skjelettet. 13. mai åpnet de Foundry Security Spec på GitHub, en modell- og stack-agnostisk spesifikasjon for å bygge agent-baserte sårbarhetsjakt-systemer.
Spesifikasjonen definerer åtte kjerne-agentroller (Orchestrator, Indexer, Cartographer, Detector, Triager, Validator, Coverage-Guide, Reporter) og fem utvidelsesroller. Hver rolle har definert formål, input, output og funksjonelle krav med begrunnelse. Totalt rundt 130 krav. Tillegget er en «constitution» med elleve ufravikelige prinsipper, hvor hvert prinsipp forklarer den konkrete produksjonsfeilen det skal hindre.
«Et fullt agent-system som Foundry Security Spec er motgiften til kaos: det pakker modellen inn i orkestrering, roller og rekkverk, slik at deteksjon, validering og dekning er designet på forhånd istedenfor improvisert i et chat-vindu.» — Cisco Security Engineering, kunngjøringen
Spesifikasjonen er ment å brukes med GitHubs spec-kit og pares med Project CodeGuard, et regelsett Cisco har donert til Coalition for Secure AI. Mønsteret er en lukket sløyfe: deteksjonsagentene finner noe nytt, det generaliseres til en CodeGuard-regel, regelen brukes både i neste evaluering og i utviklerens kodeassistent, og bug-klassen forsvinner ved tastaturslag.
Hva bør du gjøre?
- Klon Foundry-repoet (github.com/CiscoDevNet/foundry) og les constitution.md først. Den forklarer hvorfor hvert prinsipp er det det er, basert på Ciscos egne produksjonsfeil.
- Match spec-en til ditt eget miljø før du implementerer. Cisco har laget dette som blåkopi, ikke turnkey: rollene transferer, koden gjør det ikke.
- Vurder par-bruk med CodeGuard hvis du allerede har KI-koderassistenter i utviklingsflyten — Cisco peker eksplisitt på sløyfen mellom deteksjon og forebygging som det største utbyttet.