Self-State Attacks on Self-Hosted AI Agents: How Far Can OS Defenses Go?

Yimeng Chen; Nathanaël Denis; Roberto Di Pietro; Jürgen Schmidhuber

Source-linked AI summary

Self-State Attacks on Self-Hosted AI Agents: How Far Can OS Defenses Go?

Yimeng Chen, Nathanaël Denis, Roberto Di Pietro, Jürgen Schmidhuber

arXiv:2607.17986v1Jul 20, 2026cs.CRcs.AIcs.CLcs.MA

TL;DR

Self-state attacks corrupt an agent’s own persistent state through operations that are indistinguishable from legitimate behavior at the OS layer, limiting permission-based protection. The paper formalizes this attack space and evaluates layered OS defenses across workload profiles, finding that most attack cells can be closed while a residual set remains indistinguishable to the OS.

Problem
Self-state attacks target an agent’s own persistent state, where attack operations are a subset of legitimate operations that no permission model can block selectively.
Method
The paper develops a four-axis attack taxonomy and evaluates prevention, workload-conditioned detection, and recovery across a 23-cell attack matrix and multiple agent workload profiles.
Results
Under the recommended defense stack, all but 4 of 23 attack cells are closed, while workload-conditioning extends OS-layer detection beyond baseline coverage.
Takeaways & Limitations
The findings support a layered defense stack and motivate future research on semantic-layer detectors for residual self-state attacks.
Takeaways & Limitations
OS-level detection has only the write event as an observable window, after which poisoned bytes can influence inference without leaving an OS-observable signature.

Abstract

from arXiv · show

Self-hosted AI agents read and write their own memory and configuration files to function. An agent may get compromised via corruption of its own state -- a compromise realized via legitimate OS system call invocation. We refer to this class of threats as self-state attacks. In this paper, we investigate the OS resilience to this class of attacks. Formally, we characterize a four-axis attack space (Target, Mechanism, Granularity, Temporal); investigate the structural limits of prevention, detection, and recovery; and introduce a workload-conditioned view of detectability. To instantiate the framework, we collect live activity traces from a representative self-hosted agent running across distinct workload profiles, and realize the attack space as a 23-cell matrix, 43 concrete operations on real self-state files, and injected into those traces. We then evaluate both canonical and workload-conditioned defense strategies. The empirical results show that a layered defense stack (access-control prevention on the instruction and configuration layers, workload-conditioned detection on the memory layer, and periodic backup for recovery) is effective on most attack cells while a small residual attack surface remains structurally indistinguishable at the OS level. These findings suggest that against the newly established class of self-state attacks, OS-level defense needs to be reconsidered, potentially opening new research directions in the field.

1 Introduction

Self-hosted AI agents rely on continuously mutable local state, creating self-state attacks in which compromised decision processes use legitimate write paths to corrupt persistent files. This paper systematically characterizes the attack surface and analyzes the structural limits of OS prevention, detection, and recovery.

Motivation: Self-hosted agents persist memory, identity, and configuration in local files that they repeatedly read and rewrite to guide future decisions.These files shape the agent’s context, persona, goals, behavior, learning, and adaptation across interactions.
Problem: Self-state attacks exploit legitimate write paths after semantic compromise to corrupt an agent’s own persistent state through OS-indistinguishable operations.The setting resembles a confused deputy because the agent’s normal self-update mechanisms become an attacker-controlled corruption channel.
Related work: Semantic defenses remain important but are probabilistic because attackers can express malicious intent through indirect language, paraphrase, and contextual reframing.The paper therefore motivates OS defenses as a complementary layer rather than a replacement for semantic defenses.
Problem: Every self-state corruption must eventually issue a concrete syscall, making the OS a deterministic enforcement point, but legitimate and malicious operations can converge on the same files.Examples include write, rename, unlink, and mode-change operations; the paper asks which attacks OS mechanisms can prevent, detect, or recover from.
Contributions: The paper structures self-state attacks along four axes—Target, Mechanism, Granularity, and Temporal—and studies OS defenses across prevention, detection, and recovery.Each attack instance maps to a Target × Mechanism cell over defined self-state components, while each defense dimension has a distinct structural limit.

