Agentic Kill Chain: Where to Stop an Autonomous AI Agent

What Anthropic’s September 2026 threat report suggests about governing autonomous agents one action at a time.

By Tahir Mahmood, Co-founder & CTO, OpenBox · Last updated 9 November 2026

What does Anthropic’s report say about the AI kill chain?

Anthropic’s report says the risk from AI adoption is more pronounced across the cyber kill chain than in exploit development alone. Adversaries, it says, can operate faster, across a broader and deeper surface, with fewer resources. It also says publicly available offensive agent frameworks reproduce much of the scaffolding of an operating model it documented in November 2025, and that this scaffolding effectively automates each step of the chain.

The report is Detecting and countering misuse of AI: September 2026, published on 10 September 2026. It covers activity Anthropic disrupted between December 2025 and August 2026. Anthropic describes its cases as the most notable and novel threat activity it has identified, not typical misuse.

Anthropic also says a majority of the operations it describes were enabled by AI through direct execution or orchestration, with humans staying in the loop by setting targets and reviewing exfiltration. In one case, it says monitoring agents were designed to rebuild malware that security products detected, and to keep iterating until it went undetected. Anthropic says capable adversaries can, at least in theory, “close the loop” on traditional detections.

One scope note applies to everything below. The report covers threat actors using Claude for malicious activity, not enterprise AI deployments. The governance mapping later in this article is the author’s own reading. For a CISO-level take on the same report, see Governing Autonomous AI Agents That Act Without Asking.

How many stages are in the ShinyHunters attack lifecycle?

Figure 2 of the report shows nine numbered stages, from Sourcing and recon to Cover. Figure 1 gives a simpler four-stage view: Harvest, Intrude, Exfiltrate and Monetize. Figures 3 to 10 describe the first eight stages. The report gives no description for stage nine. Anthropic attributes the lifecycle to clusters of suspected ShinyHunters affiliates.

Anthropic says these affiliates appear disparate and use their own tooling, but are part of the same overall operation. Table 1 sets out the nine stages as Figure 2 labels them, with a short paraphrase of how the report describes each.

Table 1. The nine stages in Figure 2 of Anthropic’s report

Figure 2 also carries two feedback annotations: the proceeds of each credential fund the discovery of the next, and stolen compute and keys re-enter operations. Figure 11 adds four common workflows, each with six numbered steps: the app-token cascade, the vendor-vault fan-out, the platform-admin amplification and the oracle run.

The author’s inference: a loop, unlike a line, means a stop at one stage also limits what feeds the next cycle.

How fast does a chain of actions move?

Anthropic reports one breach of an enterprise software company that took only hours from first access to bulk data theft. It reports another that went from a single stolen developer token to full administrative control of a victim’s cloud environment in roughly three hours.

In a third case, Anthropic says a session-store dump covered over 2,100 Azure AD token sets across more than 40 corporate tenants in about 34 hours, and AI agents performed nearly all of the work.

These are reported timelines for specific cases, not benchmarks for AI-assisted attacks in general. The author’s reading is that review after the fact arrives late when a chain moves in hours. That is one argument for a decision at each action. OpenBox has written on why governance starts where monitoring ends, why logging is not AI governance and why runtime enforcement comes before compliance.

Why does Anthropic map weapons and intelligence cases onto lifecycle diagrams?

Anthropic’s report draws three of its conventional-weapons and intelligence cases onto named process models: a systems-engineering V (PDF page 114), the joint targeting cycle (page 122) and the intelligence life cycle (page 128). The diagrams mark where Claude was involved. The first caption adds that Anthropic’s visibility into the overall programme was limited and that the diagram reflects its assessment.

This article does not repeat the weapons details. The takeaway is structural and is the author’s: a workflow can be drawn as stages, and each stage is a place where a decision can be made. Anthropic uses the diagrams to show where Claude was involved, not to draw a governance conclusion.

How do you turn an attacker lifecycle into a governed agent workflow?

One way is to describe an enterprise agent’s work as five links: retrieve, reason, call a tool, write data and trigger downstream. OpenBox classifies agent operations into 24 semantic event types, so each link can carry its own governance decision. The five-link model is the author’s, not Anthropic’s and not OpenBox documentation.

Table 2 pairs each link with the closest analogue in Figure 2, example event types with their documented risk levels, and a decision to consider. The pairings are loose analogies, because Figure 2 describes attackers and the links describe a governed agent.

Table 2. A five-link model for an enterprise agent (the author’s model)

Risk levels come from OpenBox’s Event Types documentation. The decisions are the author’s recommendations for illustration, not defaults that OpenBox applies. Tool calls deserve particular attention; see What Your LLM Gateway Can’t See: Agent Tool Governance and MCP Tool Poisoning: Govern and Prove Agent Actions. To classify use cases before choosing decisions, start with How to Assess and Tier Agentic AI Use Cases by Risk and What Are Consequential Events in AI Agents?.

What do OpenBox’s five governance decisions do at each link?

OpenBox, an AI agent governance platform, returns one of five governance decisions when it evaluates an agent operation: ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK or HALT. They are produced in the Authorize phase of the Trust Lifecycle. When more than one applies, the stricter decision wins: HALT, then BLOCK, REQUIRE_APPROVAL, CONSTRAIN and ALLOW.

