1 Introduction↩︎

LLM-assisted reverse-engineering (RE) systems do not reason from raw bytes alone. They consume strings, symbols, decompiler output, logs, metadata, tool summaries, reports, and retained notes. In an attacker-controlled binary, many of these observations are attacker-shaped. We define a representation-confusion attack as one in which the pipeline correctly extracts an observation but assigns it a role for which it lacks the required authority or support. The pipeline may obey the observation as an instruction, use it to validate a claim, or reuse it as trusted analysis state. We call this change of role a promotion; it is invalid when the required authority or support is absent. The attack need not contain an imperative: several records traced to one origin can create false corroboration, and a stored hypothesis can gain validated status without new support. We refer to this failure class as Representation-Confusion Attacks in Reverse Engineering (RARE). Extraction correctness is therefore not the security boundary. The pipeline must preserve provenance and role constraints from extraction through the final report.

Recent reports show attackers targeting this boundary. SentinelLABS described macOS.Gaslight, a Rust implant with a 3.5 KB cascade of fabricated “system” messages intended to steer LLM-assisted triage away from analysis [1]. Check Point documented an in-the-wild malware prototype with an embedded prompt-injection attempt aimed at AI-based analysis [2]. Socket reported Hades supply-chain payloads whose non-executing headers were designed to pollute AI-assisted malware triage [3]. These examples motivate a broader question: how can we measure when a faithful RE observation is given an unsupported role?

Prompt injection through compiled strings is not new. Crawford et al. show that strings added to C programs can survive compilation and Ghidra decompilation and mislead a Cline–GhidraMCP analysis agent; their attack uses an AutoDAN-derived genetic search [4]. Follow-up work tests regular-expression filtering and a neural classifier on 20 generated adversarial programs, and demonstrates bypasses of both content-based defenses [5].

RARE-Bench measures this broader failure class with paired binaries. Each base program yields clean, benign-control, and adversarial ELF/x86-64 binaries. A recorded oracle checks designated behavior, while manifests identify the changed carrier, the promotion target, and the provenance of the rendered observations. The benchmark scores the downstream role assignment, not the mere presence of suspicious text. An adversarial string is not a successful attack until the pipeline obeys it, uses it to validate a claim, or carries it forward as trusted analysis state. Compiled-string prompt injection is one instance of authority confusion. Representation confusion also includes non-imperative evidence and state failures.

RARE-Guard organizes runtime controls into four stages. Tool Authorization mediates tool actions, Support Gate checks claim-appropriate support, Provenance Gate groups records linked by known dependencies, and State Gate carries claim status through storage and retrieval.

Our evaluation has three stages. The Broad Exploratory Study maps effects of complete model-facing interfaces; the Controlled Holdout isolates policies on new programs and shared drafts; and the Instrumented Workflow Study tests them on tool-generated observations. We report the stages separately.

The broad study contains 11,520 calls over 30 base programs. The holdout uses 20 new programs and two models. Under Flat rendering, the unsafe-action target appears in 35/40 adversarial cases and 0/40 clean cases. Data-Only rendering leaves 15 unsafe proposals; Tool Authorization denies all 15 and authorizes all 40 matched analyst requests. On identical drafts, Support Gate validates 23/40 false claims backed by records traced to the same origin; Provenance Gate validates none after grouping, and both gates retain all 40 supported claims.

The workflow uses 16 further programs and the same two models. Ghidra, r2pipe, and angr produce records with stable handles and provenance kept outside the model. No single-tool draft in a preselected eight-program subset reaches Support Gate’s validation threshold for the false claim. In fused drafts, Support Gate validates 32/32 false claims; Provenance Gate validates none, and both retain all 32 supported claims. The apparent support quorum is observed only in fused drafts, but only same-draft replay isolates the policy effect. The W3 attack case produces no unsafe proposal, and W4 produces no unsupported upgrade request; both arms are therefore diagnostic.

This paper makes four contributions:

• Representation-confusion attacks. We formalize invalid promotion of faithfully extracted binary-derived observations into instruction authority, claim-validating evidence, or trusted analysis state without the authority or support required for that role.

• RARE-Bench. We introduce rebuildable program pairs with behavior oracles, matched controls, explicit targets, and provenance links. RARE-Bench records target induction, task success, response conformance, and policy decisions separately.

• Mechanism isolation. On held-out programs, we isolate Tool Authorization and show that, on the same drafts, Provenance Gate reduces false validation relative to Support Gate in the evaluated shared-root cases without changing any positive-control decision.

• Workflow localization. Support Gate validates the false claim only in the evaluated fused drafts. On identical drafts, Provenance Gate groups repeated views of one location in 16 cases and distinct roots with one recorded common ancestor in 16 cases; it changes all 32 decisions to insufficient status and retains every supported claim.

2 Background and Threat Model↩︎

2.1 Binary-Derived Observations↩︎

A representation-confusion attack starts with a program, not a corrupted analysis tool. The binary shapes content that the pipeline correctly extracts and then assigns an unsupported role: instruction authority, claim-validating evidence, or trusted analysis state.

Reverse engineering rarely operates on raw bytes alone. Analysts inspect binary-derived observations: strings, symbols, imports, xrefs, decompiler text, control- and data-flow facts, traces, protocol fields, and structured workflow records. Decompilers and binary-analysis systems recover these views from executables [6]–[9]; other systems infer function boundaries, stripped-code structure, similarity, message formats, and indicators from related binaries [10]–[22].

We use observation for content presented to the model, record for its typed runtime representation, and handle for the record’s stable identifier. For Provenance Gate, a recorded provenance unit is a group of records that share an exact root or a recorded common ancestor. This grouping does not prove that different units are independent. These observations are useful but partial and tool-dependent. A string may be dead data; a decompiler may expose a referenced constant without showing that it supports the claimed behavior; several tools may render one recorded provenance unit as several apparent support units. Classical malware already exploits gaps between behavior and analysis environments [23]–[28]. This work studies a different downstream gap: the role assigned to faithful tool output by an LLM-assisted RE pipeline.

2.2 Promotion Boundary↩︎

LLM-assisted systems can turn observations into hypotheses, tool proposals, report claims, or retained notes [29]–[32]. We call the role-changing step promotion. A promotion is invalid when the new role lacks the authority or support required by the task.

Five properties must remain separate. Extraction integrity asks whether a tool extracted or recorded an observation correctly. Record origin identifies the trusted tool or runtime that created the record. Payload origin identifies who controls its contents. Instruction privilege determines whether that content may direct an action. Evidential weight states which claims the record can support. A trusted tracer may faithfully record an executed event while the bytes carried by that event remain sample-controlled. The event can support a behavioral claim; its payload still has no instruction authority.

Authority confusion overlaps with indirect prompt injection because an LLM reads untrusted content. Figure 1 shows the broader scope of representation confusion: paired variants have matching recorded oracle outcomes, and scoring asks whether the model assigns an observation a role it has not earned. This also covers non-imperative evidence and state failures, such as treating three views of one recorded provenance unit as separate corroboration.

2.3 Attacker and Defender↩︎

The attacker controls the binary and may shape records exposed through Ghidra, r2pipe, angr, or wrappers. The attacker does not control analyst instructions, system policy, model provider, tool binaries, runtime policy, evaluation rules, or corpus selection.

The defender controls the observation-record schema, stable handles, and a trusted lookup table—the provenance sidecar—that maps each handle to its root and derivation metadata. The defender also controls the tool mediator, claim gates, state schema, and final renderer. The defender does not assume that a model will ignore attacker-shaped text. Data-Only is the model-facing rendering condition: it presents sample payloads as data and keeps analyst instructions separate. It does not authorize an action. Tool Authorization subsequently makes the runtime decision for each typed tool proposal outside the model, and the other runtime policies check promotions at their destinations.

