On 12 May 2026, Anthropic published a case study describing how its own detection engineering team uses Claude Code to build the platform that watches Anthropic itself. The pattern is worth examining if you run security at an Australian bank, a critical-infrastructure operator, or a state-government agency, because the trade-offs it surfaces sit right at the centre of the build-versus-buy decisions Australian CISOs are making right now under APRA CPS 234 and the Security of Critical Infrastructure Act.
The pattern Anthropic just published
The team, led by Detection Platform Engineering's Jackie Bow, treats Claude Code as the primary surface for writing, reviewing, and iterating on detection logic. Rather than wiring Claude into one in-product feature, they use it as a development environment that has access to alert telemetry, log search, Slack channels, internal documentation, and the institutional knowledge that lives in past incident write-ups. Detections start as conversations with Claude, get drafted as code, get reviewed against the Responsible Scaling Policy controls, and ship into production through the same pipeline as any other engineering change.
Two design choices stand out. First, the stack is built by detection engineers, not by an AI platform team handing tools over the wall. Second, the tooling is composed of small, scoped capabilities that Claude can call individually rather than a single agent doing everything at once. Both choices match what we keep seeing succeed in Australian client engagements.
Why this lands differently for Australian security teams
Australian security leaders cannot copy Anthropic's posture verbatim. APRA's CPS 234 places accountability for information security squarely on the board and senior management of regulated entities. CPS 230 adds operational risk obligations for material service providers. The SOCI Act now reaches eleven sectors with positive security obligations and a mandatory cyber-incident reporting regime. Those obligations shape what a Claude-augmented detection stack can and cannot look like in regulated Australian environments.
The relevant implications for a CPS 234 entity considering this pattern:
Data residency. Detection telemetry that crosses borders triggers privacy and contract conversations under the Privacy Act 1988 and most APRA-registered agreements. Claude on AWS Sydney via the Bedrock route, or via the Anthropic API with a documented data-handling agreement, both work; default consumer Claude does not.
Audit trail. APRA expects every material control to be testable and evidence-based. A Claude detection workflow needs deterministic logging of prompts, model versions, tool calls, and outputs that survives a tripartite audit.
Material service provider classification. If a vendor sits inside your detection workflow, CPS 230 likely makes them a material service provider with the contract uplift, BCP testing, and notification obligations that come with it.
Human-in-the-loop on actions. Writing detections and triaging alerts is a different risk class to auto-suppressing or auto-remediating. Most APRA-regulated entities should keep humans in the action loop for now.
These constraints do not rule out the Anthropic pattern. They push it toward a particular shape.
What an in-house Claude-augmented detection stack looks like in an Australian shop
Across the engagements we have run with Sydney-based banks, super funds, and a state energy operator, the working architecture for a Claude-augmented detection capability tends to share five components.
A Claude Code workspace scoped to the detection-engineering repo, with read-only MCP connectors to log search (Splunk, Sentinel, or Elastic), the alert queue, the incident docs in Confluence or Notion, and the runbook library.
A small set of tightly scoped tools that Claude can call: a query builder for the SIEM, a hypothesis generator that reads recent alert clusters, a detection-coverage gap finder against MITRE ATT&CK, and a write-only path that posts draft detections into a review channel rather than directly into production.
A review gate where every Claude-authored detection is reviewed by a named human engineer, with the prompt, model version, and tool calls captured in the pull request for the auditor.
An RSP-style internal policy that says which detection categories are eligible for AI-assisted authoring (most), which need additional review (anything touching customer-impacting controls), and which are off-limits (auto-remediation, automated account actions).
A weekly retrospective that compares Claude-authored detection coverage against analyst-authored detection coverage, so the team can measure where the assistance is actually moving the needle and where it is just generating low-value rules.
None of this is exotic. It is the same review-gate pattern that APRA-regulated engineering teams already apply to production code, extended one step earlier into the detection-authoring loop.
The build-versus-buy maths most Australian CISOs should run
Australian mid-market security teams typically face a choice between three options: a managed XDR with built-in AI triage, a security copilot bolted onto an existing SIEM, or building the in-house Claude pattern described here. The figures we keep seeing in Australian environments:
Managed XDR with AI triage: roughly $180,000 to $420,000 per year for a 1,500-endpoint AU mid-market bank, plus the integration consulting to get incident data flowing the right way. Lock-in is high; portability is low.
SIEM copilot add-on: roughly $45,000 to $120,000 per year on top of existing SIEM licensing for a comparable footprint. Coverage matches the SIEM vendor's roadmap, which may or may not line up with your top detection gaps.
In-house Claude pattern: roughly $60,000 to $90,000 per year in Claude API or Bedrock spend at production volumes for an AU mid-market shop, plus one full-time detection engineer who would already be on the team. Total budget closer to $250,000 to $320,000 all-in, but the asset stays yours.
The honest answer is that most Australian mid-market security teams should buy first and build second. The Anthropic pattern is the right shape if your detection-engineering capability is already mature, your SOC is generating signal the vendor copilots cannot reach, and your board is comfortable with the residency and audit story. For a $2.8M annual security budget at a mid-tier Australian super fund, the in-house path is realistic. For a $450,000 security budget at a regional manufacturer, a managed service is the right call.
Where to start in the next six weeks
If the pattern fits, the shortest credible path from zero to a reviewable proof-of-concept inside an Australian regulated environment is six weeks, broken into three two-week sprints.
Weeks 1 to 2: stand up Claude Code against a non-production copy of your detection-engineering repo, wire read-only MCP connectors to the SIEM and alert queue, and draft the internal policy that says what Claude is and is not allowed to author.
Weeks 3 to 4: pick five real detection gaps from the last quarter's incident retrospectives and have your detection engineers author them with Claude alongside them. Measure time-to-draft and reviewer feedback against a control sample of five gaps authored without assistance.
Weeks 5 to 6: package the prompts, model versions, tool-call logs, and reviewer notes into a CPS 234 evidence pack and walk it past your second-line risk team and external auditor.
If the six-week pilot lands, you have a defensible foundation to expand. If it does not, you have a Sydney-based, regulator-shaped reason to choose a managed alternative instead, and the evaluation documentation to support that decision.
If you run detection engineering at an APRA-regulated entity or a SOCI-covered operator and you want help shaping a six-week pilot of this pattern against your own environment, book a brainstorm and we will walk through where Claude fits in your detection stack and where it does not.
