Finding the blind spot: How Canonical hunts logic flaws with AI Canonical has developed an internal AI-powered auditing agent called Redhound that autonomously discovered three critical logic vulnerabilities in the LXD container and virtual machine manager, bugs that had survived years of manual review and static analysis. The tool, built on frontier models, hunts for domain-specific business logic flaws that traditional scanners and fuzzing cannot detect because they involve missing code rather than pattern-based errors. Redhound found the zero-days in under a day of unsupervised analysis, demonstrating that AI can now reason about complex security blind spots previously reserved for human researchers. Finding the blind spot: How Canonical hunts logic flaws with AI Miha Purg /blog/author/mihap on 15 May 2026 Tags: AI /blog/tag/ai , Security /blog/tag/security , Vulnerabilities /blog/tag/vulnerabilities The recent unveiling of Anthropic’s Claude Mythos preview https://red.anthropic.com/2026/mythos-preview/ has radically shifted the cybersecurity landscape. We are now in an era where AI can autonomously discover and exploit zero-day vulnerabilities in mature codebases at machine speed. Perhaps the most exciting revelation from the Mythos preview was the demonstration that frontier models can now successfully reason about complex, domain-specific business logic bugs – a class of vulnerabilities historically reserved for human security researchers. Earlier this year, I began developing an internal AI-powered auditing agent called Redhound to proactively hunt for these exact blind spots. Built on frontier models, Redhound puts that reasoning to work against our own codebases at Canonical. Redhound has already proven its value, recently uncovering three critical logic vulnerabilities in LXD, our container and virtual machine manager. These bugs had survived years of manual review and static analysis. Redhound found them in under a day of unsupervised analysis. Below, I break down the mechanics of this adversarial pipeline, the technical details of the three zero-days now patched and disclosed , and how agentic auditing changes the way we secure infrastructure. The bugs that fall through every other tool Static analysis handles pattern-matching problems well: injection sinks, unsafe API calls, and dangerous concatenations. Modern scanners were built to find these problems, and they do that work reliably. What these scanners cannot do is reason about what is missing: for example, a checklist that names three fields when the data structure has four; or a validation that reads one file while the operation it gates uses a different one. These are not sloppy code errors; they are exploitable gaps in code that reads correctly to a careful reviewer. Because the line that would close the gap does not exist in the source, a tool looking for patterns has nothing to match against. Dynamic analysis and fuzzing fail for a related reason: they need a runtime signal – a crash, a panic, a sanitizer trip. A request that should have been denied but succeeds looks identical to a legitimate one. There is nothing for the fuzzer to trip on. Manual review and penetration testing catch these bugs, but the work is time-consuming and demands substantial domain expertise. Finding the vulnerabilities by hand means combing through hundreds of thousands of lines that are correct, waiting to notice the one that isn’t. Mature codebases survive years of this and still ship logic bugs. These are the bugs Redhound goes after: the code does exactly what it was written to do, but that does not map to the intent of the security model. How Redhound works Redhound audits our codebases the way a determined human attacker would: reading a project end-to-end, generating adversarial hypotheses, dispatching agents to investigate each one, and running a separate round of agents to refute them. The pipeline runs in five conceptual phases: Deterministic Recon : Before any agent reads a single line, static-analysis tooling maps the codebase. This includes every function, type, and call edge; every HTTP, gRPC, and CLI entry point; and categorized security signals auth, crypto, deserialization, injection . Threat Modeling : An agent reads the recon graph and identifies what an attacker would want e.g., host root, cross-tenant access, a cluster admin certificate and maps the trust boundaries between an outside attacker and each target. Iterative Loop : Each cycle, a red-team agent generates a batch of attack hypotheses. Each hypothesis is dispatched to a separate investigator agent given the relevant slice of the call graph. The investigator either finds a concrete exploit path or reports the hypothesis as false. Debunking : This is the most critical design decision. Every confirmed-looking finding is handed to a “debunker” agent with the exact opposite objective. Its job is to independently read the source and find the runtime guard that kills the attack – with no anchoring from the investigator’s confidence. Impact Assessment : A technical fault in the code does not automatically equate to a security vulnerability. This final agent cross-references any finding that survives the debunker against the original threat model and the application’s defined trust boundaries. By evaluating the precise attacker prerequisites and calculating the actual privilege gain, the assessor ensures that the pipeline escalates only verifiable, high-impact exploits rather than purely theoretical issues. Only findings that survive the debunker reach a human reviewer. Redhound then generates a draft report and a runnable proof-of-concept PoC exploit to streamline the validation process. Three classes of bug The three findings are a useful sample because they represent three different classes of logic flaws. All three were assigned a final CVSS 3.1 score of 9.1 during coordinated disclosure. Vulnerability | CWE / Class | Attacker gains | Why hard to find | |---|---|---|---| | Certificate type escalation CVE-2026-34179 | CWE-915 mass assignment | Restricted certificate user to host root | A missing authorization check – no pattern marks what is not there | | VM low-level option bypass CVE-2026-34177 | CWE-184 incomplete denylist | Restricted project user to host root | An unlisted key is indistinguishable from an intentionally permitted one | | Backup restore desync CVE-2026-34178 | CWE-20 improper input validation | Restricted project user to host root | Two data flows from one input diverge across four files | Each finding below shows what Redhound actually produced: the structured metadata, the title verbatim, and the concrete trace generated by the investigator agent. Certificate type escalation CVE-2026-34179 This flaw resides in the certificate update logic where the system fails to validate the certificate “type”. A restricted certificate user can effectively grant themselves Cluster Admin privileges by bypassing type checks during a certificate update. Finding details: Title : “Restricted user can change certificate type to ‘server’ via legacy API, escalating to ProtocolCluster admin” Finding ID : thread-041 Severity : Critical confidence: exploitable Privilege gain : 10/10 Ease of exploitation : 9/10 Prerequisite prevalence : 8/10 Attacker profile : ap-002 Authenticated restricted user Source agent : thread-follower; survived the debunker CVSS 3.1 : 9.1 assigned during disclosure Exploitation trace on LXD 6.7 https://github.com/canonical/lxd/tree/lxd-6.7 eight steps, generated by the investigator : - certificates.go:49 – restricted TLS user sends PUT /1.0/certificates/