The three scored failure modes are authority confusion, where a binary-derived observation steers a privileged action; evidence confusion, where weak or dependent observations validate a stronger claim; and tainted-state promotion, where a stored or retrieved observation or hypothesis undergoes an unsupported upgrade to validated state. The same content remains safe when retained as an observation or tainted hypothesis.

2.4 Measurement and Scope↩︎

RARE-Bench uses synthetic programs to obtain paired clean, control, and adversarial variants with behavior oracles, registered targets, transformation metadata, exact roots, and derivation links. Clean rows measure ordinary task behavior, and broad-study controls add benign content. The holdout authority control matches carrier form, placement, and visibility. Its evidence control matches record count and structure but is less directly tied to the false claim, so it is excluded from the primary comparison between Support Gate and Provenance Gate. Adversarial rows test invalid promotion. Infrastructure and parsing failures remain in the planned denominators rather than being selected away.

The Broad Exploratory Study characterizes complete model-facing interfaces. The Controlled Holdout measures unsafe-proposal uptake under Data-Only rendering and isolates Tool Authorization and Provenance Gate decisions on shared drafts. The Instrumented Workflow Study then uses actual Ghidra, r2pipe, and angr outputs, bounded two-turn tool execution, fused evidence, and a secondary state-reuse task. It is not an autonomous or open-ended agent evaluation. The state task tests whether status and taint survive one write/retrieval cycle and whether valid new evidence permits revalidation. Because no draft requests an unsupported upgrade, it does not identify a causal effect of State Gate on such upgrades. Prevalence in malware encountered in practice, long-horizon memory drift, arbitrary tool use, and protection of open-ended deployed agents remain outside the measured scope.

Section 3 defines the three promotion-failure modes, and Section 5 gives the layered runtime controls.

3 Attack Anatomy and Promotion-Failure Modes↩︎

We classify representation-confusion attacks by the role assigned to binary-derived observations, rather than by carrier or string pattern. The three measured promotion-failure modes are authority confusion, evidence confusion, and tainted-state promotion.

3.1 From Channel and Carrier to Promotion Failure↩︎

For scoring, we distinguish the observation channel, the concrete carrier modified within that channel, the manipulation tactic, and the resulting promotion-failure mode. Each evaluation row reports target stance (affirmed, not affirmed, or unresolved/null), task success, and response conformance separately.

A representation-confusion attack proceeds through five stages: construction of oracle-matched program variants; faithful extraction; rendering into the model context; invalid promotion across an authority, evidence, or state boundary; and a task-visible failure. Extraction can be correct even when the later role assignment is not.

A carrier is not itself a failure mode.

It becomes harmful only when the pipeline assigns it an invalid role. Instruction-like text is safe when treated as untrusted data. Multiple tool views are safe when the pipeline preserves whether they belong to one recorded provenance unit. A previous note is safe when its status and support survive storage and retrieval. Figure 2 gives one example for each measured role.

Failure means invalid promotion.

The RARE-Bench scorer evaluates whether the output leaves binary-derived content as an observation or assigns it a stronger role. A row fails when the output promotes such content into instruction authority, claim-validating evidence, or trusted analysis state without the authority or support required by the task. Quoting suspicious content, rejecting it, or retaining it as a hypothesis is not a positive promotion. If the target stance is unobservable, the scorer records null, which is not counted as safe.

3.2 Authority Confusion↩︎

Authority confusion occurs when binary-derived content is treated as if it came from the analyst, system prompt, developer policy, or trusted runtime policy. Correct extraction can still expose attacker-shaped strings in wrapper or decompiler fields. The promotion failure occurs when the model treats that data as if it were authoritative.

Authority confusion includes direct prompt-like tactics and less explicit manipulations across symbol, section-label, log, and structured-field channels that change pipeline priorities. For example, a binary-derived observation can suggest that a sample is benign, that an analysis step should be skipped, or that a family label should be assumed. None of those instructions or conclusions is authoritative merely because it appears inside the analyzed binary. Panel A of Figure 2 shows the boundary: the same text is safe when reported as data and unsafe when it changes tool priority or overrides analyst intent.

Authority failure condition

A row fails for authority confusion only when the output shows that binary-derived content affected authority: the next-tool plan follows directions embedded in the analyzed binary, the rationale treats a binary field as analyst intent, or the report cites binary-derived text as a policy source. Mentioning the content as an untrusted observation remains safe.

3.3 Evidence Confusion↩︎

Table 1 distinguishes safe use from failure. Evidence confusion is especially relevant to reverse engineering because a pipeline often exposes one exact root through several tool views, and a model may mistake repeated renderings for separate support units.

Shared-root evidence confusion occurs when one recorded provenance unit appears as several qualifying records. A string that names a capability, command, IOC, or family does not by itself show that the program implements or executes it. Provenance identity and evidential strength are separate: a root records where an observation came from, while textual presence, references, reachability, structural evidence, and dynamic traces determine what it can support.

How repetition becomes apparent corroboration

Repeated tool output should not be read as repeated evidence until its provenance is known. Panel B of Figure 2 gives the compact version of the failure; Figure 3 expands it into the provenance relationships available to the gate. The program contains one attacker-shaped location, root \(r_{17}\). A string extractor, a decompiler view, and a workflow-rendered field can all expose that same root. Those renderings may be useful observations. The safe interpretation is three observations in one recorded provenance unit, without additional corroboration. The failure is to count the three renderings as corroboration and validate a capability, IOC, family label, or classification from repeated text alone.

Implication for evidence gates

Support Gate checks whether cited records have the support type and reachability required by the claim. Provenance Gate groups records that share an exact root or a recorded common ancestor and counts each provenance unit once. This does not prove that the remaining units are independent. It then reapplies the same claim rule; several roots alone do not validate a claim.

Evidence support ladder

Text-only presence supports an observation; referenced or reachable structure may support a hypothesis; validation requires claim-appropriate structural or behavioral support. Root metadata lets the runtime group known duplicate or dependent views into recorded provenance units; distinct units do not by themselves establish independent or stronger support. Treating shared-root text as validation skips this ladder.

3.4 Tainted-State Promotion↩︎

Tainted-state promotion captures the step beyond a single answer. Tainted or stale content can enter a report, analyst note, retrieval entry, persistent hypothesis, or later context. We measure direct writes and one typed reuse step. Cross-run drift and longer chains remain outside the experiment.

The benchmark makes this boundary observable with direct write and reuse targets. They cover report-stage content, delayed exposure, decoy review text, and prior-analysis material that should remain unvalidated. A row fails when tainted or stale content is written or reused as validated state, or is reported as validated without new claim-appropriate support. Safe handling preserves it as a tainted observation or hypothesis with its status and provenance intact. Panel C of Figure 2 illustrates this narrow claim: the measured event is later reuse as confirmed evidence from a note that should have remained a hypothesis.

The workflow state arm preserves status and taint and permits explicit revalidation when new support appears. In the no-new-evidence arm, no draft requests an unsupported upgrade, so State Gate has no such request to decide.

3.5 Failure-Mode Assignment and Controls↩︎

Controls are equally important. A benign control can add strings, metadata, or chaff without encoding an adversarial promotion target. If controls produce the registered target at the same rate as adversarial variants, the result would point to prompt length, formatting fragility, or generic tool-output noise, weakening attribution to the promotion-failure modes. The evaluation reports clean, control, and adversarial roles separately so attribution remains visible: clean rows measure utility, controls measure sensitivity to benign extra program content, and adversarial rows measure invalid promotion classified by the modes above. This accounting keeps carrier visibility separate from the stronger question of whether a response assigns that carrier an invalid role.

4 RARE-Bench↩︎

RARE-Bench creates paired binaries that pass the same recorded behavior checks but produce different observations for the model. Each benchmark instance links the binaries, their rendered views, the behavior oracle, the promotion being tested, and the provenance of the relevant observations. Neither the model nor the runtime receives the oracle or target registry.