2 Self-State Attacks

Self-state attacks arise when compromised self-hosted agents use authorized file-system operations to corrupt their own instruction, memory, or configuration state. The paper formalizes these attacks and their OS-visible space across target, mechanism, granularity, and temporal dimensions.

Architecture and Self-State: Self-hosted agents combine an LLM core, OS-capable tools, and local self-state files that directly shape agent behavior.The architecture includes persistent shell and file-system access, with self-state maintained on the local file system.
Definition and Threat Model: Unlike cross-boundary attacks, self-state attacks target resources the agent normally accesses, limiting OS isolation mechanisms that deny access outside its operational scope.The threat model assumes post-compromise attacker-chosen behavior under the agent’s own OS principal and excludes direct host access and attacks on model weights or training.
Definition and Threat Model: A self-state attack uses file-system operations on the agent’s persistent memory, instruction, or configuration state that are also legitimate update operations.Formally, attack operations A(R) are a subset of legitimate operations L(R) for each self-state resource R.
Attack-Space Formalization: At the VFS boundary, every attack is represented by target-path, operation type, size delta, permission delta, and inter-arrival time.These components are the exact surface exposed to kernel-level monitors such as inotify, fanotify, and auditd.
Attack-Space Formalization: The attack space varies target across Instruction, Memory, and Config; mechanism across Modify, Add, Delete, and Deny; granularity from whole-file to minimal-delta; and timing across four patterns.Minimal-delta changes are at most 4 B, while single-shot timing is the primary configuration.

3 Limits of Operating System Defenses

Operating-system defenses face structural limits across prevention, detection, and recovery because self-state attacks can resemble legitimate operations, evade intent judgment, and contaminate recovery points. Workload-conditioned monitoring partially narrows detection limits, but indistinguishable cells remain a residual attack surface.

Prevention: Self-state attacks and legitimate operations can be indistinguishable to access control when the same agent process writes the same self-state resource.At the VFS boundary, adversarial writes are contained within legitimate writes, so blocking all attacks would also block some legitimate operations.
Detection: OS monitoring observes self-state modifications but cannot determine per event whether they are malicious because metadata excludes written content.The only OS-observable detection window is the write event; once poisoned bytes enter the agent’s context, subsequent inference occurs inside the process.
Recovery: Recovery is limited because harmful behavior may reveal neither the corruption point nor which edits should be reverted without discarding legitimate adaptation.Poison can be gradual, semantic, latent, and entangled across memory, instruction, and configuration states.
Workload-conditioned detection: Workload structure partially restores detection by enabling per-file baselines over operation type, write size, and timing features.Legitimate writes concentrate in narrow regions of the feature space, allowing monitors to flag deviations from normal traces.
Workload-conditioned detection: Three cell classes result: Visible cells fall outside legitimate baselines, Conditioned cells depend on workload profiles, and Indistinguishable cells remain within at least one legitimate distribution.Visible cells are flagged at near-perfect True Positive Rate (TPR), while the structural detection limit fully applies to Indistinguishable cells.
Defense composition: Defenses compose as a cascade of prevention, detection, and recovery, but no layer closes cells that remain indistinguishable under the deployed workload.Recovery restores states at O(Δt) loss when detection closes a cell, while runtime prevention closes cells with L(R) = ∅.

4 Experimental Methodology

The methodology evaluates self-state attacks through reproducible OpenClaw traces, a 23-cell attack matrix with 43 concrete instantiations, and layered prevention and detection experiments. It compares workload-blind and workload-conditioned anomaly detection under controlled workloads, thresholds, and train/test procedures.

