Security automation and detection engineering
Vendors sell detection. We build fixes — detections as code, AI-assisted triage, and remediation pipelines engineered inside your AWS and Google Cloud accounts, in your repositories, owned by your team when we leave.
When you need this
You pay for a SIEM and a CSPM, alerts arrive daily, and nobody has ever written a detection that knows how your environment actually works.
Every alert costs an engineer twenty minutes of copying context out of four consoles before they can decide whether it matters.
The same misconfigurations come back after every remediation sprint, and nobody automates the fix because nobody trusts an automated fix in production.
The board asked what you're doing with AI in the SOC, and you need something that runs in your environment rather than a vendor demo that invents a verdict.
What we do
01
Detections written for your cloud, tested like code
Rules live in your repository — Sigma including its correlation rules, Panther detections in Python, Elastic detection rules, Splunk correlation searches, YARA-L in Google SecOps, whatever you already run — and go through pull request, schema validation, and unit tests against fixture events and replayed telemetry before they reach production. We write to the log sources that carry cloud attacks: CloudTrail management and data events, GCP Admin Activity and the Data Access logs that are off by default, EKS and GKE audit logs, IAM Access Analyzer and GuardDuty findings as signals rather than as an alert queue. The detections are identity-centric because cloud intrusions are: role chaining, unusual principals assuming sensitive roles, access keys minted on human identities, org-level policy and trust-policy changes. Coverage is mapped to the MITRE ATT&CK cloud techniques so you can see the gaps as clearly as the wins.
02
Triage that arrives with its context already attached
Enrichment runs deterministically first: resource owner, effective IAM permissions, network reachability, recent deploys, prior alerts on the same principal. Then a model reads that assembled evidence and writes a structured triage note — what happened, which signals agree, which contradict, a proposed severity, and the exact links a human needs to confirm it. The model summarises and proposes; it never closes an alert, and its inputs and outputs are logged next to the alert so any reviewer can audit what it was given and what it produced.
03
Remediation pipelines with a rollback you've actually tested
Response automations are built on primitives you already operate — EventBridge into Step Functions and Lambda on AWS, Eventarc and Pub/Sub into Cloud Run on GCP, AWS Config with SSM Automation runbooks where that fits better. Every action ships in dry-run first, runs under a scoped role with an explicit resource allow-list, is idempotent, and captures prior state so a rollback is a tested path rather than a hope. We roll out by environment, keep a break-glass disable, and push the durable fix back into Terraform or OpenTofu so the next apply doesn't reintroduce what the automation just corrected.
04
Agentic workflows with checkpoints that mean something
Where an agent earns its place — correlating across accounts, drafting an incident timeline, proposing a containment plan — we give it its own identity, its own least-privilege role, read-only tools by default, and an audit trail separate from the humans it assists. Write actions sit behind an explicit human approval step, and we tune how many approvals a shift can realistically absorb, because a checkpoint nobody reads is not a control. The agent we build here gets threat-modelled against the OWASP Agentic Top 10 (ASI01–ASI10) as a design step — tool misuse, privilege compromise, and approval fatigue are the categories that bite inside a SOC — which is not the same thing as the adversarial assessment we run against agents you already ship. Detections and automations are then validated by emitting real attacker behaviour with Stratus Red Team for cloud control-plane techniques and Atomic Red Team for host and container ones, rather than by asserting they fire.
What you receive
- Detection rules committed to your repository, with unit tests, CI validation, and a README the next engineer can follow
- A detection-as-code pipeline: pull request, validation, test against replayed telemetry, staged deploy to your SIEM
- Enrichment and triage workflows running in your accounts under your identities, with prompts and tool definitions in version control
- Remediation automations with dry-run mode, scoped roles, resource allow-lists, and a rollback path tested per action before it goes live
- A before-and-after view of the ATT&CK cloud techniques the shipped rules cover, with the emulation output behind each one and the techniques we deliberately left alone
- Handover: working sessions with your on-call engineers, a runbook per detection, and a named owner for every pipeline
How it runs
Scope
days
Log-source inventory, alert-volume baseline, current tooling reviewed, first backlog agreed and priced.
Build
2–4 weeks
Detections, enrichment, and remediation authored in your repo and shipped in increments you review as they land.
Validate
days
Attack simulation against each detection, false-positive burn-in in shadow mode, tuning before anything pages a human.
Handover
included
Working sessions, runbooks, ownership assigned. You can change every artefact without us.
Durations are indicative. Actual scope and price are fixed after the scoping call.
Questions we get asked
- Our SIEM ships detection content, and GuardDuty and Security Command Center ship managed findings. Why pay for this?
- Vendor content is written for the median customer, because it has to be — it can't know your account structure, your naming, your CI/CD identities, or which of your buckets is genuinely meant to be public. And it stops at the alert: no vendor can ship the fix, because the fix touches your production. That gap is the work. We tune what you already pay for, write the detections it can't, and build the response side that nobody sells.
- Do you run our SOC or monitor the alerts afterwards?
- No. We don't do 24/7 monitoring, we don't take on-call, and we don't resell a platform. We build the automation, validate it against emulated attacker activity, teach your engineers to change it, and step out. If your real problem is that nobody is watching a queue at 3am, an MSSP or an in-house rota solves that and we'll tell you so rather than sell you a project that doesn't.
- How much are you letting a model actually decide?
- It correlates, summarises, and proposes. It does not close alerts, change permissions, quarantine workloads, or delete anything. Every write path is either a deterministic automation whose blast radius is bounded in code and reviewable in your repo, or a step a human approves. Where a model's judgement is load-bearing, we say so explicitly in the runbook and design the human check around that specific failure mode.
- What are we left with if we don't renew, and which platforms do you support?
- Code in your repository, workflows in your cloud accounts, rules in your SIEM. No CloudSecOps-hosted component, no licence, no phone-home — if you never speak to us again, everything keeps running and your team can edit all of it. Our cloud depth is AWS and Google Cloud; we don't claim Azure. On the detection side we work in what you already operate, and if that's a stack we haven't built in before, we'll tell you during scoping instead of learning it on your budget.