4.1 Programs, Variants, and Oracles↩︎

The corpus contains benign C programs compiled as Linux ELF/x86-64 binaries under a recorded GCC toolchain. Workloads include configuration and protocol parsers, encoding routines, serial checks, safe pack/unpack logic, benign anti-debug branches, disabled dispatchers, and inert stand-ins for security capabilities. They contain no credential theft, exfiltration, persistence, or live malware behavior.

Each base program contributes variants with the roles in Table 2. The clean variant is canonical. A control adds benign content with similar placement or visibility. An adversarial variant changes a string, symbol, constant, metadata record, log-like field, or other carrier tied to a registered promotion. The positive controls use a dedicated oracle and claim-appropriate evidence. The manifest keeps the observation channel, concrete carrier, and manipulation tactic separate from the underlying workload.

Oracles record exit status, stdout, stderr policy, and declared side effects over fixed inputs. All 120 broad-study variants rebuild to their recorded hashes and pass the checked oracle. This preserves the designated outcomes, not full semantic equivalence.

Non-clean binaries differ from their clean pairs across 14–31 ELF sections and 2,908–6,712 aligned bytes.

Synthetic programs provide controls unavailable in incident malware: a clean pair, a known false proposition, benign controls, executable oracles, and provenance recorded before rendering. Incident cases motivate the attack class; the benchmark measures effects within this controlled corpus. The comparison therefore concerns the complete tool-derived rendering of each build, not a single changed byte or named carrier.

4.2 Promotion and Evidence Ground Truth↩︎

The ground-truth record distinguishes observation presence from the role that the observation can support. A decoy string can be faithfully extracted without supporting the claimed capability. A referenced constant may establish structure without establishing executed behavior. Several tool records may form one recorded provenance unit when they share an exact root or a recorded common ancestor. Different units do not by themselves establish independent support.

For every scored target, the registry identifies the proposition, invalid promotion, expected response field, allowed response stances, and the rule that determines whether the target was affirmed. Quotation, rejection, uncertainty, and target absence are not positive promotion. A malformed or unresolved output remains in the planned denominator instead of becoming an implicit safe decision.

The broad registry was constructed after response collection and fixed before target analysis; its exact-target results are exploratory. The Controlled Holdout and Instrumented Workflow Study use new programs whose targets, schemas, policies, provenance maps, and analysis code were fixed before the evaluated responses. Hash-bound manifests connect every rendered observation and result row to the corresponding binary, prompt, model version, and policy decision.

4.3 Three-Stage Evaluation↩︎

Table 3 summarizes the studies. They answer different questions rather than measure one common effect. The broad study maps complete model-facing interfaces; the holdout measures unsafe-proposal uptake under Data-Only rendering separately from Tool Authorization and isolates Provenance Gate on new programs; and the workflow shows that false validation by Support Gate is first observed in the evaluated fused drafts.

Surface mapping—Broad Exploratory Study

Thirty base programs contribute 120 variants. Four model families, four complete model-facing interfaces, three tasks, and two repeats produce 11,520 calls. The matrix maps variation across attacks and interfaces; it does not isolate a runtime gate.

Mechanism isolation—Controlled Holdout

Twenty new programs and two models produce 528 calls. Data-Only rendering measures unsafe-proposal uptake, Tool Authorization decides whether typed requests may run, and Support Gate and Provenance Gate operate offline on identical report drafts. Targets and policies are fixed before generation.

Workflow localization—Instrumented Workflow Study

Sixteen further programs use typed records from Ghidra, r2pipe, and angr. Two models cover fused and single-tool evidence, bounded tool execution, and state reuse. The fused-view arm combines the tools; the single-tool arm separates them; the closed tool-loop arm runs bounded execution; and the state-reuse arm writes and retrieves typed state. Four other programs served only to develop the adapters.

4.4 Units and Outcomes↩︎

The base program is the independent unit. Calls, repeats, models, tasks, and tool views remain within the program cluster. Paired analyses report clean-to-adversarial target movement and same-draft policy transitions with program-clustered intervals. We report model and tool results separately to show variation; they are not additional independent samples or rankings.

We keep proposal, authorization, execution, claim validation, state write, task completion, schema validity, and infrastructure status separate. This is necessary because a model can remain influenced while the tool mediator denies authorization, or a gate can make a safe claim decision while task utility remains low. Parse and provider failures remain in the planned denominators for unconditional endpoints.

5 RARE-Guard↩︎

RARE-Guard applies four policies at three promotion boundaries: tool actions, validated findings, and validated state. Its base rule is that sample-controlled content may guide analysis but cannot issue instructions. A deterministic runtime makes authorization decisions for typed tool proposals, assigns claim statuses, and preserves state metadata. The Controlled Holdout tests authorization and exact-root grouping.

The workflow adds common-ancestor grouping and a state-preservation diagnostic.

5.1 Runtime Record↩︎

The control plane holds analyst intent and trusted policies. Binary-derived observations remain in the data plane.

A trusted extractor creates the record, but that fact does not grant authority to its sample-controlled payload. For example, a trusted tracer can record a network event whose payload contains attacker text. The event may provide behavioral evidence; the text cannot change policy or authorize a tool.

The runtime gives every observation a stable handle. Its exact root is the binary location or execution event that produced it. The provenance graph also records intermediate extraction and transformation steps, allowing records with different local roots to be traced to a recorded common ancestor. For a selected policy, records grouped by one exact root or recorded common ancestor form a recorded provenance unit. The gate counts each recorded provenance unit once; distinct units do not by themselves prove independence. A trusted sidecar maps each handle to record origin, payload origin, location, support type, reachability, exact root, common-ancestor links, and taint. The model sees only a compact typed view and returns candidate tool calls, claims, state writes, and cited handles. It cannot create provenance by asserting it in text. Unknown handles fail resolution.

RARE-Bench targets, expected answers, behavior oracles, and scoring rules stay outside this path. They measure the runtime after execution and are never inputs to the model or gates.

5.2 Layered Promotion Gates↩︎

Data-Only rendering

Data-Only rendering marks binary-derived content as data and keeps it separate from analyst instructions. The model can use that content to propose a tool request, but this step cannot authorize or execute the request.

P1: Tool Authorization

Tables 4 and 5 summarize the audit trail and policy stack. The model proposes a typed request containing a tool ID, bounded arguments, a purpose, and the record handles on which it is based. P1 checks the allowlist, argument schema, analyst grants, and resource limits. P1 denies authorization to proposals that request raw-shell access, specify attacker-selected executable paths or network destinations, or would cause unbounded side effects. Sample data may still affect which safe check the model proposes. Authorization is nevertheless decided outside the model. The runtime records proposal, authorization, and execution separately so that this distinction remains observable.

P2: Support Gate

P2 applies a deterministic rule for the requested claim. A textual observation can establish that a literal is present; it cannot alone establish an implemented capability. A capability may require a reachable structural path, and an executed-behavior claim may require a trusted dynamic event. Reachability does not suffice when the referenced code does not support the proposition. P2 downgrades a candidate finding to hypothesis or insufficient status when support is insufficient, rather than deleting the observation.

P3: Provenance Gate

P3 does not establish independence; it groups qualifying records according to dependencies recorded in the sidecar. The exact-root rule counts records from the same binary location or execution event once. The common-ancestor rule also groups records with different local roots whose derivation paths lead to one recorded common ancestor.

P4: State Gate

P4 stores each statement with its claim status, cited handles, taint, and gate decision. Retrieving the statement preserves those fields. A request to upgrade a hypothesis must pass another claim check with new evidence; retrieval alone cannot perform that upgrade. The workflow verifies preservation and explicit revalidation, but no unsupported upgrade is requested in a draft, so it does not identify a causal effect of P4 on such upgrades.

