Claude agents are landing on Australian production stacks faster than most engineering managers expected, and the question that decides whether they survive contact with audit season is not "can this model reason well" but "what can it actually touch when it gets something wrong." Anthropic spent the last twelve months publishing patterns for containing Claude across its own product surface, and the ideas translate almost line for line into how an Australian team should think about agent design under APRA CPS 230 and the Privacy Act.
Why blast radius matters before you ship a single Claude agent
Blast radius is the set of side effects an agent can produce when it acts on its own. For a chat assistant that only generates text, the radius is small. For a Claude agent that books meetings, files invoices, or modifies records in Microsoft Dynamics 365, the radius covers every system the agent's credentials touch. An APRA regulated client we worked with in Sydney earlier this year priced a single misfiled customer status change at $180,000 once you account for remediation, the breach notice workflow, and the customer goodwill payout. That number reset how their engineering leadership thought about agent capability: every new permission added to a Claude build had to clear a written blast radius review before merging.
The Anthropic engineering write up that prompted this post walks through how Claude is contained inside Claude Code, Cowork, and the public app surface. Their headline lesson is that containment is not a single firewall but a layered set of defaults, and the layers exist because no single check catches everything. Australian teams shipping into APRA regulated environments inherit a similar obligation: CPS 230 expects controls to be proportionate, tested, and reviewable, which means the containment story has to live in code, runtime telemetry, and operational runbooks at the same time.
The five containment patterns we lift from Claude's own product surface
We pulled five patterns out of the public Anthropic material and the way Claude actually behaves inside Cowork, then tested them against the controls our clients are asked to demonstrate during APRA tripartite reviews. Each pattern is implementable in a normal Claude SDK build with no special tooling, and each maps cleanly onto a CPS 230 obligation.
1. Define blast radius per invocation, not per agent
The temptation when scoping a Claude agent is to grant a single broad set of credentials and trust the prompt to keep the model in lane. That falls apart the first time the user asks for something the prompt did not anticipate. The pattern Anthropic uses inside Claude Code is to scope tool access per request, not per session: each new instruction triggers a fresh permission check against what the user actually approved. Translate this into your own build by attaching an explicit capability manifest to every Claude invocation, and refusing any tool call that asks for a capability not present in the manifest.
2. Tier capabilities by the frontmost app analogy
Claude's computer use surface uses three tiers: read (visible only), click (visible and limited interaction), and full (no restrictions). Most browsers default to read, terminals to click, and the rest of the desktop to full. The same logic works inside an enterprise Claude agent. Categorise every connected system by how reversible a failure would be. A reporting database might sit at read, a CRM with audit log at click, and a sandboxed pricing model at full. Make the tier explicit in your tool registry so a code reviewer can immediately see whether a new tool is being added at the wrong tier.
3. Gate writes behind explicit user confirmation
Anthropic's containment work for Claude Mythos Preview, the model they declined to ship in April 2026 on blast radius grounds, made one point repeatedly: high impact tool calls should require an in loop confirmation step that a human cannot accidentally click through. Inside an APRA regulated Australian Claude build, that confirmation step is also evidence. Capture the prompt that triggered the action, the capability manifest at the time, the tool arguments, and the user's response. If the confirmation is missing, the action is rolled back at the orchestration layer rather than retried.
4. Make every tool call audit grade by default
CPS 230 paragraph 35 expects controls testing to be evidenced, and CPS 234 has been there a decade asking for the same thing on security. The Claude agent equivalent is structured logging on every tool call: invocation ID, agent version, model snapshot, capability manifest hash, tool name, arguments, result hash, and the upstream user identity. Anthropic's published patterns put this telemetry behind an internal trust layer that they then sample against safety policies. Your version does the same for compliance: a weekly job samples 100 calls, replays them against a policy ruleset written in plain English, and files exceptions to the operational risk register.
5. Wire a kill switch you actually trust
Most agent platforms ship with a stop button. Few teams test that the stop button actually breaks the agent loop fast enough to stop a runaway sequence of tool calls. The pattern that holds up under APRA tabletop exercises is a two level kill: a soft pause that drains in flight work, and a hard cut that revokes the agent's runtime credentials at the secret store. Both levels should be wired to alerts so the operational team can act before an incident report is needed and so that the audit trail picks up the moment of intervention.
What this looks like in a Sydney bank or Melbourne insurer
We took these patterns into a build for an Australian general insurer in March 2026, replacing a manual claim triage queue with a Claude agent that reads loss notifications, drafts triage notes, and books loss adjuster appointments. The blast radius document came in at four pages and identified two capability tiers (read on the policy system, click on the calendar). The first month flagged $45,000 of operational savings against $9,000 in licensing and a single near miss the kill switch caught in under twenty seconds. That ratio is what makes the containment work pay for itself, and it is also what the operational risk committee wanted to see before approving a wider rollout.
The practical action list we hand to new engineering teams looks like this:
Write the blast radius document before any code: one page per agent, signed by an engineering lead and the operational risk owner.
Adopt a capability manifest per invocation, not per session, and refuse unknown tool calls in the orchestrator.
Tag every connected system with a read, click, or full tier in your tool registry, and require a code review label change to move tiers.
Capture confirmation evidence on every write call: prompt, manifest hash, args, user identity, response.
Stand up a two level kill switch (soft drain plus credential revocation) and test it monthly so the operational risk register has a current pass.
Where this leaves your roadmap
Australian engineering teams shipping Claude agents are not short on ambition; they are short on the containment infrastructure that makes agent ambition safe to expose to a regulator. The five patterns above are the minimum we now recommend before any Claude agent goes live in an APRA regulated environment, and they slot into a normal sprint cadence rather than requiring a separate platform team. If you would like a second pair of eyes on a blast radius document, a tool registry, or a kill switch design, we run two hour working sessions you can book at our contact page most weeks.
