AI-Native Detection and Triage Engineer

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.

We put a lot of work into the isolation boundary. This role is about everything that tells us whether it is holding: knowing, in near-real-time, when something has crossed it in production, finding the bug in the code before anyone gets the chance, and running every one of those signals to ground.

This Role Fly's Head of Security covers application security, trust boundaries, and the compliance program. A vulnerability researcher spends their time breaking our own hypervisor and kernel stack. A Platform Security Engineer, hiring in parallel with this role, will own isolation on the hosts. The seat we are adding will own the signal: from the fleet and from the code, through one triage pipeline, to a fixed root cause. That will be you.

Two sources will feed that pipeline. The first will be signal from the running platform: eBPF sensors on every host, the SIEM they land in, and the detections that fire on it. The second will be the code: agents that review every merged PR, dependency and image scanning across our repositories, and a full local replica of the platform where we scan, fuzz, and test the whole stack. Both feeds will land in one triage tool, and you will own what reaches it, how it is enriched and prioritized, and what happens next.

AI-native means two things here. You will build with coding agents as a matter of course. And the pipeline itself will be agentic: agents will safely triage, correlate, and enrich findings before a human sees them. You will design and operate those agents and you will be the person who can tell when one of them is wrong.

What You'll Be Doing Signal from the fleet. We run eBPF sensors across the hosts, feeding a SIEM. You will own what the sensors watch, their lifecycle across our kernel versions, and their path into the pipeline. You will own detection coverage for the scenarios that matter most on a platform like ours: spotting a compromised host and the lateral movement that follows, noticing control-plane access patterns, operator access to customer machines, secrets access, and abuse of AI workloads and the credentials inside them.

Signal from the code. Agents already review every merged PR for security issues; you will own them, their prompts, which repositories they watch, and so forth. You will own dependency, image, and SBOM scanning across the codebase. And you will help build out our local replica of the platform: QEMU/KVM Fly hosts running nested Firecracker, with the real control plane running as machines inside the cluster. You will help build its CI and its fuzzing and testing harness, so that isolation regressions, scanner findings, and new attack surface are properly exercised against a full stack in a sandbox before they reach a customer.

The triage pipeline. You will also own one prioritized inbox over SIEM alerts, scan findings, vulnerabilities, failing checks, and inbound disclosures, with the dispatch and closure workflow behind it. You will own what feeds it and the contract each producer writes against. You will build the agents that triage, deduplicate, correlate, and enrich findings before a human deals with them.

Running things to ground. A finding is not done when it is filed. You will funnel alerts and scan results to the teams that own the code or the hosts, work with them to a root cause if needed, and see the fix land and the detection or scanner confirm it. Much of this job will be that loop: a dozen owning teams, a steady stream of signal, and one person making sure nothing stalls between "fired" and "fixed."

Hunting and incidents. You will hunt on a cadence, not just when something is on fire. When something is on fire, you will lead the detection and triage side of the response: what fired, what should have fired, which other hosts or services are affected based on the signal we already have. You will own the detection side of our forensics playbook; the Platform Security Engineer will lead the host side.

You will want to be very comfortable working with coding agents. We lean on them hard, and you will be building with them as well as building them.

Who We're Looking For

• You've built detection or security-scanning pipelines against real systems and shipped them to people who depended on them. You can talk about where they failed.

• You can read Linux auth, audit, and kernel logs at the source, and you can read a Go, Rust, or Elixir diff well enough to tell a real finding from scanner noise.

• You've worked with eBPF-based telemetry (Tracee, Falco, Tetragon, or your own) in production, or you can show us something equivalent.

• You've put security tooling into CI, and you've worked with fuzzers or test harnesses (AFL, libFuzzer, syzkaller, or your own) or can show us you would pick them up fast.

• You've built agent or LLM tooling against operational data and designed around prompt injection as an engineering constraint.

• You've led or been deep in incident response and can explain a hunt you ran and what it found.

• You've run findings to ground across teams you did not manage, and you can describe how you kept that moving without authority.

• You write well asynchronously. Most of Fly happens in Slack threads and written design discussions.

This isn't a SOC analyst role. If your background is reading alerts from a vendor-managed platform and escalating them, this is a different job. It also isn't a "prompt engineer" role: the agents here will summarize logs and diffs you will have to be able to read yourself. And it isn't a scanner-operator role: running the tool is the easy part, deciding what it should look at and what to do with what it finds is the job.

Some Other Important Things to Know

Some messy things we want you to know

• You will be building, not inheriting. This is a new seat, and while the detection and triage tooling exists, you will be bringing it under one umbrella. The first six months are foundational, and you will be doing the foundation while incidents are happening around you.

• You will be the depth. Nobody above you in the security function can backstop you on detection engineering. Your sparring partners are the Platform Security Engineer, our vulnerability researcher, and the Platform and Infra teams.

• You will spend a lot of time in other people's code and other people's queues. Running a finding to ground means working with the team that owns it, and those teams are busy. Clear writing and good judgment about what is worth their time matter as much as the tooling.

• The scope is real and the structure is thin. There's no backlog handed to you. Work surfaces from incidents, from scanners, from Slack, from the fleet. You will manage your own scope.

• We're on call, and our stuff is global. When something crosses a boundary, we want

Our Process

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). We will give you an environment with a read API over a synthetic slice of our signal: host logs, admin state, a handful of SIEM alerts, and a batch of scanner findings, some of it seeded with prompt-injection payloads. You will build a small agent that finds the planted anomalies, separates the real findings from the noise, and files them without ever letting one agent context hold untrusted input, credentials, and the ability to act at the same time; critique an AI-generated attempt that gets the boundary wrong; and write a paragraph on how you used AI tooling along the way. This is the real filter.

• HR Screen - 15-20 mins

• Workday (live, 2 hours). You and one of our engineers will work an incident scenario together over Slack from the detection side: what fired, what should have, and how to find the other affected hosts from the signal we have.

• Final (30 minutes). A conversation with our CEO.