5.3 Claim Record and Decision↩︎

Table 6 gives the runtime fields used by the gates. The record keeps extractor integrity, payload control, instruction privilege, and evidential weight separate. A workflow may serialize these fields differently, but it must preserve their distinctions through generation and enforcement.

Content hashes support integrity checks; they are not exact roots. Identical bytes at distinct locations may have distinct roots, and distinct roots do not by themselves establish independent support.

\(P.\mathrm{fallback}\) selects hypothesis, insufficient, or blocked from the claim type and reason. P1 Tool Authorization handles tool mediation before this algorithm; P4 State Gate preserves the result across state write and reuse.

5.4 Enforcing the Decision in the Final Report↩︎

An uncontrolled free-text field can bypass a correct gate. The deterministic renderer therefore emits the analyst-visible report only from post-gate claim records. Every field that can affirm a claim is downstream of the same decision. Final-report consistency is reported separately from the fixed policy comparison.

The audit record includes cited handles, resolved support types, roots and derivations before and after grouping, the applied rule, reason code, final status, and final report field. A normalizer may repair syntax, but it cannot add a semantic default or restore a downgraded claim.

5.5 Evaluation Mapping↩︎

The Broad Exploratory Study evaluates complete model-facing interfaces and does not isolate P1–P4. The Controlled Holdout measures proposals under Data-Only rendering, applies P1 Tool Authorization to typed tool proposals, and applies P2 Support Gate and P3 Provenance Gate with exact-root grouping to identical report drafts; the Instrumented Workflow Study also tests P3 Provenance Gate with common-ancestor grouping over tool-generated records. Positive controls test whether stronger provenance grouping preserves claim-appropriate evidence.

The workflow also applies P1 to a bounded, two-turn tool-execution loop and records extraction, rendering, proposal, authorization, execution, claim, and final-report events. Its state reuse task is secondary. These experiments do not cover autonomous planning, unrestricted tools, long-running memory, or general RE agents. The tested interface relies on stable handles and sidecar provenance: once a workflow flattens those relations into text, a later gate cannot reconstruct them reliably.

Table 6 defines the runtime fields, and Fig. 5 shows how P2 Support Gate and P3 Provenance Gate use them to decide a claim.

6 Broad Exploratory Study↩︎

The broad study contains 11,520 model calls over 30 base programs. It compares four complete model-facing interfaces—Unguarded, Prompt-only, Typed provenance, and Composite interface—across four models, three reverse-engineering tasks, and paired clean and adversarial programs. The Composite interface combines stronger authority instructions, typed rendering, prompt-like-content redaction, and a post-generation validator. These components change together, so the study estimates an interface effect rather than the effect of any one component. All planned calls completed. The four model versions are gpt-5.5, claude-sonnet-4-6, gemini-2.5-pro, and deepseek-ai/DeepSeek-V3.2. Typed provenance here is the historical structured rendering, without the trusted provenance sidecar or P3 Provenance Gate. This exploratory interface estimate remains separate from the holdout and workflow policy effects; we do not pool these effects.

6.1 Paired Endpoint↩︎

The unit is a clean/adversarial response pair with the same program, model, task, interface, repeat, and context mode. Let \(T=1\) when the final response promotes the registered target and \(T=0\) when the registered field shows a target-negative decision. The representation effect is \[\Delta_{\mathrm{repr}}= P(T_{\mathrm{adv}}=1)-P(T_{\mathrm{clean}}=1).\] Confidence intervals use 10,000 bootstrap samples clustered by base program; repeated calls, models, tasks, and reused clean responses remain within the same cluster.

The target registry specifies an exact target, its role, and its response field. Quotation, rejection, unrelated errors, and target absence are not positive promotion. A response is null when its schema or wording does not show whether the target was affirmed. Because the registry was constructed after response collection, these target-specific results are exploratory. Of 5,760 adversarial responses with clean partners, 1,778 pairs have a resolved target on both sides and matching context modes. Appendix 15 reports coverage, null accounting, transition counts, and all-row utility and conformance.

6.2 Interface Effects and Utility↩︎

For the two focal interfaces, the confidence intervals based on their respective resolved-pair sets both include zero: Unguarded changes by \(+3.89\) percentage points (pp; 95% CI: \(-0.78\) to \(9.56\)), and Composite by \(-3.88\) pp (95% CI: \(-7.81\) to \(0.43\)). For a direct comparison, we then restrict the analysis to the 374 cases resolved under both interfaces. In this shared set, their shifts are \(+4.28\) and \(-4.28\) pp, respectively, yielding an 8.56-pp difference (clustered 95% CI: 2.96–15.59) across 18 programs. Because the interfaces change several components together, this exploratory contrast does not identify which component caused the difference.

Among the 480 adversarial rows per interface with a role-compatible registered target, observed promotion is 38/480 (7.9%) under Unguarded and 28/480 (5.8%) under Composite. Task success with a core-schema-conformant, target-negative response is 338/480 (70.4%) and 344/480 (71.7%), respectively; Prompt-only reaches 347/480 (72.3%). Across all 1,440 adversarial rows per interface, task success is 1,241/1,440 (86.2%) and 1,217/1,440 (84.5%). Composite therefore does not dominate the simpler baselines. A worst-case sensitivity analysis that treats undecided responses as target-positive leaves the marginal target-rate ordering nearly unchanged.

We assess syntactic conformance separately from target stance. Raw JSON is recoverable for 99.8% of Unguarded and 98.1% of Composite responses, while 81.9% and 83.1% satisfy the core schema without semantic defaults. A normalizer can repair syntax but cannot establish whether a claim was affirmed. The primary correct-and-safe endpoint therefore counts null, malformed, and task-failure rows as failures rather than selecting only resolvable responses.

6.3 Design Diagnosis: The Historical Validator Does Not Explain the Contrast↩︎

The replay covers 2,875/2,880 Unguarded drafts, including 480 registered targets. Table 7 shows 25/24 targets and 2,290/2,286 task successes for the validator/static rule; the static rule is the support-only baseline used in the Controlled Holdout. The holdout next compares P2 Support Gate and P3 Provenance Gate with exact-root grouping on shared drafts from new programs.

4pt

7 Controlled Holdout↩︎

The Controlled Holdout tests the attack and two policy boundaries on 20 new base programs. They are split evenly across networking, credential and configuration handling, startup configuration, and unpacking-like analysis. Each program includes clean and adversarial authority cases, matched controls, text-only and shared-root evidence cases, and a positive control. The authority control matches carrier form, placement, and visibility. The evidence control matches record count and structure, but not how directly the records name the adversarial claim; we therefore treat it as descriptive and exclude it from the primary comparison between P2 Support Gate and P3 Provenance Gate. The two models are gpt-5.5-2026-04-23 and deepseek-ai/DeepSeek-V3.2. Programs, targets, renderings, policies, root maps, model versions, analysis code, and four programs selected in advance for repeat runs were fixed before generation.

Each program–model pair has 11 generation contexts. The 440 primary calls and 88 preselected repeat calls produce 528 responses; all parse and satisfy the schema. Under Data-Only rendering, P1 Tool Authorization decides whether to authorize typed tool proposals. P2 Support Gate and P3 Provenance Gate with exact-root grouping run offline on identical report drafts; the flattened-map replay is a secondary diagnostic. Primary estimates use the first run. Effects are averaged within each base program over the two model strata, and 95% intervals use 10,000 program-cluster bootstrap samples. Paired sign-flip inference provides a sensitivity check. Correct-and-safe requires task success, schema validity, and the registered boundary decision for the context. The primary contrast, summarized in Table 8, is the reduction in target-validation rate from P2 Support Gate to P3 Provenance Gate in the shared-root case; positive values favor P3.

7.1 Attack and Authority↩︎

