About Fly.io

We're building a public cloud that runs on our own hardware all over the world. Customers hand us containers; we convert them into micro-VMs under hardware virtualization, each with its own kernel, on thousands of bare-metal hosts we operate ourselves. A growing share of those workloads are AI agents and inference, which means a growing share of the people attacking cloud platforms are interested in us.

Isolation is the product. The boundary between one customer's workload and the next, and between any workload and our own control plane, is a stack of things we build and run: the VMMs and their jailers, seccomp filters, host networking rules, the identity each host presents to the rest of the fleet, and the custom kernel underneath all of it. When that boundary holds, nobody notices. That's the job.

The Role

We have a security team. It covers application security, trust boundaries and auth, vulnerability research against our own hypervisor stack, corporate security, compliance, and disclosure. What it doesn't have is someone who works alongside the platform team hacking on the platform itself: the kernel, the hypervisor jailers, the syscall filters, host network isolation, and the trust relationships between hosts. That's the gap this role closes.

The work has two halves, and you will own both:

Keep the guest in the VM. Harden the per-workload boundary on every host.
Plan for the worst. Limit the blast radius for when the next horrible KVM guest-to-host escape drops.

You will report to the Head of Security, who will set your priorities and review your work, but you will spend most of your day with the Platform team, who own the systems you will be changing. Coordination and communication will be just as important as raw technical skills.

What You'll Be Doing

Isolation and sandboxing. We run two VMMs, Firecracker and Cloud Hypervisor, with jailers around them. You will own the syscall filtering, the process-level confinement, the network confinement around the jailers, and the violation telemetry that feeds our detection pipeline, across both VMMs and the host services that make up the platform.

Host network isolation. A lot of our fleet's isolation rests on nftables and friends. You will own what each host is allowed to talk to, by role, and the health checks and killswitches that tell us the rules in force are the ones we intended.

Blast radius and control-plane trust. The second half of the job. You will own the trust model between hosts and the control plane: how a host identifies itself and how its actions are attributed, how host-to-host operations such as machine migration are authorized, which services run on hosts that also run customer workloads, and what credentials live on a host and what each one can reach. You will design this with the Platform and Networking teams, build the host-local pieces yourself, and verify the rest.

The kernel. We build and patch our own host kernel. You will own the patching cadence and its SLA, keep kernel expertise spread across the fleet team rather than concentrated in one person, and own live kernel patching for the fixes that cannot wait for a reboot cycle.

Agent workloads. The platform increasingly runs agents, including a sandbox product for them. You will take the isolation half of that design seat: VMM confinement, worker-side controls, and what the platform can honestly guarantee an agent workload. This may even include compute where we no longer own the metal, and we will need to design for a fleet that spans trust levels.

When it breaks. A suspected guest escape, a host behaving strangely, weird kernel behavior: these need someone who can lead the technical investigation on the host, not just coordinate it. You will be one of the names we call, and you will help strengthen our forensics playbook.

You will want to be comfortable working with coding agents. We lean on them hard, and the honest truth of low-level security work is that an agent will confidently hand you a kernel patch that is subtly wrong. You will need to be the person who catches it.

Who We're Looking For

You've shipped non-trivial Linux kernel, KVM or hypervisor, or BPF security work in production.
You have production experience with seccomp filters, jailer or sandbox configuration, or VM isolation hardening.
You have one anchoring domain (kernel and sandboxing, or host networking) with credible reach into the others. You will ramp across the rest over 6 to 12 months.
You've run hardware virtualization on hardware you didn't control: bare-metal cloud instances, nested virtualization, or hosts in a customer's account. Not required, but definitely nice-to-have.
You've been the platform-security specialist on a security team before, and you've shipped security work in a matrixed org by collaboration rather than authority.
You're comfortable being the technical authority on low-level work without a more senior security engineer above you.
You write well asynchronously. Most of Fly happens in Slack threads and written design discussions.

This is not an application-security role. If your background is primarily SAST, code review, or web app pentesting, we already have that lane covered.

Other Important Things to Know

We don't want to sell you a bill of goods. A few things about this role are genuinely hard:

You will be the depth. Nobody in the security function can backstop you on kernel, syscalls, BPF, or network isolation. Your technical sparring partners are our vulnerability researcher and the Platform and Networking teams, and those are relationships you will build.
Much of the work lives in systems other teams own. You will change code in the platform and networking repositories, and those teams are busy. Getting things shipped depends on collaboration and clear writing more than on org-chart authority. The reporting line is designed to protect your priorities, not to let you dictate theirs.
The scope is real and the structure is thin. There's no backlog handed to you. Work surfaces from incidents, from Slack, from the fleet. You will manage your own scope, and that is harder than it looks.
We're on call, and our stuff is global. When isolation breaks, customers notice, in every time zone.

Extrapolate the bad implications, then ask us about them, and we'll be candid.

Our Process for Hiring

This is a senior, fully-remote, full-time position. We offer competitive equity grants with a long exercise window, health care benefits, flexible vacation time (with a minimum), and hardware and phone allowances.

We respect career experience but we aren't hypnotized by it, and we don't trust resumes or interviews to tell us who can do this work. Instead we show you the kind of work we actually do and see if you enjoy doing it. The process is about five hours of your time end to end:

Short written application. A few questions about your background and how you work.
Work sample (async, 2 to 3 hours). A kernel live patch for a recent CVE on a preconfigured environment we give you, a short critique of an AI-generated attempt at the same patch, and a paragraph on how you used AI tooling along the way.
Phone Screen - 15-20 min HR Phone Screen
Workday (live, 2 hours). You and one of our platform engineers will work a host-isolation scenario together over Slack. Coding agents are welcome; we want to see how you drive one.
Final (30 minutes). A conversation with our CEO.

Platform Security Engineer