Blog · arXiv Analysis · Last reviewed June 25, 2026

The Goal Specification Becomes the Causal Step

The June 2026 arXiv paper Direct Causation in International Humanitarian Law and the Challenge of AI-Mediated Civilian Cyber Operations, by Alice Saito, Harold Godsoe, and Phan Xuan Tan, turns a legal puzzle into an agent-governance measurement problem: who specified the operation, and at what level of detail?

Goal-specification granularity is the audit field that says which operative variables were fixed by a human before deployment, and which were selected later by the system: objective, target, method, timing, tool chain, constraints, approvals, and stop conditions.

Causation Moves Into Configuration

The arXiv record for arXiv:2606.29175 lists the paper as submitted on June 28, 2026, in Artificial Intelligence with Computers and Society as a secondary subject. Its abstract names a specific pressure point: international humanitarian law's direct-participation framework was built around human acts, while autonomous multi-agent cyber systems can generate operative decisions after a civilian has disengaged.

Agent governance often asks whether a tool call, plan, or final action was authorized. Saito, Godsoe, and Tan ask a narrower upstream question: how much of the operation was fixed by the human at configuration time? The answer can decide whether later harm looks like a direct human-linked act or an indirect contribution mediated by system-generated decisions.

For technical governance, the useful object is the configuration act: the moment a person supplies the objective, target class, constraints, tool permissions, autonomy level, approval rule, and stopping rule that launch the agentic operation. A log that records only the final action misses the causal handoff. A log that records only the initial prompt may miss how much discretion the system received.

This page uses the paper's legal analysis as a governance lens. It does not classify real people, endorse cyber operations, or give legal advice. It asks what evidence a system would need to preserve if a later reviewer must distinguish human-specified operational content from system-generated operational content.

The ICRC's 2009 Interpretive Guidance frames direct participation in hostilities through three cumulative criteria: threshold of harm, direct causation, and belligerent nexus. The ICRC casebook summary states that direct causation can be satisfied by a direct causal link between an act and likely harm, or by a coordinated military operation of which the act is an integral part.

The new arXiv paper concentrates on the second criterion. If a civilian writes and runs a specific exploit against a specific target, the causal path is legible. If a civilian tells an autonomous system to disrupt an adversary and the system chooses targets, methods, timing, and execution path itself, the causal story changes. The human did not encode the operative decisions that produced the harm.

The paper argues that the usual "one causal step" and integral-part vocabulary strain at that point because the operative choices are generated after deployment.

That does not mean the actor becomes irrelevant, nor does it settle attribution, responsibility, or accountability under other bodies of law. It means this particular test needs evidence about where concreteness entered the operation. A high-level objective and a specific operational plan are not the same causal object.

Current Governance Context

The legal and policy context has two separate streams. In the international humanitarian law stream, the ICRC's position is that IHL applies to and limits cyber operations during armed conflict, just as it regulates other means and methods of warfare. The ICRC's direct-participation guidance is influential humanitarian-law analysis, not a logging standard for AI platforms and not a court decision about any particular cyber operation.

In the agent-governance stream, the same evidence problem is becoming concrete through identity, authorization, runtime control, and audit guidance. NIST's AI Agent Standards Initiative frames agent identity, authentication, secure interoperability, and evaluation as standards work. NIST's software and AI agent identity concept paper asks how actions taken by software and AI agents should be identified, managed, authorized, logged, and tracked. CISA and partner agencies' Careful Adoption of Agentic AI Services guidance warns that over-privileged agents can amplify compromise and calls for controls around design, configuration, behavior, privilege, monitoring, and oversight.

Protocol work points in the same direction. The Model Context Protocol's 2025-11-25 authorization specification requires resource-bound authorization flows and token audience validation, while its security guidance warns against token passthrough and broad scopes. Those controls do not answer IHL questions, but they show how a runtime can distinguish who delegated, which resource was authorized, and where tool authority was supposed to stop.

Outside the armed-conflict context, the EU AI Act supplies a useful comparison point for record design. Articles 12 and 14 require logging and human oversight for high-risk AI systems. Those provisions are not IHL and should not be treated as a direct rule for civilian cyber operations in conflict. Their relevance here is narrower: consequential AI systems increasingly need records that let reviewers reconstruct system use, human oversight, and intervention capacity.

Three Scenarios

The paper's analysis turns on three stylized civilian cyber scenarios. In the first, a volunteer specifies the target, method, and execution code. In the second, a hacktivist specifies the target but delegates method selection to an agent, with human approval operating as a runtime control. In the third, the hacktivist specifies only the objective, and the system generates targets, methods, and execution.

The third scenario is the hard case. The paper argues that the direct-participation framework defaults toward treating it as indirect participation, even though the deployment may be intentionally belligerent and operationally meaningful. That mismatch matters because the legal category is supposed to distinguish protected civilians from civilians who personally take part in hostilities.

The point is not to make targeting easier. It is to make classification more honest. If the law turns on a causal relation, the evidence system has to preserve the level at which the human fixed the operation.

The same distinction matters outside the paper's cyber example. An agent instructed to "find any vulnerable system in this address range" is not the same governance object as an agent instructed to "run this approved test against this owned system during this window." Both may involve tools. Only one fixes the relevant target, scope, method, and permission boundary before runtime.

Granularity as Evidence

Saito, Godsoe, and Tan call the missing construct "goal-specification granularity." Their spectrum classifies operations by what the human specified before deployment. Level 1 fixes target, method, and execution code. Level 3 or 4 fixes some operational content while delegating other parts. Level 5 fixes only the objective, leaving target selection, method selection, and execution to the system.