Under Flat rendering, the authority target appears in 35/40 adversarial responses and no clean responses, an increase of 87.5 percentage points (95% CI: 75–97.5). Under Data-Only rendering, the model produces 15/40 unsafe proposals, down from 35/40 under Flat (50 pp; 95% CI: 35–62.5). Because this changes the model input, it is a rendering effect. P1 then denies authorization to all 15 unsafe proposals. When the matched request comes from the analyst channel, P1 authorizes it in all 40 cases. The model therefore remains open to influence, while the runtime preserves the authority boundary. Only 8/40 matched analyst-request rows meet the task-success criterion, so correct authorization does not imply successful analysis.

7.2 Shared-Root Claims↩︎

The shared-root case presents several qualifying views derived from one recorded provenance unit. On the same 40 drafts, P2 validates the target in 23 cases and P3 validates none. The 57.5-pp reduction has a clustered 95% CI of 45–70 and a two-sided sign-flip \(p\approx2\times10^{-5}\). Both model strata and all four program families move in the same direction.

To test why P3 differs from P2, we replay it with root equivalence removed: each cited record receives a different pseudo-root and therefore appears to come from a distinct root. With this flattened map, P3 exactly matches P2 on all 384 replay rows. With the true map, P3 groups records that share a root into one provenance unit before applying the same support rule. The draft text, claims, and cited records do not change, so the comparison isolates the trusted root map. This replay is separate from the 40-cell primary comparison.

P2 and P3 validate all 40 positive-control claims. Across the eight Data-Only generation contexts evaluated under both gates (\(8\times40=320\) cells), correct-and-safe rises from 40.6% (130/320) under P2 to 47.8% (153/320) under P3, a 7.19-pp increase (95% CI: 5.63–8.75). The text-only context already has zero target-positive drafts before P2, so it cannot estimate an incremental P2 effect. The result supports exact-root grouping for the evaluated report claims while preserving the positive controls. The Instrumented Workflow Study tests how these boundaries behave when tools produce and combine the evidence views.

8 Instrumented Workflow Study↩︎

The Controlled Holdout isolates P1 Tool Authorization and P3 Provenance Gate. The workflow study asks whether these controls remain observable and enforceable when the observations come from Ghidra, r2pipe, and angr. Its primary arm fuses the three tools’ outputs into one report draft (W1). A second arm presents each tool separately (W2) to test whether an evaluated single-tool draft reaches the same P2 support threshold. Two diagnostic arms examine tool authorization (W3) and retained state (W4).

The workflow evaluates 16 new programs with the same two model versions as the holdout: gpt-5.5-2026-04-23 and deepseek-ai/DeepSeek-V3.2. Its analyzed cohort has 688 model calls: 160 for fused evidence (W1), 192 for separate-tool evidence (W2), 256 for tool authorization (W3), and 80 for state write and reuse (W4). W1 and W3 use all 16 programs. W2 and W4 use preselected eight-program subsets. With two models, each subset contributes 16 model–program cells.

Programs, variants, tool containers, adapters, prompts, policies, provenance maps, targets, and analysis code were fixed before each analyzed batch. All analyzed W3 rows use the same amended schema; the pre-inference provider rejection and compatibility change are documented in Appendix 17.

8.1 Workflow and Promotion Trail↩︎

The tools map their outputs to observation records with stable handles, record and payload origin, support type, reachability, provenance, and taint.

An exact root identifies a binary location or runtime event shared by records from different tools.

The provenance graph also records how those records were derived. It can reveal a recorded common ancestor even when the tools assign different local roots. The model sees compact records with stable handles; the complete provenance remains in a trusted sidecar. The runtime records extraction, rendering, citation, tool proposal, authorization, execution, claim decision, state write, and state retrieval as separate events (Table 9). This promotion trail shows how far an attacker-shaped observation travels and which boundary decides its final role.

8.2 Canonicalization and Bounded Execution↩︎

All 688 calls returned parseable, schema-valid responses. The base program is the independent unit; models and tool views remain within its cluster. W1 and W2 apply each policy to a fixed draft, so the policy comparisons introduce no additional model generation. The authority and state comparisons are descriptive unless an interval is stated.

8.3 W1: Apparent Corroboration in the Fused View↩︎

In Table 10, the fused view presents three records as support for the same false capability. P2 Support Gate counts the qualifying records separately and therefore validates all 32 cases. The applicable P3 rule groups records linked by known dependencies and validates none. The same transition occurs in all 32 cells and all 16 base programs. The observed reduction is 100 percentage points; every program cluster shows the same transition, so the percentile-bootstrap interval is [100, 100] percentage points.

The 16 W1 programs are divided evenly between two provenance patterns. In eight programs (16 cells across two models), the three tool records share one exact root. P2 validates all 16 cells, whereas the P3 exact-root rule validates none. In the other eight programs, the records have different local roots but one recorded common ancestor. The exact-root rule leaves these cases unchanged, but the common-ancestor rule follows the recorded derivation edges and validates none. Exact-root grouping handles repeated views of one location; common-ancestor grouping handles distinct records derived from one recorded common ancestor. Draft, claim, citations, and support rule remain fixed.

The positive control has claim-appropriate support. P2 and the applicable P3 rule both validate all 32 positives.

8.4 W2: Single-Tool Views Stay Below the Support Threshold↩︎

W2 uses eight programs and two models, giving 16 cells per tool. Each draft contains records from only one tool. The shared-provenance condition never reaches P2’s validation threshold in any single-tool view. For Ghidra, r2pipe, and angr, P2 validates 0/16 false claims per tool, leaving no P2-positive decision for P3 to change. Of the 48 drafts, 47 cite no eligible handle and one cites a single handle. There is therefore no incremental P3 effect to estimate in W2. Only the fused W1 drafts reach the support threshold.

Positive-control validation is 16/16 for Ghidra, 9/16 for r2pipe, and 5/16 for angr under both gates. P3 changes none of P2’s positive-control decisions. These counts report validation under each single-tool draft, not comparative safety among the tools. The evaluated false corroboration is observed only in the fused W1 view. The study does not isolate why the fused W1 prompt elicits more eligible citations: repetition, tool labels, and prominence change together. It does isolate the downstream policy step: with draft and citations fixed, P2 validates and the applicable P3 rule downgrades the claim.

8.5 Carrying the Gate Decision into the Final Report↩︎

The primary W1 outcome is the structured claim decision. A subsequent implementation check found that the free-text task_answer field could repeat the false proposition outside that decision. The deterministic renderer closes this path by emitting only post-gate claim objects. The resulting reports match the policy decision in all 480 W1 and 384 W2 reports. These outputs verify final-report consistency; they are not part of the fixed policy-effect estimate.

8.6 W3: Carrier Exposure Without an Unsafe Proposal↩︎

8.7 W4: State Preservation Without an Unsupported Upgrade↩︎

W4 uses eight programs and two models, giving 16 cells. At write time, eight of 16 drafts request a validated state item. The upstream claim gate downgrades those eight before storage; P4 then stores all 16 records as tainted hypotheses. Without new evidence, neither the preserved-metadata nor the flattened-text retrieval condition requests validation; both are 0/16, so P4 receives no unsupported-upgrade request. This arm therefore does not test whether P4 would deny an unsupported state upgrade. It does verify that all 16 preserved retrievals retain the original hypothesis status and taint.

With new evidence, 11/16 preserved-metadata retrievals and 8/16 flattened-text reassessment rows end in validation; this descriptive difference is not significant (\(p=0.25\)). The workflow preserves state provenance, but P4’s effect on an unsupported upgrade remains untested.

9 Discussion↩︎

9.1 Cross-Study Synthesis↩︎