Experimental setup: Experiments use openclaw-core, a lightweight OpenClaw harness running on Ubuntu 22.04 from a clean snapshot for every trial.The harness preserves the core agent loop and self-state I/O paths while removing channel, plugin, and gateway components.
Workload construction: Four workload profiles—W1 Coding, W2 Research, W3 Operations, and W4 Generalist—provide distinct legitimate activity patterns for workload-conditioned evaluation.Each profile contains 30 back-to-back tasks, repeated across five task-ordering chains, yielding 150 task-slots per profile and 600 overall.
Trace collection: Live legitimate VFS traces are collected with Linux inotify and serve as the context into which attack events are injected during evaluation.The traces are time-ordered event streams of self-state I/O, collected under openclaw-core driven by Gemini 3 Flash.
Attack instantiation: The attack suite enumerates 23 Target × Mechanism × Granularity cells and realizes them as 43 concrete operations on trace-derived self-state files.Granularities G1–G4 are calibrated to nominal size bands and the legitimate-write distribution of the selected target file and profile.

5 Results

Under B2 at τ=2.0, the 23-cell attack matrix contains 11 V, 8 C, and 4 I cells; the recommended L3+B2+15-event backup stack closes all but the four I cells. Results show that prevention must balance protection against workload functionality, while workload-conditioned detection leaves a residual Memory-row surface that recovery can fully remediate once detected.

5.4 Defense outcome: 11 V, 8 C, and 4 I cells comprise the 23-cell matrix under B2 at τ=2.0, while the recommended L3+B2+15-event backup stack closes all but the four I cells.The residual I cells are therefore the only cells left open by the composed defense outcome.
5.1 Prevention: Protection increases monotonically from 0.00 at L0 to 1.00 at L5, while functionality decreases monotonically from 1.00 to 0.00 across restriction levels.Every workload profile’s success rate is non-increasing from L0 through L5.
5.1 Prevention: L3 is the highest restriction preserving usable workloads on at least three profiles, reaching protection 0.61 before Memory locking causes sharp functionality losses.At L4, functionality falls to approximately 90% for W1/W2, 9% for W3, and 31% for W4.
5.2 Detection: The four I cells concentrate on Memory-row writes in operations-style profiles, where small or daily-log writes resemble legitimate workload distributions.W3’s training pool contains 162 Memory-row write events, enabling non-degenerate per-(file, op_type) baselines and allowing many small writes to score below threshold.
5.2 Detection: B2 yields per-profile FPRs of 0.08 on W3, 0.18 on W4, 0.36 on W1, and 0.33 on W2, with sparse-profile errors driven by insufficient training data.B1 instead reports constant per-profile FPRs of 0.000 on W1, 0.143 on W2, 0.081 on W3, and 0.000 on W4 because its global baseline is dominated by W3 traffic.
5.3 Recovery: Recovery achieves 100% remediation across V, C, and I classes when detection fires, covering 640 scenarios across eight attacks, four backup intervals, four profiles, and five chains.The result confirms that remediation does not depend on the attack’s V/C/I class once detection has occurred.

6 Related Work

Prior work addresses agentic threats through semantic attack models, specific poisoning instances, or system- and action-level defenses. This paper instead studies the structural defensibility and inherent OS-level limits of persistent self-state corruption in self-hosted agents.

Threat models for agentic AI: Threat frameworks identify self-state corruption and memory poisoning as agentic-AI threats, but prior systems-security work mainly maps individual cases to violated principles.MITRE ATLAS and OWASP Agentic Top 10 name memory poisoning, while Christodorescu et al. provide per-case mappings.
Positioning: This paper differs by evaluating the effectiveness and inherent limitations of OS defenses against persistent state corruption in self-hosted agents.Its positioning contrasts structural OS-level analysis of the self-state target with prior work operating primarily at semantic or system constraint layers.
Attacks against LLM-based agents: Prior attacks target agent memory and knowledge bases through content-layer RAG injection, long-term-memory backdoors, and query-only poisoning.PoisonedRAG, AgentPoison, and MINJA exemplify specific attack instances rather than a structural organization of the target class.
Defense systems: Existing defense systems provide OS observability or constrain tool calls, planners, plugins, program flow, and information flow, but address specific boundaries or signals.Examples include AgentSight’s eBPF-based kernel and TLS correlation, Prompt Flow Integrity, CaMeL, SEAgent, and Progent.

