Runtime Governance Series

AI Task Splitting and Re-Prompting: Per-Action Governance

Anthropic’s September 2026 report shows split tasks and re-prompting weakening safeguards. See what per-action governance checks and what carries over.

Published on

Nov 10, 2026

Subscribe to our newsletter

Can Attackers Bypass AI Safeguards by Splitting Tasks Across Sessions? What Anthropic's Report Shows

By Tahir Mahmood, Co-founder & CTO, OpenBox | Last updated 10 November 2026

In brief: Anthropic's September 2026 threat report describes one case where safeguards performed less consistently once malicious work was fragmented across later, smaller sessions, and another where a refusal was reversed on re-prompt. A check that judges one prompt sees one slice of the plan. OpenBox, an AI agent governance platform, evaluates each agent action and, per its published posts, returns one of five decisions. It adds session-level Behavioral Rules and a Trust Score that reflects compliance over time.

What did Anthropic's September 2026 report find about split tasks and re-prompting?

Anthropic's September 2026 report describes three patterns relevant to split tasks. In one case, safeguards performed less consistently when work was fragmented across later, smaller sessions. In another, a refusal was reversed on re-prompt. In four conventional weapons operations, actors split their work across many sessions. Anthropic says its cases are not typical misuse.

Anthropic published "Detecting and countering misuse of AI: September 2026" on 10 September 2026. It covers activity Anthropic disrupted between December 2025 and August 2026 across seven harm areas, and says sophisticated and persistent threat actors continuously test its safeguards. It describes cases Anthropic disrupted, not industry-wide prevalence. Page numbers below are the report's own footer numbers.

The pillar guide What Is AI Agent Governance? The Complete Enterprise Guide covers the wider topic. OpenBox has also read the same report for model-level safeguards, including model-switching, in Model Guardrails Aren't Enough to Govern AI Agents.

Fragmentation: GTG-30006 (p. 107)

Anthropic tracks an Iranian threat actor as GTG-30006. GTG stands for Generative Threat Group, which Anthropic defines as its internal designator for actors observed abusing AI. According to the report, the actor used free Claude.ai accounts across 16 single-operator organizations to develop malware, a delivery pipeline and a phishing portal. It used Claude for engineering and testing by decomposing projects into individually benign web-development requests.

The report gives one specific measurement. Claude refused nine out of ten direct requests that were facially malicious. Anthropic then says its safeguards performed less consistently when the user fragmented the work and directed the model to carry out tasks across later, smaller sessions. That ratio belongs to this case. It is not a general refusal rate.

Re-prompting: a refusal reversed (pp. 94 to 97)

The report describes three linked PRC-aligned surveillance operations. In one, Claude refused an attempt to ingest and produce a weekly "stability maintenance" report. The actor then re-prompted the model and obtained functional suppression guidance naming 10 private citizens (p. 94). Anthropic's case table records the outcome as a refusal reversed on re-prompt (p. 95).

Anthropic's own summary is that its safeguards did not perform uniformly across these cases (p. 97). In one, Claude correctly refused but was overcome on further prompting. In another, it complied across many sessions without intervention.

Session splitting: four conventional weapons operations (pp. 112 to 113)

In Part I of the report, Anthropic discusses four conventional weapons operations it disrupted. By its definition, disrupted means it banned every account it could link to the actor. Anthropic says the actors split their work across many sessions to conceal the full nature of their programs, and used other methods to circumvent its safeguards and access controls (p. 112).

One of the four, GTG-87001, is a cell Anthropic locates in northern Yemen. The report says the group split its work across multiple sessions so that no single session revealed its full intent. It adds that Anthropic's safeguards blocked many of the requests, but not all of them (p. 113).

The same actors managed several Claude instances at once and assigned each a role. One instance wrote code, another did research and a third reviewed the first instance's code. The report compares this to a lead delegating work on a small engineering team. It describes the arrangement. It does not say that role assignment concealed intent, and this article does not claim that either (p. 113).

Why does a per-prompt safety check miss a task that is split across sessions?