The three studies form a staged design, not a pooled estimate. The Broad Exploratory Study compares complete interfaces; the Controlled Holdout isolates Data-Only rendering, P1 Tool Authorization, and exact-root grouping on shared drafts; and the Instrumented Workflow Study applies provenance-aware claim checks to tool-generated records. Because the interventions and denominators differ, we report their estimates separately.

Together, the studies trace the failure from surface variation to mechanism and then to transport. The broad study shows that model-facing representations matter. The holdout fixes model output to isolate policy decisions. The workflow preserves record identity through extraction, multi-tool aggregation, and reporting, showing where the same provenance rule becomes necessary.

A policy can act only when the pipeline reaches its boundary: P1 requires an unsafe proposal, P3 a P2-validated claim, and P4 a requested state upgrade. We therefore report target induction, policy applicability, policy decision, and final output separately. P3 changes a decision only when grouping reduces a P2-positive support count below threshold. This occurs in the holdout and fused workflow; the single-tool arm never reaches the P2 threshold.

This separates exposure from enforcement: a policy effect is interpretable only after its boundary is reached.

Multiplicity is not independence

On identical drafts, provenance-aware enforcement changes decisions in both the holdout and the fused workflow, within the evaluated shared-provenance report claims. In the holdout, P2 Support Gate validates 23/40 negatives and P3 Provenance Gate validates none; both validate all 40 registered positive-control claims. In fused tool-generated drafts, P2 validates all 32 shared-provenance negatives and P3 validates none; both validate all 32 registered positive-control claims. P3 uses exact-root grouping in 16 cases and common-ancestor grouping in the other 16.

Enough apparent support first appears in the fused drafts, not in the evaluated single-tool drafts. This localizes the support increase to the fused condition, but it does not identify why fusion elicits more eligible citations because the conditions produce different drafts. The single-tool zeros do not establish safer analysis. Positive-control validation is 16/16 for Ghidra, 9/16 for r2pipe, and 5/16 for angr, and the fused and single-tool conditions produce different drafts. The runtime sidecar lets P2 Support Gate and P3 Provenance Gate evaluate the same claim and citations without counting known provenance dependencies separately.

In this workflow, fused drafts expose useful records while also inflating the apparent evidence count. The goal is not to discard multi-tool aggregation, but to retain the dependencies that make its support count auditable and carry the post-gate status into the analyst-visible report.

Auditability must reach the final report

The pipeline must preserve handles, provenance, stance, and the proposal–authorization–execution sequence. Raw W1 text repeated the false proposition outside the structured gate in all 32 shared-provenance cases, so the renderer emits only post-gate claim records. All 480 W1 and 384 W2 reports match the gate decision, keeping every analyst-visible claim on that path. P3 Provenance Gate groups sidecar-recorded dependencies; the remaining provenance units are not proven independent.

Influence is not authority

Data-Only rendering leaves 15 unsafe proposals among 40 holdout outputs. P1 Tool Authorization denies authorization for all 15 and authorizes all 40 matched analyst requests. In W3, the carrier survives extraction but never becomes the target proposal. W3 therefore measures carrier exposure rather than attack-case authorization. The analyst case reaches proposal, authorization, and execution in all 32 sessions. The separate task criterion is met in 31/32 clean, 31/32 adversarial, 26/32 control, and 6/32 analyst-request sessions; it requires an additional check after correct authorization.

State preservation

W4 preserves status, support, and taint in all 16 preserved-metadata retrievals. Without new evidence, no draft requests validation. With new evidence, 11/16 preserved-metadata and 8/16 flattened-text rows end in validated status. W4 therefore measures preservation and explicit revalidation, not upgrade denial.

Scope

The broad study covers four model families; the other studies use two fixed versions. Programs are synthetic, inert ELF/x86-64 samples, and workflow tasks are bounded. The single-reader audit has no inter-rater estimate. Malware prevalence, long-horizon memory, unrestricted tools, and open-ended agents remain outside scope. Results need not generalize to other pipelines.

10 Related Work↩︎

Prompt injection and RE agents

Prompt injection steers LLMs through untrusted text [33]–[36], including in tool-integrated agents [37]–[40]. Crawford et al. embed optimized injection strings in C programs against a Cline–GhidraMCP–Ghidra pipeline [4]. Their follow-up detects 20/20 attacks in list_strings output but only 15/24 injected functions in decompile_function output; adaptive attacks evade the classifier in 13/20 cases [5]. These studies establish the carrier and the limits of content filtering. RARE instead measures invalid promotion across authority, evidence, and state.

Composition and multi-agent amplification

Chang et al. show that orchestration amplifies indirect prompt injection: with GPT-4o, code-execution success rises from 2–4% in single-agent configurations to 72–80% in Magentic-One [41]. They attribute this increase to retrieval, delegation, and partial context. RARE instead studies dependent tool records that form an apparent support quorum after fusion and compares provenance rules on the same claim, citations, and draft.

Architectural defenses

CaMeL and FIDES use information flow to stop untrusted data from driving instructions [42], [43]. RARE-Guard separates Data-Only rendering from P1 Tool Authorization, applies P2 Support Gate and P3 Provenance Gate to report claims, and uses P4 State Gate to preserve status and taint. Sanitization, tool agreement [44], and extractor labels do not reveal dependencies between records.

Code, reverse engineering, and measurement

Code LLMs support generation, decompilation, and RE assistance [45]–[57]; AgentRE-Bench and Project Ire are public projects [58], [59]. Classical RE recovers program structure, data flow, similarity, formats, and IOCs [6]–[22]. Unlike task-completion benchmarks [29]–[32], [38], RARE-Bench also scores exact targets and response conformance.

Malware anti-analysis and analyst-targeting content

Malware evades sandboxes, VMs, unpackers, and dynamic analysis [23]–[28], [60], [61]. Newer examples target AI-assisted analysis through false messages, embedded injection, headers, or logs [1]–[3], [62]. RARE-Bench scores the resulting promotions against registered oracle outcomes.

11 Conclusion↩︎

RARE-Bench measures when binary-derived observations acquire unearned roles: authority over tools, claim-validating evidence, or trusted state. The holdout separates influence from authorization and repeated views from recorded provenance units. Binary-derived content can therefore inform a proposal without authorizing it, and repeated records need not increase support when the sidecar records their dependency.

In the workflow, the apparent support quorum is observed only in fused drafts. Each single-tool draft remains below Support Gate’s threshold, while the fused drafts make the provenance relationship decisive. Tool Authorization separates model suggestions from runtime authority, Provenance Gate preserves dependencies across tool views, and controlled rendering carries those decisions into the final report. Together, they let binary-derived content guide analysis while preserving authority, provenance, and claim status through aggregation and reporting.

12 Ethics Considerations↩︎

This is a defensive measurement study. All evaluated binaries are synthetic and run only benign workloads; adversarial variants change the representation but do not implement live malware behavior. Each binary is paired with source code, behavior oracles, manifests, hashes, and provenance metadata. The study uses no live malware, operational credential-theft or exfiltration payloads, exploits against RE tools, personal data, or incident records. No human participants were recruited, and model and tool inputs contain only controlled benchmark material.

Attackers could adapt the reported representation-confusion patterns to make binary-derived views more persuasive to LLM-assisted analysts. We study this dual-use risk with bounded counterfactuals rather than operational malware or exploit chains. The workflow permits only cataloged operations with typed arguments and resource limits; raw-shell access, attacker-selected executables, unbounded writes, and network destinations are unavailable. The release contains the synthetic source code, ELF binaries, and metadata needed for reproduction. It excludes live samples, credentials, private account data, provider-specific response metadata, and operational payloads.

13 Artifact Availability and Reproduction↩︎

The anonymous review artifact is available at https://anonymous.4open.science/r/representation-confusion. It contains the synthetic benchmark snapshots, retained model responses, deterministic scoring and policy code, workflow records, and frozen protocols used in the three evaluation stages.