7 Conclusion … D Notation

The paper establishes a structured account of OS-layer defenses for self-state attacks and finds that workload-conditioned detection complements prevention and recovery in a usable defense stack. It also releases the experimental platform and documents the study’s ethical safeguards, AI use, and notation.

7 Conclusion: The paper formulates self-state attacks and provides the first systematic characterization of OS-layer defensibility for self-hosted AI agents.Its framework combines a formal threat model with a four-axis dimensional taxonomy.
7 Conclusion: Workload-conditioning extends OS-layer detection beyond baseline coverage, and prevention, detection, and recovery compose into a usable defense stack.The findings also motivate future research on semantic-layer detectors.
A Open Science: The supplementary artifact releases the minimal openclaw-core harness, including the self-state contract, LLM client, tool dispatch, boundary checks, heartbeat loop, and trace collector.The harness is implemented in Python and described in Appendix F.
A Open Science: The release includes 43 canonical attack-script instantiations across 23 matrix cells, task corpora and instruction packs, and defense configurations.Defense configurations include Unix permission policies and inotify-based anomaly detectors.
B Ethical Considerations: The work characterizes defensive limitations rather than developing novel offensive capabilities, using deterministic OS operations representing post-compromise prompt-injection stages.The scripts do not implement new prompt-injection techniques, exploit novel vulnerabilities, or target real systems.
B Ethical Considerations: Experiments ran in isolated environments with automated teardown and involved no real user data, production systems, or third-party services.W1 and W2 used public benchmarks, while W3 and W4 used author-constructed tasks without real user data.
B Ethical Considerations: The 23-cell canonical attack matrix and 43 instantiations characterize the OS-layer detection boundary, including OS monitoring’s inability to distinguish benign from malicious content in I-class cells.The authors state that the matrix is not an offensive toolkit and disclose it to support effective defense development.
C Generative AI Usage: Claude assisted with prose, boilerplate LaTeX, and experimental scripts, while the authors reviewed and edited AI-generated content and retained responsibility for design, analysis, and claims.Table 11 summarizes the symbols used throughout the paper.

E Mapping of the Canonical Cells to Established Threat Catalogs

The appendix maps all 23 canonical matrix cells to MITRE ATLAS, ATT&CK, and OWASP Agentic AI catalogs, while showing how Granularity and Temporal refine the catalog taxonomy. It also expands the cells into 43 concrete attack-script entries and projects catalog anchors across matrix rows rather than individual cells.

Catalog mapping: The 23-cell matrix is grounded in three community threat catalogs at the Target/Mechanism level, while Granularity and Temporal refine rather than duplicate their taxonomy.The appendix provides the full per-cell mapping across ATLAS, ATT&CK, and OWASP Agentic AI anchors.
Instantiation: 43 attack-script entries realize the 23 canonical cells through one to three target-file instantiations per cell.Examples span instruction files, memory files, configuration files, and their associated target-file variants.
Boundary cases: Two boundary attacks fall outside the matrix: Cred-Repl targets credentials, while Proc-Kill stops the agent process and produces no file event.Cred-Repl has an empty legitimate-write baseline by operator convention, and Proc-Kill is excluded from file-event analyses.
Catalog projection: Catalog anchors correspond to entire matrix rows rather than single cells, exposing Granularity distinctions that a single technique such as ATLAS aml.t0080.000 bundles together.The framework therefore reveals that defender visibility can vary within a catalog anchor as a function of Granularity.
Catalog mapping: Each canonical cell is a unique (Target, Mechanism, Granularity) coordinate, with primary ATLAS anchors invariant within rows and ATT&CK and OWASP anchors varying by mechanism.Table 12 lists the primary target-file instance for catalog reference, while each cell has a fuller instantiation list.