Table 3 sets out what each decision does. The Governance Decisions page documents the decision types and their effects.

Table 3. OpenBox governance decisions and their effect on a chain

HALT works on the chain, not the link. OpenBox’s documentation lists a critical policy violation, a detected multi-step threat pattern, a critically low agent trust score and an explicit termination rule among the conditions that return HALT. In the author’s view, HALT is the natural response when one link shows that the whole chain is compromised or misdirected.

This article does not claim that any of these decisions would have stopped a case in Anthropic’s report, which concerned attackers’ use of Claude, not governed enterprise agents.

For a worked scenario that applies the five decisions to a chain of individually approved steps, see Runtime AI Agent Governance: Chained Approved Steps.

For approval design, see Human-in-the-Loop AI, Explained the Right Way. For HALT thresholds on long-running agents, see Your agent ran two hours. Who was watching?. For why a binary allow-or-block gate struggles when one action can be safe or harmful, see Why Blocking Bad AI Prompts Fails on Dual-Use Actions. The wider discipline is covered in What Is AI Agent Governance? The Complete Enterprise Guide.

Why does a session-level view matter across a chain?

OpenBox Policies (OPA/Rego) are stateless checks on a single operation. Behavioral Rules are stateful: they detect multi-step patterns across an agent’s session, such as sequences, frequencies and combinations, and can escalate to BLOCK, REQUIRE_APPROVAL or HALT. A chain is a pattern across operations, which is the job of Behavioral Rules.

The documentation’s examples include personally identifiable information being accessed and then followed by an external API call without approval, and a database write combined with a file export and an external send. Both are documentation examples of rule patterns, not accounts of real incidents.

The Authorize phase has three layers: Guardrails, Policies and Behavioral Rules. Guardrails validate or transform data flowing in and out. The Monitor phase covers sessions, metrics and telemetry as the agent runs. After a session, Session Replay, part of the Verify phase, lets a team walk through it step by step and inspect each event, tool call and governance decision.

The Trust Lifecycle’s five phases are Assess, Authorize, Monitor, Verify and Adapt. They feed an agent-level Trust Score that maps to Trust Tiers. The documentation says lower tiers receive stricter defaults.

What can security architects do with an agentic kill chain model?

These steps are the author’s recommendations, not requirements from Anthropic or any standard.

1.  List the operations each agent can perform and group them into links. The AI Agent Lifecycle Management checklist is one starting point.

2. Choose a decision per link, starting from the documented risk level of each event type.

3. Write Behavioral Rules for sequences that matter, such as sensitive reads followed by outbound sends.

4. Decide in advance which conditions should return HALT, and who is told when one does.

5. Review sessions with replay and adjust. For a week-by-week plan, see OpenBox’s 90-day CISO playbook.

If agents hand work to other agents, treat each handoff as a link too. See Govern the Handoffs Between Your AI Agents and Authorization Propagation in Multi-Agent AI Systems.

The takeaway

Anthropic’s diagrams show attackers working stage by stage. An agent’s work can also be drawn in stages, and each stage can carry a decision. You do not govern an agent once at the door; you govern each action in its chain. To see how OpenBox applies this, start with the OpenBox documentation.

Frequently asked questions

What is an agentic kill chain?

In this article, an agentic kill chain is the sequence of discrete actions an autonomous AI agent takes to complete a workflow, drawn as stages the way Anthropic’s September 2026 report draws attacker lifecycles. The phrase is the author’s, adapting the cyber kill chain term the report uses. Each stage is a point where a governance decision can be made.

What does HALT do in OpenBox?

HALT is the highest-precedence of OpenBox’s five governance decisions. It stops the whole session, and documented effects include cancelling the workflow and abandoning pending operations. The documentation lists a critical policy violation, a detected multi-step threat pattern, a critically low agent trust score and an explicit termination rule among the conditions that return it.

What is the difference between BLOCK and HALT?

BLOCK stops one operation, and the agent carries on with other work. HALT ends the whole session, cancelling the workflow and abandoning pending operations. When both apply, HALT takes precedence. In the author’s view, BLOCK suits a single bad action, while HALT suits a case where the whole chain can no longer be trusted.

Does this article say OpenBox would have stopped the attacks in Anthropic’s report?

No. Anthropic’s report covers threat actors using Claude for malicious activity, not enterprise AI deployments. This article uses the report’s lifecycle diagrams as a structure for thinking about governed agent workflows. It makes no claim that any OpenBox decision would have stopped any case the report describes.

Related reading from OpenBox

•      Prompt Injection Is a Governance Failure

•      Securing AI Agents Requires Runtime Governance

•      Model Guardrails Aren’t Enough to Govern AI Agents

•      AI Agents Can Rewrite Their Own Permissions

•      Trust Is a Runtime Governance Decision

•      Why AI Agents Need Runtime Monitoring

•      Your AI agent acted. Can you prove it was allowed?

•      Copilot SearchLeak: Why Logging Can’t Stop One-Click Data Exfiltration

In the documentation: Agent Identity, Agent Lineage, Attestation & Cryptographic Proof and the Developer Guide.