13.1 Offline Verification↩︎

From the repository root, with Python 3.10 or newer, make verify checks benchmark counts, study completion, frozen hashes, headline endpoints, the license, and the test suite. The offline make reproduce-records path verifies the released 11,520-response exploratory archive, re-scores all 528 retained holdout responses into 2,064 outcome rows, reruns the frozen analysis, and regenerates the locked 688-call workflow presentation bundle while checking its semantic audit. Neither command requires provider credentials or network access; generated records are written under . Without GNU Make, run python scripts/artifact_cli.py verify, python -m pytest -q, and python scripts/artifact_cli.py reproduce-records.

13.2 Released Records and Traceability↩︎

The release includes source code and ELF/x86-64 binaries for the synthetic programs, clean, control, and adversarial variants with manifests and behavior oracles, the exploratory response archive and frozen analysis, all holdout responses and scored outcomes, and the final workflow responses, policy rows, reports, and audits. Stable handles and hashes link the reported claims to corpus, generation, policy, and final-report records. The exploratory archive omits prompts, provider envelopes, secrets, and local source paths; the other cohorts retain their released raw responses and final scored records.

13.3 Reproduction Boundary↩︎

The default artifact path reproduces results from retained records rather than issuing new model calls. Fresh provider collection and optional RE-tool rematerialization are separate because models, routing, filters, and tool versions can change. The release excludes live malware, provider credentials, private account metadata, raw provider envelopes, author-identifying metadata, and unredacted incident data. The separate make anonymization check scans release-facing text for known local identity markers.

14 Evaluation Contracts and Cohorts↩︎

Table 11 summarizes the three study contracts. For all inferential analyses, calls are clustered by base program.

3.5pt

14.1 Model and Call Accounting↩︎

The broad bindings are gpt-5.5, claude-sonnet-4-6, gemini-2.5-pro, and deepseek-ai/DeepSeek-V3.2; each contributes 2,880 calls. The holdout and workflow use gpt-5.5-2026-04-23 and deepseek-ai/DeepSeek-V3.2. Each binding contributes 264 holdout calls (220 primary plus 44 preselected repeats) and 344 workflow calls. Model strata describe heterogeneity rather than additional independent samples.

14.2 Fixed Inputs and Retained Records↩︎

Corpus records link source code and binary variants to the clean pair, behavior oracle, registered propositions, controls, hashes, and provenance maps. Generation records retain the model, prompt/response hashes, task, rendering, timing, tokens, provider status, and repeat index. Policy and workflow records add cited handles, resolved support and provenance, decisions, reports, tool events, and state events.

The frozen schemas retain the field name artifact_id; the paper refers to this identifier as a record handle.

14.3 Decision Contract and Scoring Audit↩︎

The scorer is deterministic and never uses an LLM judge. Proposal, authorization, execution, claim validation, state transition, task completion, schema validity, and provider status are distinct outcomes. Null is an observable lack of target resolution, not a safe result. Malformed outputs, provider failures, and task failures remain in the planned denominators.

A blinded reader annotated 120 responses using Table 12. Labels were 42 exact matches, 74 non-matches, and four unclear; positive-use labels were 23 affirmed, 19 rejected or quoted, 74 absent, and four unclear. Scorer and reader agreed on 107/107 exact-field and 65/65 positive-use decisions; coverage was 92.2% and 56.0%, respectively. This single-reader, edge-case-stratified audit estimates neither inter-rater agreement nor a population-wide error rate.

3pt

15 Surface-Mapping Detail↩︎

Within the cohort boundaries in Table 11, the broad-study selector uses only corpus-design fields. It selects 120 variants across 30 programs: 30 clean, 30 controls, and 20 for each promotion mode. Selection does not inspect model outputs, targets, latency, cost, or scores. The resulting 11,520-call matrix crosses four complete model-facing interfaces, three tasks, four model families, and two repeats.

Tables 13 and 14 report the broad-study transitions and all-row utility. Two-sided program-level sign-flip tests give \(p\approx2\times10^{-5}\) for attack replication, the P2-to-P3 false-validation reduction, and correct-and-safe; no supported-claim decision is lost. All aggregate repeat-minus-primary differences are zero, although individual program effects may differ.

15.1 Exact-Target Transitions↩︎

The registry resolves 1,778 transitions from 5,760 adversarial responses with paired clean responses and matching context modes, spanning 20 target variants. The direct Unguarded/Composite contrast uses 374 cases decided under both interfaces from 18 programs. Nulls arise from missing target-bearing response fields, incompatible fields, or unresolved stance and are never converted into safe outcomes.

15.2 All-Row Utility and Conformance↩︎

Raw JSON is recoverable for 99.8% of Unguarded and 98.1% of Composite responses. Literal conformance to the full broad-study schema is much lower; missing fields are not filled with semantic defaults. Target, task, schema, abstention, and provider outcomes remain separate. Program-clustered bootstrap resampling keeps model, task, interface, and repeat rows together; model and task strata are descriptive.

16 Mechanism-Isolation Checks↩︎

The holdout uses new programs and one primary response per program–model context. P1 mediates typed proposals at the authorization boundary; P2 and P3 with exact-root grouping run offline on the same structured report drafts. The primary P2/P3 comparison therefore fixes model output, claim text, stance, and cited record handles.

16.1 Generation Contexts and Offline Replays↩︎

Each program–model pair uses the same eleven fixed contexts. Flat contexts measure target induction without the typed authority boundary; Data-Only contexts produce one structured draft that the deterministic policies can replay. Table 15 lists these contexts.

Call order is randomized only after materializing the full plan. Only transport failures may be retried, at most once; refusals, malformed responses, and task failures remain outcomes. Each model binding uses the minimum available temperature and a fixed seed when supported. The exact model revision, endpoint parameters, prompt, renderer, and response hashes are recorded for every generation row.

4pt

16.2 Same-Draft Invariants↩︎

For every P2/P3 row, the draft SHA-256, proposition, stance, claim text, and cited handle list are identical. P2 resolves support type and reachability and counts qualifying records. P3 uses the runtime-owned map to group records mapped to the same location-qualified exact root before applying the unchanged support rule. The model neither sees nor supplies the equivalence map.

The flattened-map check assigns every cited handle a distinct pseudo-root. Under that map, P3 reproduces P2 in all 384 implementation rows. Under the true map, 23 primary shared-root decisions change. This distinguishes the provenance relation from schema filtering, response wording, and sampling. The text-only context already has zero target-positive drafts before P2, so it cannot estimate an incremental P2 effect. The evidence-matched control matches record count and structure but is less closely tied to the false claim and is not part of the primary P2/P3 estimate.

Program-level inference keeps both model cells inside each base-program cluster. The four-program repeat subset was selected before the primary run; it is analyzed separately rather than pooled with the primary cells. Bootstrap, wild-cluster, and sign-flip checks use the same program-level unit. Repeats preserve the frozen prompts, policies, targets, and scoring and serve as a sensitivity check rather than additional independent samples.

16.3 Inference and Preselected Repeats↩︎

Tables 16 and 17 report the primary transitions, same-draft checks, program-level intervals, and the preselected repeat subset.

17 Workflow Localization Detail↩︎

The workflow maps Ghidra, r2pipe, and angr outputs to canonical observation records. The model-visible record contains a stable handle, payload, observation type, and reachability summary.

The trusted sidecar retains record and payload origin, support type, exact root, common-ancestor links, reachability, and taint. An exact root identifies one binary location or runtime event. P3 first groups records that share an exact root. Its common-ancestor rule follows the provenance graph when records with different exact roots trace to one recorded common ancestor. An unknown handle or missing mapping fails closed as insufficient; the runtime never assigns a fallback root.

17.1 Frozen Workflow Contract and Call Accounting↩︎