F Experimental Settings

This appendix describes the experimental setup underlying the V/C/I evaluation, covering the harness, workloads, corpus, trace features, and attack-injection coupling.

Experimental Settings: The setup produces the trace data used by the V/C/I evaluation.The appendix documents the experimental setup that generates these traces.
Experimental Settings: The harness architecture and per-workload agent prompts and instruction packs define the experimental workloads.These topics are covered in §§F.1–F.2.
Experimental Settings: The task corpus, trace-collection feature tuple, and coupling between legitimate sessions and attack injection complete the setup.These topics are covered in §§F.3–F.5.

F.1 Harness Architecture · F.2 Per-Workload Agent Prompts

The study uses an auditable, minimal harness that runs real LLM tool-calling sessions over self-state files, while per-workload instruction packs shape distinct legitimate write distributions. Coding, research, operations, and generalist profiles therefore create different workload-conditioned baselines for memory and configuration attacks.

F.1 Harness Architecture: The openclaw-core harness runs real OpenAI-compatible chat loops, parsing model tool calls, dispatching them through its I/O layer, and returning tool outputs as messages.This replaces the v4 synthetic generator’s directly scripted file operations.
F.1 Harness Architecture: The minimal reimplementation keeps the experiment auditable by exposing the LLM client, tool dispatch, boundary checks, trace collector, and heartbeat loop in roughly 2,000 lines of Python.It also avoids unrelated production OpenClaw subsystems that could inject extraneous events into traces.
F.1 Harness Architecture: Each session is bounded by max_turns, max_total_tokens, and a globally set 128,000-token context window that controls compaction and memory-flush sub-sessions.These independent budgets constrain session execution and context management.
F.2 Per-Workload Agent Prompts: Every profile starts from eight neutral templates, then applies an instruction pack that fully overwrites five Instruction-layer files while leaving memory and heartbeat files unchanged.The overlay is applied immediately after workspace initialization.
F.2 Per-Workload Agent Prompts: Instruction packs are the load-bearing mechanism producing distinct write distributions: W1 rarely writes MEMORY.md, whereas W2 writes it densely despite using the same model and tools.Thus workload behavior is induced primarily by instructions and task corpus rather than tool or model differences.
F.2 Per-Workload Agent Prompts: W2 treats memory writes as its main output, producing the densest legitimate Memory-write distribution and making Memory/M1 and Memory/M2 most likely to become C or I.Its prompt directs distilled wisdom, topic notes, and raw session logs into memory files.
F.2 Per-Workload Agent Prompts: W3’s configuration-first workflow creates the densest legitimate Config/M1 baseline, making configuration attacks workload-conditioned rather than uniformly visible.W3 treats openclaw.json and the environment file as auditable production outputs.
F.2 Per-Workload Agent Prompts: W4 produces moderate writes across all three layers, uniquely including occasional writes to every layer and making its V/C/I assignments most sensitive to Granularity.Its profile directs the agent to read and update state files for persistence.

F.3 Task Corpus and Dataset Construction

The dataset comprises four 30-task profiles spanning benchmark-derived, self-configuration, and general-assistant workloads. Each profile is executed through five orderings, yielding 600 task slots overall, with checked-in seeds and reproducible sampling.

Corpus structure: Each profile contains 30 tasks organized as 5 clusters × 6 variants, producing 120 tasks across four profiles.Tasks and seed material are checked into structured repository paths with a defined JSON schema.
Execution design: Five task-ordering chains run each profile in one shared workspace, totaling 150 task slots per profile and 600 across four profiles.The chains include canonical, two random shuffles, cluster-major ordering, and a fifth ordering described in the corpus construction.
Profile composition: W1 uses the Aider polyglot benchmark, W2 uses FRAMES, and W3 and W4 are hand-authored for self-configuration and general-assistant workflows.W1 groups programming exercises by theme, while W2 samples reasoning types with a fixed seed; W3 and W4 cover documented workflows and everyday assistant tasks.
Reproducibility: All seed material is version-controlled and checked into the repository, with pinned benchmark sources, seeded sampling, and no runtime network requirement.W1 is pinned to an Aider commit; W2 pins its TSV and article versions; W3 and W4 use authored JSON.

