A new arXiv preprint identifies 23 distinct attack categories and 43 specific techniques for tampering with a self-hosted AI agent's internal memory and settings using ordinary operating-system file operations [S1]. The authors constructed a multi-layer defense system that blocks the majority of these threats. However, a narrow class of attacks persists, and from the operating system's vantage point it looks identical to legitimate activity. Whether that leftover gap is negligible or fundamental enough to reshape how we protect AI agents is the open question.

The attack that comes from inside the agent

Self-hosted AI agents, the sort a small company might deploy on its own hardware, must routinely read and modify their own memory and configuration files to operate [S1]. This is by design, not a vulnerability: it is how they retain context between sessions, hold onto instructions, and adapt their behaviour over time.

The difficulty arises because an agent can be subverted by altering its own stored state, and the subversion is carried out through standard OS file operations [S1]. The agent is not exploiting an external vulnerability. It is performing the same reads and writes it performs in normal operation. The operating system has no basis to flag the activity because, by its own rules, the activity is permitted.

The authors label this category of threats "self-state attacks" [S1]. That label is their own terminology, not an established industry term, and the work is a preprint that has not undergone peer review [S1].

A four-axis map of the threat

The researchers organise the attack landscape using four dimensions they call Target, Mechanism, Granularity, and Temporal [S1]. Target refers to which element of the agent's stored state is affected, its instructions, its configuration, or its memory. Mechanism describes the method by which the tampering occurs. Granularity ranges from altering a single byte to replacing an entire file. Temporal concerns timing, whether the attack takes effect immediately or lies dormant until a later moment.

They gathered real-time activity logs from a representative self-hosted agent operating under several different workload scenarios, then constructed a 23-cell matrix populated with 43 specific tampering techniques applied to genuine self-state files and overlaid on those logs [S1]. This involves only a single representative agent, not a broad survey of production deployments, so the empirical generalisability is uncertain.

A related GitHub repository, junwenleong/stateful-agent-security-eval, offers a testing framework for security attacks that persist across sessions in LLM-based agents, including attacks that activate on a delay [P3]. That temporal dimension, the delayed trigger, is where detection becomes especially difficult. An adversary inserts a modification now that activates later, when the workload has shifted and existing detection rules may no longer apply.

What it means

The central result is that operating-system-level protections can block most self-state attacks, but a subset eludes them entirely. The authors implemented a defense architecture with three tiers: permission-based restrictions guarding instruction and configuration files, behaviour-based monitoring keyed to the current workload for memory files, and scheduled backups to enable recovery [S1]. This arrangement neutralised the majority of attack cells.

However, a narrow class of attacks remains impossible to distinguish from legitimate activity at the OS level [S1]. The operating system has no way to separate an authorised state update from a malicious one. Tightening access rules or adding anomaly detection does not resolve this, because the malicious action is observationally identical to a normal one from the OS's perspective.

The authors propose judging whether an operation is suspicious based on the agent's current workload rather than in isolation [S1]. A memory write that is expected during a code-review task may be unexpected during a customer-service task. This contextual approach detects more than static rules alone, but it still cannot detect every case.

This aligns with a wider research trend. Another preprint, "Toward Securing AI Agents Like Operating Systems," contends that as autonomous agents gain broader tool access and tighter integration into user environments, they require security mechanisms analogous to those found in operating systems [P2]. A third, "Agent libOS," puts forward a runtime inspired by library operating systems for long-running, capability-restricted LLM agents that preserve state across multiple model invocations [P4]. The common theme is that AI agents are evolving into persistent software entities with durable state, and existing security frameworks have not kept pace.

What it means for business

A small organisation operating a self-hosted agent on its own infrastructure confronts a risk that conventional OS security tooling was never built to handle. The agent has authorised access to its own files. The OS sanctions the operations. A perimeter firewall offers no protection. A file-integrity monitor may detect a modification, but only if it can tell a hostile change apart from a routine one.

The paper's actionable recommendation is the tiered defense architecture. Restricting permissions on instruction and configuration files constrains what can be altered without explicit approval. Monitoring memory writes against the pattern expected for the current task flags operations that deviate from the norm. Scheduled backups create a fallback if tampering is discovered after the fact.

For a local agency using an agent to manage client intake, the prescription is: apply strict permissions to the agent's instruction and configuration files, watch memory writes for mismatches with the expected task, and maintain backups. The undetectable residual that the paper identifies means these measures are necessary but not complete. The agent's own stored state constitutes a trust boundary, and at present the OS cannot fully enforce it.

The open-source GenericAgent project, with over 13,000 GitHub stars, describes itself as a self-evolving agent that achieves full system control [P5]. Full system control is precisely the capability that makes self-state attacks hazardous. An agent empowered to manage its own system can equally be manipulated into corrupting its own state.

What we don't know yet

The paper is a preprint and has not been peer-reviewed [S1]. The findings and the "self-state attack" framework are provisional and attributed to the authors. No independent verification has appeared yet.

The empirical work relies on a single representative agent with injected traces, not data from production systems [S1]. Whether the 23-cell matrix and 43 operations extend to other agent architectures is unresolved.

The residual attack surface that is undetectable at the OS level is described qualitatively but not measured in the evidence pack. Its practical size, and whether defenses operating above the OS can close it, remains uncertain.

The paper does not name any specific commercial AI agent as vulnerable, and the attacks have not been demonstrated against cloud-hosted or third-party managed agents [S1]. The threat model is confined to self-hosted agents.

The next concrete event to watch is whether this preprint enters peer review and whether independent researchers reproduce the results against other agent frameworks. The GitHub evaluation framework [P3] and the Agent libOS runtime [P4] indicate that the research community is already constructing infrastructure around these problems, but no follow-up study has appeared yet.

If this kind of reporting is useful to you, subscribe to keep reading.

Sources

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.