Senior Security Engineer, Trail of Bits

• Red teaming. Direct experience with red teaming production software, personally responsible for finding and proving exploitable vulnerabilities. Hands-on offensive work, not exercise coordination or scanner triage
• Building AI tools that find bugs. Experience building AI-driven tooling for vulnerability discovery, such as agentic harnesses, LLM-assisted triage pipelines, or automated exploit generation. You have written this tooling, not only used someone else's
• Formal methods. Experience applying formal methods to system designs and code implementations, including reading specifications and proof artifacts and reasoning about what a machine-checked proof does and does not establish. You can read at least one of Lean, Rocq, F*, Dafny, or Verus/Rust
• Depth in a systems domain. Experience finding vulnerabilities in network protocol implementations, operating system internals, open-source software, cryptographic implementations, or AI inference infrastructure
• Software development. Experience in Python, C++, and/or Rust
• Written findings for expert readers. Experience producing security assessment reports for an audience that will scrutinize every claim
• Delivery to a fixed external schedule with defined acceptance criteria
• Vulnerability Disclosure. Experience in the ethical reporting of vulnerabilities in technology

Desirable

• AI has transformed the cost curve for formal verification. Network boundaries, infrastructure, operating system components, cryptographic libraries, and proof-checking kernels can now ship with genuine mathematical guarantees attached, and those guarantees are narrower than the word "verified" leads anyone to believe. We are looking for candidates who have both the rigor to read a proof and say exactly what it establishes, and the instinct to find what it left out
• Day-to-day, you will evaluate specifications alongside their designs and proofs, and determine what has actually been established versus what has merely been assumed. Then, using state-of-the-art tools and frontier AI models, you will go after everything the proof does not reach. Some of what you find may be ordinary memory corruption. More of it will be a threat model that ignores a real attacker, a trusted computing base that does not survive deployment, or a sound proof of a property adjacent to the one that matters
• Red-team evaluations are scheduled for a one-week sprint with seven weeks to prepare. The tooling you build during that time determines how much ground you cover once the window opens. Trail of Bits is AI-native, and we expect AI to drive the bulk of our evaluations with agentic harnesses, triage pipelines, automated exploit generation, and systems like , our cyber reasoning system that placed second at DARPA's AI Cyber Challenge
• You will work in small teams and with third parties and report to a domain lead in applied cryptography and proof systems, operating system internals, applications, hardware, or AI infrastructure. Several engagements will run simultaneously and remain separate, so holding information where it belongs matters as much as the technical work. Occasionally, you will attend sprints and hackathon events in London
• Break systems built to resist you. Compromise designs and production software whose authors had a proof assistant on their side, and demonstrate it with a working exploit rather than a written argument
• Map the real attack surface of a proof. Establish the formal property, the level it holds, the threat model behind it, and the underlying assumptions, then show the client which of those give way under pressure
• Build the tooling that decides your coverage. Design and extend the AI-driven discovery and triage systems that determine how much of a target a single engineer can reach within a short window
• Write the assessment that becomes the record. Set out what held, what did not, and what you attempted without success, clearly enough that the result stands up to the product developers
• Raise the practice around you. Publish tooling and methodology, write for the blog, present internally, and pull what one engagement learns into the next