LLMs are proving increasingly useful for security research. Cisco aims to standardize and streamline the process of evaluating security in IT systems. With the Foundry Security Spec, now open-source, organizations can, just like Cisco itself, orchestrate LLMs in a predictable manner for mature security evaluations.
The reason this is a spec and not a single line of code is relatively simple. Cisco has indeed written all kinds of code for its own security evaluations, but by its own admission, that code would be of little help to other parties. “Our internal systems are tightly coupled to Cisco’s infrastructure: our cloud provider, our issue tracker, our LLM gateway, our development platform, our severity taxonomy [for vulnerabilities or security threats],” the company explains on its GitHub page. Nevertheless, this specification serves as a useful guide.
From LLM plumbing to business language
When you essentially “fire” an LLM at your IT environment, you likely rely on a gradually refined set of guardrails, permissions, and model choices to gain insights into that environment. You might be looking for ways to optimize it, or—in the scenario the Foundry Security Spec targets—for security considerations and potential misconfigurations or vulnerabilities. That can help, but according to Cisco, it is unstructured, highly error-prone, unvalidated, gives no idea of coverage, and is, fundamentally, improvised.
The alternative Foundry Security Spec starts from an orchestration layer, where the roles, guardrails, and domain for security evaluations are defined. From there, a detection agent operates, systematically analyzing code per specification. Then, another agent validates these findings and filters out false positives. A coverage tracker monitors whether the IT environment is being fully examined, after which an “auditable output” presents and maps the findings in a verifiable manner. According to Cisco, the end result is a security evaluation system that is defensible to CISOs and auditors, and potentially also to a C-suite colleague who might otherwise be difficult to convince.
Usage
Foundry Security Spec consists of two main documents. The first is the “spec.” It covers eight core roles for agents: Orchestrator, Indexer, Cartographer, Detector, Triager, Validator, Coverage-Guide, and Reporter. In addition, there are five additional roles for expansion, a lifecycle for the findings, and approximately 130 functional requirements. Each requirement includes an explanation of why it exists. The second document is the “constitution”: eleven inviolable principles. Each principle codifies a real production error that Cisco’s internal security team previously made, diagnosed, and resolved.
The specification is designed to be used in conjunction with GitHub’s spec-kit, a set of spec-driven development workflows for various AI agents. The constitution.md is readable by both the AI agent, such as Claude Code or Codex, and the human developer. Each rule precisely describes which production error it prevents. Cisco does this intentionally, because engineers who want to relax a principle to speed up the evaluation process first read the consequences of that choice.
The system delivers four outcomes, according to Cisco. A defined, prioritized, and verifiable set of findings; a clear “ready” signal; a traceable (i.e., auditable) chain of custody from detection to publication; and safety rails that assume the model could make a mistake at any time. These controls are built into the architecture, not the prompt, and should therefore be significantly more reliable than improvised systems.
Collaboration with Project CodeGuard
Foundry Security Spec works best in combination with Project CodeGuard, Cisco advises. The company had open-sourced CodeGuard in October and donated the project to the Coalition for Secure AI (CoSAI) in February. CodeGuard embeds security rules directly into AI coding workflows and helps AI coding agents automatically generate safer code.
The combination of both tools creates a self-improving cycle, a “feedback loop” for increasingly secure environments. CodeGuard rules systematically scan every function in the target codebase. Foundry’s exploratory agents also search for vulnerabilities not yet covered by existing rules. If such a new finding is confirmed, Foundry records a rule gap. That gap results in a new or revised CodeGuard rule, which is then available for all future evaluations and in developers’ editors.
Conclusion: a starting point
Cisco explicitly describes the Foundry Security Spec as a starting point, not a ready-made scanner. The eight agent roles define the structure, but implementation is up to the organization itself. The spec is also designed to remain relevant as LLMs continue to evolve: the need for an orchestrator, detector, and validator persists, regardless of which models are running under the hood.