Staff + Software Security Engineer, Labs

Staff + Software Security Engineer, Labs

About Anthropic

Anthropic’s mission is to create reliable, interpretable, and steerable AI systems. We want AI to be safe and beneficial for our users and for society as a whole. Our team is a quickly growing group of committed researchers, engineers, policy experts, and business leaders working together to build beneficial AI systems.

About the role

Frontier AI is on track to be among the most consequential and most adversarially-targeted technology in the world. The capability curve is steep, the adversaries who want these systems are extremely well-resourced, and the security bar this will eventually require is well beyond where the industry operates today. Incremental hardening alone is not going to close that gap, so we need breakthroughs and a group of people to go find them.

Security Labs is that team. We run a portfolio of high-risk, high-expected-value security projects: the work that seems impractical until someone optimistic and stubborn enough actually tries it. Projects run on the order of weeks rather than quarters, and each one is either handed off to the Anthropic team that will own it in production or wound down with a writeup of what we learned. We expect a meaningful fraction of our bets not to land.

This team is intentionally scrappy and ambitious. We're intentionally iterating fast on high-risk research bets and we expect a meaningful fraction not to land. If a 30% project success rate sounds uncomfortable, or uncharted and chaotic territory isn’t both frightening and exciting, this probably isn't the right fit. There are other places in Anthropic Security doing important work with more structure, less risk, and more certain paths to positive outcomes.

The questions we're trying to answer include:

• Can our core research workflows survive extreme isolation?
• Can we replace trust with cryptographic guarantees?
• Can the models themselves become our most effective security control?
• What would it actually take to defend against a tier-1 state adversary, and how much of that can we build now?

Who we're looking for. We're hiring generalists with rare depth. You're a strong software engineer as a baseline, and on top of that you've gone deep in at least one area most engineers don't get near: firmware or hardware security, applied cryptography, OS / kernel / hypervisor internals, formal methods, reverse engineering, or high-assurance and cross-domain systems. You've built things under your own direction, you're comfortable jumping layers when the problem demands it, and you'd rather take a swing at something that might not work than ship the safe incremental thing. You think the trajectory of AI matters a great deal, you're not comfortable with how the security side of it is going by default, and you'd rather be on the inside building the answer than watching from outside.

Current Project Areas

The portfolio changes as we learn. The kinds of bets currently in flight or queued:

• Standing up a prototype high-assurance research cluster: running real Anthropic training and research workloads under extreme isolation and physical security controls, and finding out exactly where productivity breaks and what we'd need to invent to get it back
• Provable inference: cryptographic verification (zero-knowledge proofs, attestation chains) that a given output came from a specific model running specific code, replacing "trust us" with math
• Build hypervisor-isolated microVM workload isolation across the fleet
• Compiling an ML kernel through a formally verified pipeline where every lowering step carries a machine-checked proof of equivalence, making compilation-layer sabotage mathematically detectable
• Regenerating clusters: automation that spins up a purpose-built cell, runs a workload, and tears the whole thing down on a TTL measured in hours, so attacker persistence has an expiry date
• Using Claude itself to drive security work end to end: threat modeling new compute platforms, rewriting critical services to zero external dependencies, running the test equipment that validates what hardware datasheets claim

Part of your job is deciding what comes next. We hire people we trust to pick good bets, and project selection is owned by the engineers doing the work.

Key responsibilities

• Own Security Labs projects end to end. You'll scope the bet, build the prototype, run it against real workloads, and bring it to either a hand-off or a documented exit
• Stand up novel security infrastructure fast (isolated clusters, attestation chains, hypervisor and runtime work, verification tooling) optimizing for what we learn rather than for permanence
• Find the receiving team early, bring them along while you build, and hand them something they actually want to own
• Work embedded with research and infrastructure teams (Pretraining, RL, Inference, Compute) to test whether their workflows survive what you're proposing, and document precisely where they don't
• Turn experimental results into short writeups that shape Anthropic's long-term security architecture, and into costed contingency plans we could execute on short notice
• Help pick the next round of bets and influence the industry to get better along the way
• Genuinely care about where AI is heading and want to work on the security problems that determine whether it goes well. This is the most important thing on this list
• Have real depth in at least one area most software engineers don't touch (e.g. firmware or hardware security, applied cryptography, OS / kernel / hypervisor internals, formal methods and verification, reverse engineering and exploit development, or high-assurance / cross-domain systems)
• Have built and shipped things under your own direction. Maybe you founded a company or research group, maintained an open-source project other people depend on, or shipped research that changed how people in your field work. We weight this far more than where you've worked or for how long
• Have a track record of choosing the problem yourself and seeing it through, rather than only executing a plan someone else handed you
• Are comfortable jumping between domains and layers of the stack when the problem calls for it, and have actually done so
• Have run prototypes or experiments where the goal was answering a hard question rather than shipping a permanent system, including ones that didn't pan out