Configuring your AI vulnerability harness, Part 2: The steering file

The configuration of an AI model requires a steering file to enforce structured, evidence-based vulnerability triage consistent with a security analyst's rigor. This methodology is established through five key sections: structural verification over LLM trust, evidence-based confidence scoring, infrastructure-aware assessment, threat intelligence integration, and priority classification. The core premise is that explicit instructions shape the model's judgment more effectively than single-turn prompting, which relies on default helpfulness rather than analytical depth.
The steering file mandates that findings must be supported by structural verification—confirming dataflow, function existence, and call paths—to mitigate hallucination in security analysis. Confidence scoring shifts from intuitive self-reporting to a formula based on binary structural signals (e.g., confirmed taint or confirmed call graphs). Furthermore, infrastructure awareness requires mapping control types to specific multipliers and implementing defense-in-depth logic by stacking attack-blocking controls while maintaining a floor to prevent over-mitigation. Finally, threat intelligence from sources like CISA KEV and EPSS is integrated to adjust prioritization, and a clear priority classification system dictates actionable responses.
The validation demonstrated that applying this structured methodology resulted in more accurate findings, correctly identifying mitigated risks, and producing scientifically justifiable results when compared to unsteered assessments. The process moves the AI from generating plausible narratives to producing verifiable, reproducible security assessments.

* A steering file is a set of instructions loaded at the start of every session for an AI coding assistant.
* The instructions encode a team’s triage methodology as machine-executable instructions.
* Structural verification is required before reporting findings to prevent fabricated attack chains.
* Confidence scoring replaces self-reported confidence with a score computed from binary structural signals.
* Infrastructure-aware assessment maps controls to vulnerability classes using multipliers and enforces defense-in-depth stacking with a floor of 0.15.
* Threat intelligence integration incorporates signals from CISA KEV, EPSS, and Public Proofs of Concept (PoC).
* Priority classification uses score thresholds against criteria including the presence of effective attack-blocking mitigation.
* The priority tiers are P0 (Score $\ge$ 0.8 without mitigation), P1 (Score $\ge$ 0.6 or active threat intel), P2 (Score $\ge$ 0.4 with partial evidence), and P3 ($\le$ 0.4 or effectively mitigated).
* The instruction specifies not to file P3 findings as security issues.
* Validation involved testing against an application containing ten known vulnerabilities, including WAF rules and IAM controls.
* The steering file resulted in finding nine of ten vulnerabilities and correctly downgrading two mitigated findings to P3 with rationale.

The narrative centers on the principle that consistency in security assessment is achieved not through better models, but through superior methodology engineering—the steering file. The core implication is a critique of relying on the inherent, unconstrained capabilities of frontier models for high-stakes tasks. The system shifts the locus of reliability from the model's generative ability to the externally enforced constraints provided by the instructions.
The pattern observed is an attempt to inject formal, mathematical rigor into inherently subjective security judgment. By replacing intuitive confidence with quantifiable, binary structural signals and explicit multiplicative rules, the authors are attempting to mitigate the inherent unpredictability of LLM reasoning in areas where small errors lead to significant real-world risk (hallucination). This mirrors a necessary pattern in complex system engineering: abstracting ambiguous human intuition into deterministic, verifiable steps.
The mechanism for controlling this is powerful but introduces a new layer of dependency: the quality of the initial encoding of the methodology. The distinction between technical controls (like IAM) and attack-blocking controls (like WAF) highlights a systemic gap where general reasoning fails to account for specific architectural contexts unless explicitly mapped—a common failure point in translating high-level policy into executable code. The final constraint against filing P3 findings as security issues addresses the organizational friction caused by low signal-to-noise ratios, advocating for engineering focus based on validated evidence rather than raw output volume.
Bridge Questions: If the weights used for confidence scoring are adjusted empirically based on a specific organization's risk tolerance, how does that change the perceived urgency of P1 versus P2 findings? What is the cost associated with maintaining perfect adherence to infrastructure-aware assessment rules across diverse deployment environments? How can static analysis tools be effectively integrated to provide the "programmatic taint tracking" that the steering file currently omits, and what are the limitations of this separation?