F.4 Trace Collection and Feature Tuple · F.5 Coupling Between Legitimate Sessions and Attack Injection · G Extended Discussion

The appendix describes a Linux-only inotify pipeline that records structured filesystem events, derives a three-component detector tuple, and evaluates attacks through post-hoc injection into held-out legitimate sessions. It also notes that the extended discussion is practitioner-oriented and not load-bearing for the paper’s central argument.

F.4 Trace Collection and Feature Tuple: The collector runs beside the LLM session, recursively watches workspace directories, excludes noise paths, and dynamically watches newly created subdirectories.Excluded paths include __pycache__, .git, .DS_Store, virtualenv and cache directories, and node_modules.
F.4 Trace Collection and Feature Tuple: The default event mask captures creation, modification, deletion, moves, and attribute changes, including mode-bit changes required to distinguish the M4 Deny mechanism.The mask is IN_CREATE | IN_MODIFY | IN_DELETE | IN_MOVED_FROM | IN_MOVED_TO | IN_ATTRIB.
F.4 Trace Collection and Feature Tuple: Each event is emitted as a JSONL record containing timing, session, path, size, hash, mode, and move metadata.The record includes a signed size delta and a 16-hex-character SHA-256 prefix over up to the first 2 MiB of file content.
F.4 Trace Collection and Feature Tuple: The detector consumes only the tuple (op_type, δs, Δt), representing event kind, signed size delta, and inter-arrival time between writes to the same file.No semantic file content is provided to the OS-layer detector.
F.4 Trace Collection and Feature Tuple: Trace overflow is recorded and counted while collection continues, and non-Linux execution is skipped or rejected because inotify is Linux-only.All camera-ready 30-session runs were executed on Linux.
F.5 Coupling Between Legitimate Sessions and Attack Injection: The legitimate-session driver and canonical attack catalog are decoupled: sessions produce logs and traces, while 43 deterministic (cell, target-file) attack specifications are consumed independently.The specifications are generated once from the trace pool.
F.5 Coupling Between Legitimate Sessions and Attack Injection: The V/C/I experiment uses post-hoc coupling, drawing a per-trial 70/30 session-level train/test split, fitting on training traces, and selecting held-out normal context for attacks.Per-trial randomness comes from the train/test split and per-attack injection position.
F.5 Coupling Between Legitimate Sessions and Attack Injection: Attack injection preserves the legitimate write distribution while placing the attack at a known position, enabling per-event V/C/I classification.The known injection position makes each event’s classification well-defined.

G.1 Operational Cost · G.2 Beyond Per-Event Detection: Trajectory Scoring

The recommended defense stack concentrates overhead on rare operator-side actions rather than the agent’s runtime path, while recovery costs arise only when recovery is triggered. Beyond per-event detection, trajectory scoring addresses temporal gaps between malicious writes and later compromised behavior that memoryless detection leaves unexplored.