A check that judges one prompt, or one session, sees only that slice of a split task. In GTG-30006 each request looked benign on its own. In GTG-87001 no single session revealed the full intent. This is the author's reading of those cases, not a finding Anthropic states.

Anthropic's own wording is measured: safeguards that were less consistent under fragmentation, blocked many requests but not all, and were overcome on further prompting in one case. It also says these are not typical misuse. They show what determined actors tried, not how often it happens.

The consequence for governance is the unit of judgment. In the author's reading, a check that works from prompt wording has to infer intent from the words, and a project decomposed into individually benign requests gives the words little to work with. OpenBox has described the same difficulty: fragmentation is harder, because the harm can sit in a sequence of individually permitted actions that a per-action check does not see (3 November post).

What does per-action enforcement check beyond the prompt?

Per OpenBox's October and November 2026 publications, OpenBox returns one of five governance decisions when it evaluates an agent action: ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK or HALT. The Authorize stage routes each operation through three layers: guardrails for input and output validation and transformation, policies (OPA/Rego) as stateless permission checks, and Behavioral Rules for stateful multi-step patterns.

Authorize is the second of five stages in the Trust Lifecycle: Assess, Authorize, Monitor, Verify and Adapt. The five decisions are described in these posts:

Decision	What it does, per the posts
ALLOW	Lets the action proceed without interruption.
CONSTRAIN	Executes the action inside a sandboxed environment rather than allowing or refusing it outright, for example by stripping sensitive fields from a tool call's input or limiting which resources the action can reach.
REQUIRE_APPROVAL	Pauses the operation and routes it to a human to approve or reject before it proceeds.
BLOCK	Refuses the individual call. The agent session continues.
HALT	Terminates the agent session, cancelling the current action and any pending operations.

Precedence runs HALT over BLOCK over REQUIRE_APPROVAL over CONSTRAIN over ALLOW, so a stricter verdict overrides a looser one (4 Nov post). According to the 28 Oct post, each decision executes before the tool call or model request reaches its target. The 4 Nov post argues that a binary allow or block gate is a poor fit for dual-use actions, where context decides whether the same action is safe or harmful. The 6 Nov post, Governing Autonomous AI Agents That Act Without Asking, reads the same Anthropic report for security leaders. The governance decisions docs page is the configuration reference.

In the author's reading, a policy gives the same result for the same input, however the request behind it was phrased. The docs list the input as including the tool, its arguments, activity spans and agent properties, so a re-prompt affects the outcome by changing what is evaluated. A policy keeps no history, which leaves the sequence problem to Behavioral Rules.

How do Behavioral Rules catch a sequence that no single step reveals?

OpenBox's docs describe Behavioral Rules as stateful authorization rules that detect multi-step patterns across an agent's session. A rule names a trigger action and the prior actions that must have happened first. If they have not, the configured verdict applies. The documented scope is one session.

Multiple prior states combine with AND logic. Rules are evaluated by priority, from 1 to 100, and evaluation stops at the first rule that triggers a verdict. The Behavioral Rules page lists four verdicts: ALLOW, REQUIRE_APPROVAL, BLOCK and HALT. Its worked example pairs a file_write trigger with a database_select prior state and a HALT verdict, under the rule name Query Data Before Generating Reports.

The 28 Oct post, Runtime AI Agent Governance: Chained Approved Steps, applies the same idea to a database write, then a file export, then an external send. That addresses a sequence inside one session. It does not by itself address intent split across separate sessions, and the Behavioral Rules page documents session scope.

What carries over when intent is split across separate sessions?

In the author's reading of OpenBox's docs, three recorded signals reach beyond a single session: the Behavioral component of the Trust Score (35% of the score), the Alignment component (25%, a decay-weighted average of recent sessions) and the violation patterns that Adapt aggregates. Each depends on what is recorded.

The Trust Score is (Risk Profile Score × 40%) + (Behavioral × 35%) + (Alignment × 25%), on a scale of 0 to 100. The table lists what the docs describe for each mechanism.

