TL;DR: Context, not model choice, determines whether AI security automation makes correct decisions, according to Pixee research showing that injected code and security context raised repair performance from 15% to 63% and that similar gains appeared in repository-aware program repair. The practical lesson is that security teams need curated, validated context layers, not bigger prompts.
NHIMG editorial — based on content published by Pixee: Context Engineering for Security: Why Context, Not the Model, Decides the Fix
By the numbers:
- Injected security and code context raised one model's buffer-overflow repair rate from 15% to 63%.
- Repository knowledge on top of bug-report context raised Llama 3.3's fix rate from 65% to 74%.
- More recent work found that input length alone can degrade performance by 13.9% to 85% even when the relevant facts are retrievable.
Questions worth separating out
Q: How should security teams govern AI systems that can both triage and remediate alerts?
A: Treat them as privileged non-human identities with explicit ownership, scoped permissions, and revocation paths.
Q: Why do AI security fixes fail when the model has only code snippets?
A: Because snippets omit the surrounding facts that determine exploitability and safe remediation.
Q: How do you know whether context engineering is actually working?
A: Look for lower false-positive rates, higher merge rates on proposed fixes, fewer escalations caused by missing ownership, and better alignment between AI recommendations and policy.
Practitioner guidance
- Define the context inputs for each AI security decision Document which code, runtime, ownership, policy, and criticality inputs must be present before an AI can triage a finding or propose a fix.
- Separate code context from governance context Map the technical facts a model needs to the organisational facts it also needs, including service ownership, approved patterns, and escalation rules.
- Require traceable decision evidence Capture what context was retrieved, how it was ordered, and why the recommendation was accepted so reviewers can audit AI-assisted security decisions.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- Controlled study results showing how injected security and code context changed repair outcomes across vulnerability classes
- A deeper explanation of context graphs, retrieval order, and validation steps that make AI-assisted fixes reviewable
- Lifecycle examples showing how design-time review, triage, and remediation each need different context inputs
- The article's comparison of code context versus program context, including ownership, policy, and workflow metadata
👉 Read Pixee's analysis of context engineering for security decisions →
Context engineering for security: is your AI making correct decisions?
Explore further
Context engineering is becoming the control plane for AI-assisted security decisions. When the model is commoditised, differentiation moves to the quality, provenance, and ordering of the context it receives. That is especially relevant in security, where a wrong answer is not a stylistic problem but a governance failure. For NHI and IAM programmes, the same logic applies to machine-driven access decisions, secret handling, and remediation workflows. The practitioner takeaway is that context quality now belongs in control design, not just in tooling selection.
A question worth separating out:
Q: What is the difference between context engineering and prompt engineering for security?
A: Prompt engineering shapes the instructions you give a model. Context engineering governs the full set of information the model can use, including retrieved data, code relationships, workflow metadata, and historical decisions. In security, that broader discipline matters more because the quality of the answer depends on the quality and completeness of the decision context.
👉 Read our full editorial: Context engineering for security is the real AI control plane