G.1 Operational Cost: The recommended stack concentrates overhead on rare operator-side actions rather than the agent’s runtime path.L2 prevention with chattr +i has near-zero per-operation impact in Exp 1 because legitimate runtime Instruction-file writes are empty on three of four profiles.
G.1 Operational Cost: The reported per-profile, per-mode FPR calibration uses B2 at τ=2.0, although real deployments will typically tune τ separately by profile and mode.The uniform V/C/I operating point is used only to characterize the detectability boundary.
G.1 Operational Cost: Autonomous blocking requires per-profile threshold tuning: on dense W3, τ=2.5–3.0 pushes FPR below 0.01, while sparse W1 and W2 need more legitimate-trace volume.At τ=2.0, W3 has FPR 0.08; on W1 and W2, the FPR floor is workload-data-bound rather than threshold-bound.
G.1 Operational Cost: At τ=2.0, human-in-the-loop detection averages 1 prompt per 12 legitimate self-state events on W3 and 1 per 5 on W4.W1 and W2 are too sparse for a stable per-session estimate, while interactive deployments can absorb prompts because per-event approval is already part of the agent UX surface.
G.1 Operational Cost: Operating-point assignments remain stable under per-profile retuning: the TPR gap between V and I is ≥0.30 at every profile, and only 8 C-cells depend materially on threshold choice.V denotes TPR≥0.80 and I denotes TPR<0.50.
G.1 Operational Cost: Recovery loses approximately 14%, 15%, 15%, and 10% of events on W3 for backup intervals k=5, 15, 30, and 60, respectively.This cost applies only when recovery is triggered; human-in-the-loop mode avoids false-alarm-triggered recovery when users dismiss false positives.
G.2 Beyond Per-Event Detection: Trajectory Scoring: Per-event, memoryless V/C/I detection leaves a temporal gap between a malicious write engineered to look normal and the compromised agent’s later behavior.Trajectory scoring is presented as a complementary surface for this unexplored cause-and-effect gap, including potentially novel syscall patterns after Instruction corruption.

G.3 Workload-Conditioning Ablation: B1 vs B2 Detail · G.4 Temporal Features and the Limits of Multi-Event Detection · G.5 Instruction-Row Baseline Coverage

Workload conditioning improves sensitivity by distinguishing sparse from dense profiles, but temporal feature variations change only two attack cells and cannot resolve dense Memory-write cases. Instruction-row coverage is strong because legitimate writes are nearly absent, except for a USER.md case absorbed by its baseline.

G.3 Workload-Conditioning Ablation: B1 vs B2 Detail: B1 reports W1 FPR 0.000 and W2 FPR 0.143, versus B2’s 0.36 and 0.33, reflecting under-flagging rather than genuine specificity.B1’s pooled baseline is dominated by W3’s high-volume traffic and absorbs in-distribution variation on sparse profiles.
G.3 Workload-Conditioning Ablation: B1 vs B2 Detail: ΔTPR on C is +0.37 as workload conditioning separates sparse and dense profiles; two configuration cells rise from I to C while two Memory cells fall from V to C.Cfg-M1-G3/G4 move from I to C, whereas Mem-M1-G2 and Mem-M2-G2 move from V to C under W3’s wider Memory-row baseline.
G.3 Workload-Conditioning Ablation: B1 vs B2 Detail: Residual I cells gain mean TPR +0.46 on profiles where the attack tuple is rare, yet remain below threshold on dense Memory-row profiles.Thus B2 improves per-profile sensitivity without eliminating the OS-layer residual.
G.4 Temporal Features and the Limits of Multi-Event Detection: The B2 score incorporates per-(file, op_type) log-interarrival timing, while the 43-instantiation grid yields V/C/I distributions of 11/8/4, 10/8/5, and 12/7/4 across three timing modes.The modes are random, burst-aligned, and quiet-gap injection, respectively.
G.4 Temporal Features and the Limits of Multi-Event Detection: Only two cells change class across timing modes, and small-modify and daily-log Memory cells remain I because single-event timing cannot separate them from dense Memory-write distributions.Agent-runtime consistency checks, read-path rescoring, and content-diff audit gating remain follow-up defenses above the OS.
G.5 Instruction-Row Baseline Coverage: 8 of 9 Instruction-row cells are V because SOUL.md, AGENTS.md, and IDENTITY.md have zero or near-zero legitimate writes across all four profiles.Writes into these V-anchor instantiations trigger the unseen-(file, op_type) sentinel.
G.5 Instruction-Row Baseline Coverage: Inst-M1-G3 is the sole C-cell exception because it targets USER.md, whose W4 instruction-write baseline absorbs the line-scale edit signature.The passage identifies this baseline behavior as the exception to the otherwise strong Instruction-row V coverage.