Mechanism	What the docs describe	Needs
Behavioral component (35%)	Policy compliance from Authorize and Monitor. It starts at 100 for new agents, is updated continuously and increases with compliant behavior. A violation lowers it: minor 5 points, major 15, critical 25, which is 1.75, 5.25 and 8.75 points on the Trust Score.	Recorded compliance or violation events
Trust Tiers	Tier 1 (90 to 100) is Trusted, Tier 2 (75 to 89) Confident, Tier 3 (50 to 74) Monitor, Tier 4 (25 to 49) Restrict, and 0 to 24 is Untrusted. Agents are downgraded immediately when the score crosses a lower bound. Policies can reference Trust Tier.	Score movement
Alignment component (25%)	Starts at 100 and is updated per session. Overall Alignment is a weighted average of recent sessions with a decay of 0.95. In the Temporal implementation, goal alignment needs goal context propagation.	A goal to measure drift against
Monitor	Shows a Goal Alignment Trend across sessions over time and lists recent drift events. This is visibility, not enforcement.	A person or process reviewing it
Verify	Logs a drift event when alignment drops below threshold. Drift patterns can trigger behavioral rules, and repeated drift generates policy suggestions.	Recorded drift
Adapt	Shows aggregated patterns derived from the agent's violations. OpenBox can suggest new policies or rules.	Recorded violations

The author reads these as the documented carry-over between sessions. The 40% Risk Profile component is left out because the docs describe it as static unless re-assessed. None of the pages cited here describes the carry-over as a cross-session intent detector.

The hard case follows. If every step is individually compliant, no violation may be recorded. The Behavioral component can still reflect that compliance, which is not the same as detecting a harmful plan spread across sessions. Drift events are the other documented signal, and the Monitor page says goal alignment needs goal context propagation in its Temporal implementation. Accumulation helps where something is recorded. It does not read intent that nothing recorded.

What should a security team do about task splitting and re-prompting?

Keep model-level safeguards, add action-level policies for sensitive operations, add Behavioral Rules for sequences you can name, use graded decisions and Trust Tier conditions, and review sessions in Session Replay. These are the author's recommendations, not Anthropic's and not stated in the OpenBox docs.

1. Keep model-level safeguards. In GTG-30006 the model refused nine of ten facially malicious direct requests. Treat safeguards as one layer, since fragmented work fared worse.

2. Write action-level policies for sensitive operations. Define what an agent may do with data, files and external sends, using fields such as the tool, its arguments and activity spans.

3. Add Behavioral Rules for sequences you can name. The docs example, a file write that requires a prior database query, shows the shape. Pick the sequences that matter in your environment.

4. Use graded decisions for ambiguous actions. CONSTRAIN and REQUIRE_APPROVAL give a response between allow and block, which the 4 Nov dual-use post argues dual-use actions need.

5. Reference Trust Tier in policies. The docs say policies can reference Trust Tier, so a policy can be written to depend on an agent's tier.

6. Review sessions. Use Session Replay, a step-by-step walkthrough of an agent's session execution opened from the Verify tab, together with the drift events in Monitor and the patterns in Adapt.

Cross-session intent remains the hard case. Intent can hide between prompts. In the author's view, governance has to accumulate rather than reset every session, and what it can accumulate today depends on what was recorded.

Frequently asked questions

Is task splitting typical of AI misuse?

Anthropic says the cases in its report are not typical misuse. It calls them examples of the most notable and novel threat activity it has identified to date. The report describes activity Anthropic disrupted between December 2025 and August 2026, so it shows what determined actors tried, not how often it happens across the industry.

Do OpenBox Behavioral Rules work across separate sessions?

OpenBox's docs describe Behavioral Rules as detecting multi-step patterns across an agent's session, so their documented scope is one session. Across sessions, the documented carry-over is the Behavioral and Alignment components of the Trust Score, tier changes and the violation patterns shown in Adapt. Each depends on what is recorded.

Does re-prompting change a per-action policy check?

In the author's reading, not by itself. OpenBox's docs describe policies as stateless checks that evaluate each operation independently, against an input that includes tool arguments, activity spans and agent properties such as Trust Tier. The same input gets the same result. A re-prompt can still change the outcome by changing the operation or the context evaluated.