Fractile is a UK AI hardware startup building next-generation inference chips and systems for frontier AI.
<h1><strong>Member of Technical Staff - Security Engineering</strong></h1> <h3><strong><em>London or Bristol · Hybrid · Permanent</em></strong></h3> <h2><strong>About Fractile</strong></h2> <p>Fractile was founded in 2022 on the bet that, eventually, the world’s most capable AI systems would be limited in their impact by the time taken to produce useful outputs. We bet everything on the logical conclusion: that the only way to truly unlock this latent value, to make speed viable at scale, was to radically re-invent the hardware that we run our frontier AI models on. Ever since, we have been building chips and systems that tackle this problem: how to efficiently generate output at thousands of tokens per second, while handling the complexity and capacity challenges of operating large models at very long contexts.</p> <p>The workloads that push to the limits of the current frontier are already transformational; it is the technical and economic limits on inference speed that are constraining progress. The defining work of the 21st century will be marked by the engine of inference delivering immense and diffuse chains of intellectual inquiry, in drug discovery, in software engineering, in materials discovery, in any field where progress is driven by deep reasoning and intelligence to resolve complex problems.</p> <h2><strong>The role</strong></h2> <p>We build the control chain that powers on, monitors, updates, and protects devices and racks across bare metal, RTOS, and embedded Linux. We also build the communication mechanisms that connect devices to each other and to the host. Security runs through all of it. A chain of trust from the hardware up to the rack management plane: the root of trust each controller boots from, the signed updates that reach the fleet safely, the identity that lets a device prove what it is, the authenticated channels the controllers and devices talk over, and the runtime protections that keep the host Linux kernel and the on-die firmware trustworthy long after boot. These are the layers that let operators rely on the hardware.</p> <p>You’d be deeply involved in that security across the chain, making it real in software. You’ll work hand in hand with our architecture and hardware teams, bringing the software and system-level view: turning threat models into concrete mechanisms in bare metal, RTOS, and Linux, then designing, prototyping, and validating them. Some of the calls in this model are still open, and you’ll help shape them.</p> <p>We want engineers who understand security from the inside out. You know how the root of trust, boot chain, key hierarchy, and secure interconnects actually work under the hood, not just how to switch them on. In this role, the security of your software solutions depends entirely on how well you understand the hardware beneath it. Some of the protections we rely on live in silicon, some in software, and part of the skill is knowing which belongs where. We’re looking for people who know both sides well enough to build the mechanisms that close whole classes of bugs by design.</p> <p><strong><em>We’re not heavy on levels here! </em></strong>Whether you’d call yourself senior, staff, principal, or lead, what matters is depth of security judgement, system-level experience, and working well with the engineers around you. If you’ve worked deep in the security of real systems and like to get your hands on the code and the systems around it, we’d like to hear from you.</p> <h2><strong>What you’ll do:</strong></h2> <ul> <li>Shape the security of the control chain (device, board, chassis, and rack controllers): threat models, trust boundaries, and a coherent secure-by-design approach across all platforms</li> <li>Design and help build secure boot and the root of trust on each controller: verified/measured boot, signing and verification, anti-rollback, and locking down debug and privileged access in production</li> <li>Secure the interconnects, between controllers and between devices and the host, with authentication, integrity, and additional protections where needed</li> <li>Design and build the cryptographic mechanisms: key hierarchies, provisioning and storage, device identity, and remote attestation so the fleet can prove what it’s running</li> <li>Make firmware updates safe end to end: signed images, rollback protection, staged rollout, and clean recovery, across every hop of the chain</li> <li>Protect the running system, not just boot: harden the host Linux kernel and the on-die firmware</li> <li>Work closely with hardware and the rest of the software team to build security into the product, running threat-model reviews, triaging vulnerabilities, and driving fixes to closure</li> </ul> <h2><strong>What we’re looking for:</strong></h2> <p><em><strong>We expect you to know the fundamentals, and to have real, practical experience across several of these:</strong></em></p> <ul> <li>An adversarial mindset and sharp threat-modeling instincts: trust boundaries, assets, attacks, and honesty about residual risk</li> <li>Hands-on experience with the core security primitives in software and in silicon: secure boot, root of trust, cryptography, and key management, including how they’re implemented and where they can fail</li> <li>Secure protocol and channel design between components</li> <li>Strong C and Rust, and the instinct for memory safety and defensive coding that low-level security work needs</li> <li>Experience building, not just using, security mechanisms: a secure-boot chain, key hierarchy, or attestation flow you shaped</li> </ul> <p><em><strong>That’s the core. We get especially curious about your application when you also bring some of the following. Very few candidates tick every box here, and we don’t expect you to:</strong></em></p> <ul> <li>Attestation at boot and at runtime, and management-plane protocols (DICE, IETF RATS, SPDM, MCTP, PLDM; confidential-computing directions like TDISP)</li> <li>Hardware building blocks and firmw