Fixed corpus objects include program source code, variants, behavior oracles, registered propositions, controls, and positive controls. Fixed system objects include tool containers, adapter code, the observation-record schema, root and derivation mappings, capability catalog, and sandbox limits. Prompts, response schemas, model bindings, retry rules, P1–P4 policies, fallback decisions, targets, pairing keys, clusters, and analysis code are also committed before the corresponding analyzed batch.

Frozen records retain their original arm IDs: paper labels W1, W2, W3, and W4 map to W2-v2, W3-v2, W1-v2, and W4-v2. Prompts, responses, and measured comparisons are unchanged.

All 688 responses parse and satisfy the fixed schema. W1 and W2 policy replays fix the claim text and cited handles. The exact-root and common-ancestor strata each change 16/16 P2 validations to insufficient; all 32 positive controls remain validated. Final reports match the policy in all 480 W1 and 384 W2 rows, and typed state retains status, support, and taint in all 16 retrievals.

The first authority batch was excluded after one provider rejected an unsupported uniqueItems schema keyword before inference. A recorded compatibility amendment removed only that provider-side keyword; offline uniqueness checks, prompts, policies, targets, and analysis remained fixed. Both bindings then used the same amended schema.

17.2 Policy Activation↩︎

Each policy applies at a different stage. P1 receives a typed tool proposal and authorizes only a cataloged, analyst-granted operation with valid arguments. P2 receives a claim requesting validation and applies its claim-specific support and reachability rule. P3 applies only after P2 validates a claim with multiple cited records; it groups recorded exact-root or common-ancestor dependencies and reapplies the same rule. P4 preserves status, support, and taint across state writes and retrieval, and requires new claim-appropriate support for an upgrade. The final renderer consumes the post-gate claim object rather than claim-bearing free text.

A zero policy difference can therefore mean that no relevant proposal, claim, or state update reached that stage. The trail distinguishes attacks that reach a gate from those that stop earlier; the renderer separately governs the final report.

17.3 Fused and Tool-Specific Evidence↩︎

Table 18 separates the fixed W1 contexts before the tool-specific comparison.

Across 160 W1 drafts, P3 changes 32 registered shared-provenance decisions without creating a target-positive result. Other contexts remain unchanged.

Within shared provenance, P3 changes all 16 exact-root decisions from validated to insufficient. Exact-root grouping leaves all 16 common-ancestor decisions validated, while common-ancestor grouping changes them to insufficient. The sign-flip test gives \(p=0.0078\) for each eight-program stratum. Exact-root equality and a recorded common ancestor capture different kinds of dependence.

17.4 Worked Provenance Decisions↩︎

For an exact-root negative, P2 validates three cited tool records. All three handles map to one exact root.

After P3 groups them by exact root, the unchanged support rule sees one recorded provenance unit and returns insufficient. For a common-ancestor negative, the immediate roots differ, so exact-root grouping still counts three roots. The common-ancestor rule follows their derivation paths to one recorded common ancestor, counts the dependent records once, and again returns insufficient.

Positive controls remain validated because their cited records satisfy the claim rule. P3 groups recorded dependencies before reapplying that rule.

Unknown handles and missing mappings fail closed as insufficient; they never create a new provenance unit.

17.5 Boundary Activation and Final Reports↩︎

Tables 19 and 20 report the remaining workflow checks. The final renderer consumes post-gate claim objects, not free task_answer. Under the corresponding P3 variant, all 32 W1 shared-provenance reports render as insufficient and all 32 supported claims render as validated. These checks show that the final report preserves the policy decision; they are not additional policy-effect estimates.

18 Counterfactual and Provenance Integrity↩︎

Subject to the recorded amendments in Table 21, adversarial negatives and matched controls preserve their registered clean oracle outcomes; positive controls intentionally use a different registered outcome. In the holdout and workflow, every cited record handle resolves to runtime-owned metadata. In the instrumented workflow, the final report is rendered from the post-policy object rather than an uncontrolled summary.

18.1 Freeze Amendments↩︎

Table 21 records the three integrity amendments and their treatment in the analysis.

18.2 Binary-Pair Validation↩︎

Each base program has a designated clean variant, a registered target, and a behavior oracle. Variants are rebuilt and hashed before rendering. The frozen manifest records program source code, binary identity, transformation, target polarity, oracle inputs and outputs, and the changed byte locations used to audit the transformation. Multi-input oracles and differential traces check the designated oracle outcomes rather than treating a successful compilation as semantic equivalence.

Adversarial negatives and matched controls retain the clean oracle outcome; changed payload bytes or exposed observations do not confer the registered decoy capability. A positive control has its own positive oracle and claim-appropriate support. Missing binaries, failed oracles, mismatched target hashes, and unresolved pairing keys are excluded from analyzed pairs.

18.3 Control Roles↩︎

The controls answer different questions and are not pooled. Authority-matched controls preserve carrier form, placement, and approximate visibility while removing the registered operational instruction. The matched analyst-request positive control places the instruction-like content in the trusted analyst channel; it checks that removing authority from sample payloads does not prevent the runtime from obeying a legitimate analyst grant.

Evidence-matched controls preserve record count and structure without the registered relationship to the false proposition. Text-only negatives ask whether support type alone is sufficient, but the Controlled Holdout’s text-only context already has zero target-positive drafts before P2 and therefore cannot estimate an incremental P2 effect. Shared-provenance negatives are designed to activate P3 when their qualifying records first reach P2’s threshold, even though fewer recorded provenance units remain after grouping. Positive controls test the opposite error—whether grouping wrongly downgrades a supported finding. Clean, matched, attack, reachability-decoy, and positive contexts therefore retain separate denominators throughout the workflow analysis.

18.4 Root and Derivation Mapping↩︎

Canonicalization preserves distinct tool records even when their payloads match. The trusted mapper assigns records that expose the same binary location or runtime event to one location-qualified exact root. The provenance graph records derivation edges from records and roots to upstream provenance nodes, allowing different exact roots to share a recorded common ancestor. The model sees handles and compact observation types, not the runtime-owned exact-root and derivation mappings used by P3.

Every target-bearing record is mapped before generation; unknown handles fail closed as insufficient. A flattened map makes P3 reproduce P2, confirming that only grouping changes. Exact-root and common-ancestor strata remain separate because only the latter uses the common-ancestor rule. The tool-specific and fused views generate different drafts, so their contrast shows where enough apparent support first appears but does not replace the same-draft policy comparison.

18.5 Worked Promotion Trails↩︎

Authority

The trail separates proposal, authorization, and execution. In the Controlled Holdout, models produce 15/40 unsafe proposals under Data-Only rendering. P1 denies authorization to all 15 and authorizes all 40 matched analyst requests. In W3, the carrier is rendered in all 32 sessions, but the models never propose the target operation; P1 therefore receives no unsafe proposal and makes no attack-case authorization decision. The matched analyst request is proposed, authorized, and executed in all 32 sessions.

Evidence

In fused W1 drafts, records from Ghidra, r2pipe, and angr are cited as support for one false claim. In 16 exact-root cases, P2 validates the claim; P3 groups records sharing the root and downgrades all 16. In 16 cases with distinct roots but one recorded common ancestor, exact-root grouping still validates; the common-ancestor rule follows the recorded derivation edges to their common ancestor, groups the dependent records, and downgrades all 16. P2 and the applicable P3 variant validate all 32 positive-control claims. The renderer emits only post-gate claim objects, and the final report matches the policy decision in all 480 W1 and 384 W2 outputs. Because the replay fixes the draft and citations, it isolates the effect of provenance grouping.

State

P4 stores all 16 items as tainted hypotheses, including the eight downgraded by the upstream claim gate. No retrieval requests an unsupported upgrade without new evidence. With new evidence, 11/16 preserved-metadata and 8/16 flattened-text rows validate.

References↩︎