MirrorWeb
Manchester, Lancashire
What is a Product Security Engineer? The hardest security problems we face aren't policy problems. They're engineering problems. Supply-chain operators. Prompt-injection campaigns. Financially-motivated attackers who turn a compromised dependency into production access. A well-organised control library doesn't move the needle there. Engineering does. A Product Security Engineer is a software engineer whose specialism is making those attack paths hard, expensive, or impossible. They write production code. They build detections that catch real attacks. They harden the systems other engineers depend on. They reason about specific adversaries with specific failure modes, not abstract categories. We're hiring someone to defend the regulated communications record of thousands of financial firms. The data is a real target. The work is engineering work. What you'll do MirrorWeb is a communications compliance supervision platform. We process hundreds of millions of events a month for thousands of financial-services firms worldwide. Customers trust us with their regulated record, which is a high-value target by any threat model. You'll work across the platform: web capture, largescale data pipelines, archiving, the customer-facing product, and the developer infrastructure all of it ships on. Engineer defence into the product Multi-tenant isolation that holds up to a determined insider. Encryption and key management you'd trust on your own data. IAM modelled as code, reviewed like code, with privilege escalation paths analysed before they ship. Application-layer hardening on the surfaces customers actually use. Security as a property of how the product is built, not a layer on top. Defend the supply chain The path of least resistance into modern SaaS runs through dependencies, build pipelines, and CI providers. You'll engineer the systems that make our supply chain defensible: provenance and integrity for what we build (SLSA, sigstore patterns, signed artifacts), dependency trust as a real control rather than a manifest scan, build pipeline isolation, third party risk as runtime telemetry. When the next big supply chain incident lands, we should know within hours whether it touches us. Detect, respond, contain Runtime detection that catches what actually happens, not what a vendor template guesses might. Incident response codified as automation: containment, rotation, isolation, evidence capture. Forensics tooling that works on our stack. Adversary emulation against our real attack surface. The metric is mean time tocontain, not control coverage. Secure the agentic development surface Our engineers ship with AI agents in the loop on every change. That's leverage, and it's a new attack surface: prompt injection against agent harnesses, untrusted MCP server outputs, IAM scope creep on agent driven tooling, model and prompt supply chain. You'll own the security layer of our agent platform: sandbox boundaries, scoped credentials, provenance trails on agent shipped changes, secure by default code generation patterns. Lead the security craft inside engineering You embed inside the engineering team, not next to it. You pair with platform and product engineers on the work where threat models matter. You raise the bar through the tooling and patterns you ship, not through review gates. Compliance (SOC 2 today, more as we scale) falls out as evidence of real security work, not as a separate workstream. What we're looking for Essential Several years writing production software on AWS Security as your specialism, with a track record of defence systems you've shipped: detections that fired on real attacks, supply chain or build pipeline hardening, hardened product surfaces, IR automation that contained an incident. Be ready to talk about one in depth. Adversarial instincts. You follow supply chain incidents, read post mortems, and reason about real threat actors rather than abstract categories. Hands on experience using AI coding agents (Claude Code, Cursor, Codex, or similar) in production development workflows A clear model for how agent harnesses work (context, tool selection, trust boundaries), and where they break Threat modelling fluency. You can walk a system design and come out with what's worth defending and what isn't. An open communicator who raises concerns early and contributes in group discussions A high bar for resilient systems, in yourself and the people around you Desirable Detection engineering at production scale: runtime detection, anomaly detection, alert tuning (Sigma, OSQuery, Falco, or equivalent) Supply chain security: SLSA, sigstore / cosign, in toto, SBOM tooling used as a real control Cloud native attack patterns on AWS: IAM privilege analysis, IMDS exploitation, cross account paths, KMS misuse, and the defences for each Incident response leadership end to end on a real incident (containment, eradication, forensics, write up) Authoring MCP servers or custom agent tools with a security lens Product Security Engineer Job Description 3 Familiarity with AGENTS.md / CLAUDE.md patterns and skill authoring Cryptography in practice: key management, KMS / HSM, encryption in use, sensible TLS Large scale data intensive systems: PostgreSQL, ClickHouse, Turbopuffer Observability tooling: Grafana, exception alerting, OpenTracing, Langfuse Regtech, fintech, or regulated record experience Scoping red team and pentest engagements (you commission and consume offensive testing, you don't run it day to day) What you won't find here A GRC role with an engineering title. A queue of CVE tickets to triage. A SOC analyst rota. A compliance automation role rebadged as security engineering. This role exists to defend our product against real adversaries, not to manage a control library. Why MirrorWeb? We're a communications compliance surveillance and supervision platform. We process hundreds of millions of events a month for firms worldwide, and we're scaling fast. Past the scrappy startup stage, still small enough that the work you do this week is in production next. Security Engineering, like Product Engineering, is a first class softwareengineering discipline here. Not an audit function bolted onto one. We protect the regulated record for thousands of financial firms. The threat is real, and the surface is interesting. Our Tech Stack Backend: Go, TypeScript, Python Frontend: React, TypeScript Cloud: AWS (Lambda, EC2, ECS Fargate, Aurora PostgreSQL/MySQL, S3, SQS/SNS), Vercel AI Infrastructure: AWS Bedrock, Langfuse, Vercel AI Gateway Infrastructure: Terraform, GitHub Actions Data: Large scale PostgreSQL, ClickHouse, Turbopuffer Agent tooling: Claude Code, Cursor, Linear, Codex, Sentry, Grafana Cloud, CodeRabbit, Incident.io
What is a Product Security Engineer? The hardest security problems we face aren't policy problems. They're engineering problems. Supply-chain operators. Prompt-injection campaigns. Financially-motivated attackers who turn a compromised dependency into production access. A well-organised control library doesn't move the needle there. Engineering does. A Product Security Engineer is a software engineer whose specialism is making those attack paths hard, expensive, or impossible. They write production code. They build detections that catch real attacks. They harden the systems other engineers depend on. They reason about specific adversaries with specific failure modes, not abstract categories. We're hiring someone to defend the regulated communications record of thousands of financial firms. The data is a real target. The work is engineering work. What you'll do MirrorWeb is a communications compliance supervision platform. We process hundreds of millions of events a month for thousands of financial-services firms worldwide. Customers trust us with their regulated record, which is a high-value target by any threat model. You'll work across the platform: web capture, largescale data pipelines, archiving, the customer-facing product, and the developer infrastructure all of it ships on. Engineer defence into the product Multi-tenant isolation that holds up to a determined insider. Encryption and key management you'd trust on your own data. IAM modelled as code, reviewed like code, with privilege escalation paths analysed before they ship. Application-layer hardening on the surfaces customers actually use. Security as a property of how the product is built, not a layer on top. Defend the supply chain The path of least resistance into modern SaaS runs through dependencies, build pipelines, and CI providers. You'll engineer the systems that make our supply chain defensible: provenance and integrity for what we build (SLSA, sigstore patterns, signed artifacts), dependency trust as a real control rather than a manifest scan, build pipeline isolation, third party risk as runtime telemetry. When the next big supply chain incident lands, we should know within hours whether it touches us. Detect, respond, contain Runtime detection that catches what actually happens, not what a vendor template guesses might. Incident response codified as automation: containment, rotation, isolation, evidence capture. Forensics tooling that works on our stack. Adversary emulation against our real attack surface. The metric is mean time tocontain, not control coverage. Secure the agentic development surface Our engineers ship with AI agents in the loop on every change. That's leverage, and it's a new attack surface: prompt injection against agent harnesses, untrusted MCP server outputs, IAM scope creep on agent driven tooling, model and prompt supply chain. You'll own the security layer of our agent platform: sandbox boundaries, scoped credentials, provenance trails on agent shipped changes, secure by default code generation patterns. Lead the security craft inside engineering You embed inside the engineering team, not next to it. You pair with platform and product engineers on the work where threat models matter. You raise the bar through the tooling and patterns you ship, not through review gates. Compliance (SOC 2 today, more as we scale) falls out as evidence of real security work, not as a separate workstream. What we're looking for Essential Several years writing production software on AWS Security as your specialism, with a track record of defence systems you've shipped: detections that fired on real attacks, supply chain or build pipeline hardening, hardened product surfaces, IR automation that contained an incident. Be ready to talk about one in depth. Adversarial instincts. You follow supply chain incidents, read post mortems, and reason about real threat actors rather than abstract categories. Hands on experience using AI coding agents (Claude Code, Cursor, Codex, or similar) in production development workflows A clear model for how agent harnesses work (context, tool selection, trust boundaries), and where they break Threat modelling fluency. You can walk a system design and come out with what's worth defending and what isn't. An open communicator who raises concerns early and contributes in group discussions A high bar for resilient systems, in yourself and the people around you Desirable Detection engineering at production scale: runtime detection, anomaly detection, alert tuning (Sigma, OSQuery, Falco, or equivalent) Supply chain security: SLSA, sigstore / cosign, in toto, SBOM tooling used as a real control Cloud native attack patterns on AWS: IAM privilege analysis, IMDS exploitation, cross account paths, KMS misuse, and the defences for each Incident response leadership end to end on a real incident (containment, eradication, forensics, write up) Authoring MCP servers or custom agent tools with a security lens Product Security Engineer Job Description 3 Familiarity with AGENTS.md / CLAUDE.md patterns and skill authoring Cryptography in practice: key management, KMS / HSM, encryption in use, sensible TLS Large scale data intensive systems: PostgreSQL, ClickHouse, Turbopuffer Observability tooling: Grafana, exception alerting, OpenTracing, Langfuse Regtech, fintech, or regulated record experience Scoping red team and pentest engagements (you commission and consume offensive testing, you don't run it day to day) What you won't find here A GRC role with an engineering title. A queue of CVE tickets to triage. A SOC analyst rota. A compliance automation role rebadged as security engineering. This role exists to defend our product against real adversaries, not to manage a control library. Why MirrorWeb? We're a communications compliance surveillance and supervision platform. We process hundreds of millions of events a month for firms worldwide, and we're scaling fast. Past the scrappy startup stage, still small enough that the work you do this week is in production next. Security Engineering, like Product Engineering, is a first class softwareengineering discipline here. Not an audit function bolted onto one. We protect the regulated record for thousands of financial firms. The threat is real, and the surface is interesting. Our Tech Stack Backend: Go, TypeScript, Python Frontend: React, TypeScript Cloud: AWS (Lambda, EC2, ECS Fargate, Aurora PostgreSQL/MySQL, S3, SQS/SNS), Vercel AI Infrastructure: AWS Bedrock, Langfuse, Vercel AI Gateway Infrastructure: Terraform, GitHub Actions Data: Large scale PostgreSQL, ClickHouse, Turbopuffer Agent tooling: Claude Code, Cursor, Linear, Codex, Sentry, Grafana Cloud, CodeRabbit, Incident.io