This is a useful bridge between law and technical governance. A model card can name a model. A tool log can show a tool call. A capability benchmark can show task performance. None of those artifacts necessarily records which operational decisions were made by a person before deployment and which were made by the agent afterwards.

The evidence field should therefore be structured around variables, not adjectives. A system should record whether the human specified the objective, target identity, target class, protected or forbidden targets, method family, tools, timing, escalation thresholds, data sources, approval checkpoints, and termination rule. For each variable, the record should say whether it was fixed by a human, selected by the system, narrowed by policy, or changed after human review.

Runtime approval needs its own label. A human who approves an agent-proposed step after the system has already selected a target is exercising oversight, but that is not the same as specifying the target at deployment. Oversight can matter enormously; it should not be hidden under the same field as configuration.

The Logging Gap

The paper proposes instrumentation as the first constructive move. Cloud-hosted agent platforms, API gateways, and multi-tenant orchestration layers could classify deployment granularity from the configuration input and operating parameters, then report that classification in audit logs with model, tenant, and capability metadata.

The authors also name the limits. Local hacktivist operations may have no cooperative platform to log anything. Providers may face legal exposure, weak incentives, boundary ambiguity, and technical difficulty. A determined actor can also make a Level 5 operation look lower-level across chained calls unless the logging system traces the full call chain.

This is where ordinary observability falls short. A tool-call trace can show that a scanner, browser, exploit-test harness, or message tool was invoked. It may not show whether the human chose the target or whether the agent discovered it. A prompt log can show the first instruction. It may not show that later subgoals, retries, retrieved plans, or sub-agent calls filled in the operative details.

A better log would preserve both path and provenance: initial goal, configuration variables, policy constraints, system-selected variables, human approvals, rejected options, sub-agent handoffs, tool calls, and final effects. The point is not maximal surveillance. It is reconstructability where delegated action can have legal or safety consequences.

Governance Standard

Every high-risk agent deployment should carry a configuration-granularity receipt. The receipt should record the human-specified objective, target class, forbidden targets, method constraints, tool set, approval thresholds, runtime stop controls, delegated subgoals, and the point at which the system began selecting operative details.

The receipt should distinguish configuration from runtime oversight. A human approval button after an agent proposes a step is not the same thing as a human fixing the operation at deployment.

Governance should also require an operational envelope before high-impact tools are available. The envelope should name authorized systems, prohibited targets, allowed test methods, data-use limits, network boundaries, time windows, rate limits, escalation rules, and safe-stop controls. If the user supplies only a broad goal, the runtime should narrow, ask for authorization, or refuse rather than silently letting the model choose the missing operational content.

The platform should preserve a decision trail outside the model's own narration. The log should say which facts came from the user, which came from a trusted policy source, which came from a tool result, which were inferred by the model, and which were approved by a human. That distinction matters because later reviewers need to know whether the system followed a human instruction, a policy rule, or its own generated plan.

The Spiralist rule is simple: authority does not live only in the final action. It also lives in the level of specification that launched the action chain. If a system can choose the target, method, timing, and execution path after the human gives only a goal, that fact belongs in the audit trail.

Granularity Receipt

A minimum granularity receipt should contain: task identifier, human sponsor, agent identity, model or runtime version, initial objective, specified target or target class, specified method or method family, authorized tools, prohibited tools, data sources, forbidden targets, time window, autonomy level, required approvals, stop controls, sub-agent delegation rules, variables selected by the system, variables changed after human review, and final action path.

The receipt should also carry an evidence status. Some fields may be directly observed from structured configuration, some inferred from prompts, some asserted by the operator, and some unknown. Unknown granularity is itself a governance fact. A system should not treat "not logged" as "human specified."

For cyber systems, the receipt should separate discovery, validation, exploitation, patching, disclosure, and messaging. Those are different authorities. A person may authorize vulnerability discovery on owned systems without authorizing exploitation against third-party systems or public disclosure of a proof.

Limits

This is a doctrinal and governance paper, not an empirical claim that a particular attack happened or that a particular civilian should be classified in a particular way. It analyzes a structural mismatch between an existing legal test and increasingly autonomous agent architectures.

Granularity logging would not by itself settle attribution, intent, proportionality, precautions, or accountability. It would also not solve the hardest adversarial cases where actors run systems locally and falsify records. Its narrower value is evidentiary: it names a property that legal and governance systems need but often fail to record.

It is also possible to overread the paper. A Level 5 classification does not prove innocence, and a Level 1 classification does not answer every legal question. Granularity is one piece of the causal and governance record. It should sit beside intent evidence, command relationship, system capability, target effects, human oversight, operational context, and post-action conduct.

Source Discipline

Use the Saito, Godsoe, and Tan paper for its doctrinal argument, scenario structure, five-level goal-specification spectrum, and instrumentation proposal. It is an arXiv preprint, not a judicial decision, treaty text, operational incident report, or universal AI governance standard.

Use ICRC sources for the humanitarian-law frame: direct participation in hostilities, cyber operations during armed conflict, and the ICRC's legal positions. The ICRC guidance is a primary humanitarian-law source for this discussion, but it is still legal interpretation. It should not be collapsed with statutory AI governance, platform logging guidance, or technical security standards.

Use NIST, CISA, MCP, and EU AI Act sources as current governance context for agent identity, privilege control, authorization, logging, and human oversight. They help specify what a record-bearing agent runtime could look like. They do not decide IHL classification, and they do not certify any particular cyber agent deployment.

Sources

Return to Blog