Anthropic developed an agentic harness system to help security teams discover, verify, and patch code vulnerabilities at scale using Claude. The system addresses the challenge that while frontier AI models have dramatically increased the number of vulnerabilities that can be found (Mozilla Firefox saw findings increase 20x in April alone), the bottleneck has shifted from discovery to verification, triage, and patching. Through a six-step process involving threat modeling, sandboxed testing, discovery, verification, triage, and patching, teams working with Anthropic achieved true positive rates of up to 90% while automating much of the security workflow, with over 1,600 vulnerabilities reported to maintainers and 100 patched upstream from scanning 1,000+ open source repositories.
This case study describes Anthropic’s work with security teams to deploy Claude in production for identifying and fixing code vulnerabilities at scale. Eugene U from Anthropic presented lessons learned from working with dozens of organizations to improve their security posture using AI models. The presentation focuses on how frontier AI models have reached a capability threshold where they can meaningfully assist in cybersecurity tasks, but also highlights the operational and organizational challenges that emerge when deploying these systems in production.
The context for this work is significant: the UK AI Security Institute’s time horizon benchmarks show that models are increasingly capable of completing longer cybersecurity tasks, with recent models showing a step-change improvement over previous generations. This capability improvement has translated into dramatic real-world impact. Mozilla Firefox provides a compelling example: their average monthly security bug fixes in 2025 was around 20, but this jumped to 60-70 in February-March and then spiked to 400 in April, representing a 20x increase over the previous year’s average. Mozilla attributed approximately two-thirds of these findings to Claude, demonstrating that frontier models can help defenders find and fix vulnerabilities at unprecedented scale.
Anthropic’s own security research scanning over 1,000 open source repositories identified 23,000 vulnerability candidates, of which 6,200 were rated as high or critical severity. At the time of reporting, 1,600 had been reported to maintainers and approximately 100 had been patched upstream. This volume of findings led to a critical insight: finding vulnerabilities is now relatively straightforward with modern AI models, but the bottleneck has shifted to verification, triage, and patching. The entire LLMOps implementation described in this case study is designed to address these downstream bottlenecks.
The production system that most teams converged on consists of six steps, with the first two being setup phases and the remaining four forming an iterative loop. This architecture reflects fundamental machine learning principles applied to security workflows, with each step optimizing for different objectives.
Threat modeling provides critical context that dramatically improves model performance. Multiple teams reported that having a well-documented threat model increases true positive rates to 90%, a remarkably high precision for this type of work. The fundamental challenge, as one CISO articulated, is that “the model has great context of the code but poor context of the system.” Models can read and understand code exceptionally well, but they lack implicit knowledge that exists only in the minds of senior designers, on-call engineers, and security teams—knowledge about why systems were designed in certain ways, what vulnerabilities have been fixed historically, and what compensating controls exist elsewhere in the infrastructure.
The threat modeling process itself can be AI-assisted. Teams bootstrap threat models by giving models access to all documentation, code, past commits, and previous patches linked to CVEs, then asking the model to infer what other vulnerabilities might exist that haven’t been patched. After this bootstrapping phase, models conduct structured interviews with system experts to capture information that isn’t in the code, such as whether an application runs on an internal VPN only, what compensating controls exist (like application firewalls), or what the sensitivity level of the data actually is.
For the hypothetical order service example used throughout the presentation, the threat model identifies key assets (customer PII data), entry points (the orders API), and possible threat vectors like SQL injection and unauthenticated API access. This documented context becomes crucial input for all subsequent steps in the pipeline.
The sandbox provides isolation and reproducibility, both critical for production deployment. Isolation is necessary because the system may run untrusted code or deliberately detonate proof-of-concept exploits to verify vulnerabilities are real. These operations must occur in VMs without egress and without cloud credentials to prevent data exfiltration or accidental damage to production systems.
Reproducibility ensures that all agents in the pipeline start from the same baseline state. This consistency is essential because vulnerabilities might only manifest with specific dependency versions or configurations. As one team noted, having the model test against live systems in sandboxes where they can run and detonate proof-of-concept exploits was “the biggest lever we had” for confirming true positives.
For the order service example, the sandbox consists of three Docker images: one for the application, one for the Postgres database, and one for the Redis cache. A security agent sits outside this target boundary, probing the application via HTTP, mimicking how an external attacker would interact with the system.
The discovery phase focuses on finding as many vulnerabilities as possible, optimizing for recall rather than precision. Three factors emerged as critical for discovery performance:
Context engineering is paramount. Teams found that providing comprehensive context to the model—all available documentation, system designs, threat models, past incidents—directly improves vulnerability coverage and reduces false positive rates. The principle is simple: if information is written down and shared with the model, the model can leverage it to become a better security engineer.
Prompt engineering has evolved significantly as models have improved. Multiple teams reported that with each new model generation showing step-change capabilities, they actually needed to reduce prompt specificity by approximately 50%. Earlier models required prescriptive instructions about specific vulnerability categories to look for, but newer models perform better with simpler, more abstract guidance like “look for where untrusted data hits the trust boundary.” The model can infer the specific vulnerability types from this higher-level instruction.
Tool access is essential for high-quality discovery. One pentesting team that gave the model tools to query APIs, check responses, read logs, and read source code achieved a true positive rate near 100% because the model could dynamically verify findings during the discovery process itself. This represents a shift from expecting models to find vulnerabilities purely through static code analysis to enabling dynamic testing capabilities similar to what human security engineers use.
In the order service example, the discovery agent identified a SQL injection vulnerability in a five-line API function where user input flows directly into a SQL query through Python string interpolation. This is precisely the type of vulnerability that modern models excel at identifying, even though a non-security-focused engineer might easily write such code.
Verification operates independently from discovery and optimizes for precision. This separation is architecturally important: when discovery agents try to verify their own work in the loop, they may self-censor, which hurts recall. By separating these concerns, each can optimize for its specific objective.
The verification agent is designed to be both independent and adversarial. “Independent” means the verifier doesn’t see the reasoning traces or work of the discovery agent—it receives only the vulnerability report and location. “Adversarial” means the verifier assumes the vulnerability is false and attempts to disprove it. This sets a high bar that reduces false positives.
The most effective verification involves detonating proof-of-concept exploits in the sandboxed environment. For the order service SQL injection, the verification agent is given only the line number and vulnerability type, then attempts to exploit it by running curl commands. When the agent successfully exfiltrates customer PII from the database, the vulnerability is confirmed as a true positive with high confidence.
Triage addresses a critical production challenge: engineer attention is the scarcest resource. Multiple teams reported that sending product engineers all true positive vulnerabilities, even medium and low severity ones, caused them to lose trust and become overwhelmed. Engineers can’t cope with hundreds of findings; they need the top 10-20 critical and high-severity issues.
Triage involves deduplication (using heuristics or AI clustering), severity assessment based on both magnitude of impact and likelihood of exploitation, and crucially, business context. The threat model becomes essential again here. A vulnerability that appears high severity based purely on technical factors might actually be low risk due to compensating controls like firewalls, or because the service is internal-only. Conversely, a technically medium-severity vulnerability might be elevated to high if it affects healthcare data or customer PII.
For the order service SQL injection, the initial automated triage rated it as high severity due to high impact (customer PII exposure) and high likelihood. However, after human review, it was downgraded to lower likelihood because an application firewall blocks SQL injections and the service is internal-only for warehousing logistics. This kind of contextual adjustment requires information that isn’t in the codebase—it exists in system designs, documentation, or institutional knowledge. The LLMOps challenge is ensuring this context is captured and made available to the model.
The patching phase generates fixes and validates them through multiple levels of rigor. The basic requirement is that the original proof-of-concept exploit must stop working. The second level ensures existing test suites remain green, preventing regressions. The third level, which teams found particularly valuable, involves having a fresh discovery agent attack the patched code to verify the fix is comprehensive and doesn’t leave related vulnerabilities.
This represents a generate-verify loop where agents receive feedback and iteratively improve patch quality. Human review remains the final gate before patches are merged to production. For the order service, the patch is a one-line change moving the variable out of Python string interpolation to use parameterized queries. Critically, the patch also updates the threat model documentation to clarify compensating controls (the application firewall) and system context (internal-only use). This closes the loop: the next time the scanning harness runs, it has better context and won’t flag this as a high-severity issue.
The case study reveals several important LLMOps principles for production deployment:
The architecture is fundamentally an ML pipeline. When viewed abstractly, the six steps map directly to machine learning concepts: recall optimization (discovery), precision optimization (verification), ranking (triage), and continuous improvement through feedback loops (patching with updated context). This framing helps teams understand how to operationalize the system.
Context is everything. The repeated emphasis on threat models, system documentation, and business context highlights that LLM performance in specialized domains depends critically on providing comprehensive, well-structured context. This is more than prompt engineering—it’s about systematically capturing and encoding organizational knowledge that exists implicitly in people’s heads.
Separation of concerns improves outcomes. Having independent agents for discovery and verification, each optimizing for different objectives, outperforms having a single agent try to do both. This prevents issues like self-censorship and allows each component to be tuned independently.
Sandboxing and reproducibility are non-negotiable for security applications. The ability to safely detonate exploits and ensure consistent testing environments is what enables high-precision verification. Building representative sandboxes is difficult but provides enormous leverage.
The system converts operational expense to capital expense. Each iteration improves the threat model, adds test cases, and refines context, making subsequent scans better. This is a critical characteristic of production LLMOps systems: they should get smarter over time, not just execute the same operations repeatedly.
The presentation explicitly addresses that “non-technical problems are an order of magnitude harder than technical problems.” When a system increases input volume by one or two orders of magnitude, technical challenges can often be solved by adding compute and spending more money. But human attention doesn’t scale.
Three organizational bottlenecks were identified:
Vulnerability routing becomes unmanageable when findings increase from dozens to hundreds per month. Manual curation and Jira ticket assignment doesn’t scale. Solutions involve automated routing to code owners or service owners, which doesn’t necessarily require LLMs but does require process automation.
Severity calibration requires alignment between product and security teams who may have different mental models of what constitutes “high severity.” This requires getting everyone in a room, documenting agreed-upon criteria that incorporate business context, and encoding those rules so both humans and agents can apply them consistently.
Patching bandwidth becomes constrained. While few engineers now write code entirely by hand, asking engineers to implement patches even with LLM assistance is less efficient than providing AI-generated patches for human verification. The workflow should move toward generation-verification rather than assisted implementation.
The presentation emphasizes starting now rather than waiting for perfect solutions. Three recommendations stand out:
Begin with open source dependencies, starting with whatever you’re comfortable with. This provides a safer learning environment than immediately applying tools to production codebases.
Climb the learning curve interactively before pursuing full automation. Use tools like Claude in an IDE with “hands on the wheel,” learning where precision is low, what context is missing, and where the process gets stuck. This hands-on experimentation builds intuition about what works before committing to automation.
Don’t aim only for scanning. Scanning is no longer the bottleneck. Focus investment on verification, triage, patching, and organizational processes where the real constraints lie.
The case study presents compelling evidence of AI models’ capabilities in security work, but several considerations deserve attention:
The dramatic Mozilla Firefox statistics (20x increase in findings) are impressive but raise questions about sustainability. Can engineering organizations actually address this volume of findings? The presentation acknowledges this by emphasizing triage and prioritization, but the organizational change management required to absorb this increased workload is substantial.
The 90% true positive rate claim is exceptional and depends heavily on having excellent threat models. Organizations without mature security practices may struggle to create the foundational context required to achieve these results. The system’s performance is only as good as the context provided.
The separation between discovery and verification, while architecturally sound, adds complexity and latency to the pipeline. Organizations need to weigh the improved precision against increased operational overhead.
The emphasis on sandboxing and reproducibility is appropriate but represents significant infrastructure investment. Building representative sandboxes that mirror production systems accurately enough to verify vulnerabilities is non-trivial, particularly for complex distributed systems.
The human-in-the-loop requirement for patch approval suggests that full automation remains distant. This is appropriate for security-critical work but means the human bottleneck persists even with sophisticated AI assistance.
The presentation focuses heavily on Anthropic’s Claude, which is natural given the speaker’s affiliation, but organizations should evaluate whether similar results can be achieved with other frontier models or whether there are specific capabilities that differentiate Claude for this use case.
Overall, this represents a sophisticated and thoughtful approach to production LLMOps for security applications, with careful attention to both technical architecture and organizational challenges. The framework is generalizable beyond security to other domains where AI can dramatically increase the volume of candidates that need human verification and triage.
Cognition, the company behind Devon, discusses their journey building production-ready autonomous coding agents that operate in cloud environments. The conversation with Walden Yan (Co-founder, CPO at Cognition) and Cole Murray (creator of Open Inspect) explores the architectural decisions, infrastructure challenges, and production considerations for deploying AI agents that can autonomously write, test, and merge code. They discuss the shift from local IDE-based AI assistants to background agents that work autonomously in cloud environments, the technical infrastructure required to support this paradigm (including VM management, sandbox security, and state management), and real-world use cases like automated incident response, customer support triage, and continuous security scanning. The discussion covers how Devon now contributes 80% of commits on Cognition's repositories (up from 16% in January), representing a fundamental shift in how engineering teams work with AI.
Anthropic's platform team discusses the evolution from simple API completions to stateful, production-ready AI agent infrastructure. The conversation covers Claude Managed Agents, a platform that abstracts away infrastructure complexity for teams building autonomous agents at scale. The platform addresses the common challenge where teams prototype agents successfully but hit infrastructure walls during productionization, particularly around sandboxing, state management, and async execution. By providing opinionated primitives like file systems, skills, and memory while maintaining modularity, the platform enables both internal teams and external customers to deploy long-running agents without managing servers, credentials, or orchestration complexity.
This panel discussion brings together engineering leaders from HRS Group, Netflix, and Harness to explore how AI is transforming DevOps and SRE practices. The panelists address the challenge of teams spending excessive time on reactive monitoring, alert triage, and incident response, often wading through thousands of logs and ambiguous signals. The solution involves integrating AI agents and generative models into CI/CD pipelines, observability workflows, and incident management to enable predictive analysis, intelligent rollouts, automated summarization, and faster root cause analysis. Results include dramatically reduced mean time to resolution (from hours to minutes), elimination of low-level toil, improved context-aware decision making, and the ability to move from reactive monitoring to proactive, machine-speed remediation while maintaining human accountability for critical business decisions.
