Data Center Security Engineering (DCSE) secures Anthropic's data center footprint; this role covers how the sites are designed and built to be secure. Much of that footprint is designed and built with partners, so a site's security is decided early: in what Anthropic hands the people who build it, and in how rigorously the delivered systems are tested against it.
You'll design and specify the physical security systems for a site: perimeter and vehicle barriers, intrusion detection, video, security lighting, and the site penetrations and utility entry points that bypass them. Design firms and integrators produce the site drawings and install; you specify, review, and verify. You'll write the performance requirement and verification method behind each control, review every site design against them at each stage with redlines a design team can act on, test in the field that what was built performs as specified, and re-verify post-acceptance changes.
This is a foundational role. You'll own Anthropic's physical security reference design package (typical details, reference drawings, schedules, and test procedures) in the form partners build from, and keep it current against each site's threat basis and the sites actually being built. You'll set the technical position for a site and decide what applies where; where a requirement can't be met as written, you'll engineer the compensating control and document the deviation. You'll work with the rest of DCSE, with Anthropic's design, construction, and real estate counterparts, and directly with the vendors who build to the package. We use Claude throughout our engineering workflow and expect you to as well.
The same seat covers the team's security operations control rooms. You'll set their design and operational requirements and accept delivered systems against them, working day to day alongside the team's platform engineers, who own the software and compute that run in them.
This role involves regular travel to data center sites. These are critical services, and this role participates in an on-call rotation for them.
Key responsibilities
• Produce a vendor-ready design package for perimeter barriers and hostile vehicle mitigation, intrusion detection and its zoning, video coverage, security lighting matched to camera performance, and penetration protection: performance specifications, typical details and reference drawings, and device and zone schedules, written so a design firm can build to them and a test can prove them
• Define the per-site engineering basis: which requirements apply to a site based on its risk profile and the threats it faces, with compensating controls and documented deviations
• Write the acceptance criteria and test methods: the verification method behind each requirement and the evidence a site must produce to pass acceptance
• Set standoff, structural hardening, and site layout criteria for new designs, tied to the threat basis they derive from
• Run field verification: commissioning and acceptance testing of perimeter, detection, video, and lighting against performance criteria (detection coverage tests, photometric measurements, video quality checks)
• Write the operational and design requirements for security operations control rooms: console layout, wall versus workstation content, supervisor placement; room network, power, backup, and resilient communications to the team's segmentation and hardening baseline
• Own control room acceptance: factory and site acceptance criteria written before the build, then accept or reject delivered systems (video wall, consoles, cabling, fit-out) against them
Minimum qualifications
• Have designed or specified physical security systems (perimeter barriers, intrusion detection, video, security lighting) for campus-scale sites: multiple buildings, a secured perimeter, many detection zones
• Read and produce construction documents (site plans, civil and electrical drawings, device schedules, submittals) using standard design and markup tools such as AutoCAD, Revit, or Bluebeam, and find what is missing as readily as what is wrong
• Write performance requirements that are testable: each states what must be true, how it will be verified, and what evidence shows it
• Have run commissioning and acceptance tests against performance criteria and rejected work that did not meet them
• Derive requirements from a threat basis rather than a product catalog: you can say which adversary a control stops and where the next weakest point is
• Have owned an engineering domain where you set the approach, chose what applied to each site, worked directly with vendors, and answered for the result
