Sign up for updates
The industry calls the agent harness "the operating system for AI agents." As a compliment, that's marketing. Taken at its word, it reads more like an indictment. The harness has picked up an OS's jobs: credential custody, code execution, a configuration store, and a trust model. It has acquired those responsibilities faster than the defenses that make them safe. And in the CVEs examined below, the model is rarely the component that changes in the fix. The patches land in the harness.
We have a name for "load executable configuration from the current directory without checking who put it there." Several, in fact. On Windows it was DLL search-order hijacking and its cousin, sideloading: a program that searched its working directory for a library would happily load an attacker's copy. Windows named it at scale in 2010; the disclosures are in the references. On Unix it was . in your PATH, plus LD_PRELOAD and $ORIGIN rpath abuse, all of them the loader honoring a search path an attacker could write into. The mature fix was always an ownership check before trust: Git shipped safe.directory after CVE-2022-24765, and direnv will not load a directory's .envrc until you direnv allow it against a content hash.
The agent harness is the loader, and right now it is the pre-safe.directory, pre-direnv loader. I lead with it because it is the most familiar thing in the system, not the worst: a mistake the platform layer beneath this one diagnosed and fixed years ago, reappearing one level up with a new file extension.
The harness is an OS now. Not as a compliment
The word harness has settled, over the last year, into a specific meaning: the infrastructure layer around a language model that turns a stateless text generator into an agent that does things. It builds the context window and talks to its remote counterparts when the model is hosted, holds the tools, brokers the file system and the network, keeps the session's state, and decides what the model is and isn't allowed to do. The popular gloss is that the model is the CPU and the harness is the operating system: the model supplies raw processing while the harness manages how that power reaches memory, devices, and the outside world.
A harness is not only a local coding agent. It is the cloud coding agent that runs your repo on a hosted VM. It is the CLI agent wired into CI. It is the enterprise copilot that retrieves your email and documents, like Microsoft 365 Copilot. It is the workflow-automation platform that stores every credential and runs your steps, like n8n. It is the low-code builder that lets anyone wire a model to internal APIs. Different shells, same role. Each one composes untrusted input, holds credentials, runs tools, and decides what is allowed. The claim is not that any of these is literally an operating system. It is that each has become part of the agent system's trusted computing base while carrying an operating system's responsibilities, and that the CVEs land where those responsibilities outran the defenses.
What makes something an operating system is not that programs run on it. It is the boundaries it enforces between those programs and the resources they want. By that definition the harness already occupies an operating system's security role. It owns the syscall-equivalent surface (the tool layer), it custodies credentials, it keeps a configuration store, and it adjudicates trust. The question the metaphor invites and then quietly drops is: if the harness is an OS, how good is its OS security? Subsystem by subsystem, the answer is "roughly Windows XP at first release." Powerful, ambient-authority-by-default, missing the specific countermeasures the previous era spent fifteen years building after it got burned without them.
The aim here is to take the analogy literally enough to be useful: to map each failing onto the specific mechanism that fixed it before, and to look hard at the half of the agent OS that gets the least attention, the configuration store. The claim I want to stake is that the agent config file is on a direct trajectory to become a registry hive, and that the registry's painful security history is the closest thing we have to a roadmap for what comes next.
Where the patches land
Start with the evidence, but make the selection rules explicit.
This is a hand-picked architecture sample, not a census, prevalence estimate, or severity ranking. Scores are the CNA base scores in the official records. Rows are grouped by product, not ranked by score. Each entry is assigned one primary failing subsystem, based on the control the shipped fix changed; prompt injection is noted as a trigger where relevant, not scored as either a model or a harness bug. Severe model-layer failures, a successful jailbreak or an injection that lands, often receive no CVE at all. This table shows recurring harness failure modes. It does not measure how often harness failures occur relative to model failures.
Of these eleven, most cluster in two subsystems, configuration-and-trust resolution and execution-or-sandboxing, with a single case, EchoLeak, in privileged context composition and egress. That distribution describes this selected corpus, not the ecosystem. Where the remediation landed is the stronger signal.
n8n's expression evaluator produced a documented cluster of sibling escapes beyond CVE-2025-68613, including CVE-2026-25049 and CVE-2026-27493, -27495, and -27497, patched across the same release train. They are the least agent-specific findings in the set, classic sandbox escapes in a Node application where the model is frequently not in the loop at all. They belong here because they show the same failing, code and credentials in one namespace, not because the model participates.
The entry vector is often a model-layer property. Indirect prompt injection works because instruction and data arrive on the same token channel, and there is no W^X for a prompt, no boundary the platform can enforce between "content to process" and "command to obey." That part is structural and cannot be patched away at the model. But notice what follows from it. If you cannot reliably stop the injection at the model, the place left to contain the impact is the harness. And every fix in the table is a harness fix: require confirmation for config changes, partition the prompt context, fix the CSP, isolate the sandbox, scope folder trust. Not one of these was resolved by retraining a model. TrustFall's vendors decline to call it a vulnerability at all, on the grounds that the behavior is harness convention rather than model error, which is the same point from the other direction.
So the claim is narrow and, I think, defensible. The model is an untrusted initiator; the harness sets the blast radius. In this sample, the consequential failures land in the orchestration layer: how it handles secrets, how it resolves and trusts configuration, what its tools can reach, and how its output gets out. Two of those deserve a closer look before the architecture.
Credentials tend to live in the environment, alongside the model, exposed by the harness. Secrets arrive as environment variables, inherited by every child process, readable same-user through /proc, prone to leaking into crash dumps and logs. "Keep no secret in the clear" is one of the field's oldest lessons. The original case was a secret file that had to be guarded against both reading and writing, and lost that protection every time it was edited or copied. The principle that fixes it is equally old: the component most exposed to untrusted input must not hold the credential. The n8n cluster is the live demonstration, and the fix has been named twice already, as namespaces in 1992 and as privilege separation in 2003. The agent should be the unprivileged deputy that asks a privileged broker to use a secret, holding an unforgeable scoped handle, never the bytes.
And the user-visible defenses tend to suggest a protection they do not deliver. "Internet off" that does not cover the agent's own retrieval tools. A folder-trust prompt that defaults to yes and does not say it is about to launch a native process. Notice the shape repeating across the whole table: a privileged component handles untrusted input with ambient authority, a control is absent or misplaced, and the user sees a reassurance the architecture hasn't earned. That is not a list of unrelated bugs. It is one missing layer, showing up in a dozen places.
Apps before kernel
The reflex is to read all of that as a list of defects to patch: fix the loader, move the secrets, scope the trust prompt. That reading is wrong.
An operating system earns its security properties from two structures, and the harness has shipped neither. The first is a mediated service interface. The program does not touch the resource, it asks a broker that can say no. The second is a protected configuration store: a database of who-may-change-what, guarded by ownership and integrity rules, kept separate from the data plane.
The harness skipped both and shipped the application surface first: an agent that can already act, holding raw exec and a live network stack, reading and writing the same files it treats as configuration. It built the part that does things before the part that constrains what can be done. Apps before kernel. Every row in that table is a symptom of the same ordering. The secrets are in the environment because there is no broker to hold them. The planted MCP server runs because there is no protected store with an owner. The sandbox escape reaches the credentials because the code and the secrets share one namespace.
The confused-deputy literature has the first structure well in hand: strip the agent's standing authority, issue scoped per-action capability tokens, broker the credentials. The second structure is the one nobody is watching, and it is already further along than people realize.
The harness owns more than the impact surface. Building the context window is the first job on its list, and the composition step, where untrusted bytes get flattened into trusted instructions, is as much a harness responsibility as execution. This piece stays on the impact half deliberately, because it is the half with decades of shipped mechanisms waiting to be ported. Composition has no safe.directory to import, and securing it will not look like porting an OS control.
The configuration store is becoming a registry hive
Look at what the agent config file already holds. Not preferences. It holds hooks (shell commands that fire on events), permission grants, definitions for external tool servers, environment overrides, helper commands the harness will execute to fetch credentials, and custom agent definitions that become system prompts. In Claude Code, the managed-settings environment-variable surface alone runs to over 150 entries, a count taken by enumerating the environment of spawned CLI instances rather than trusting the documentation, which tells you where this is going. It is hierarchical. It merges across tiers (user, project, local, command-line, policy) with precedence rules. Its entries are not passive settings. They are executable triggers and privilege grants.
That is not a config file. It is a registry hive in its larval stage. What made the registry an improvement over the .ini files it replaced was not the hierarchy. It was security on the keys.
Ownership and integrity belong on the entry, not the file. HKLM is admin-writable and HKCU is user-writable, and every key carries a security descriptor. Then Windows Vista added Mandatory Integrity Control, so a low-integrity process cannot write a higher-integrity object regardless of discretionary permissions. The agent config store has tiers but no integrity labels on entries, so whoever can write the file can populate any tier the file represents. "A conventionally low-trust local override file silently supplied a high-trust setting" is exactly the violation MIC was built to make impossible. Config entries need integrity levels and a no-write-up rule, enforced by the harness rather than by convention.
Execution-bearing keys are crown jewels and deserve special treatment. The registry learned that Run, RunOnce, Image File Execution Options, and the services keys are where persistence lives, and an entire defensive practice grew up around them, from Microsoft Research's 2004 paper naming auto-start extensibility points to Sysinternals Autoruns. The agent store's hooks, credential-helper commands, and custom-agent definitions are the auto-start keys of the agent OS, the ones whose values get executed or become instructions. They warrant the same handling: enumerable, attributed to an author, change-audited, and writable only from a higher trust tier than ordinary preferences.
The prediction is straightforward. As agents take on more, this store will accumulate entries the way the registry did. Without ownership, integrity labels, special protection on execution-bearing keys, and a clear view of which tier won and whether it is even enforced, it will reproduce the registry's worst decade on a compressed schedule. The good news is that none of those controls has to be invented. They have to be ported.
What good looks like
The target architecture is not hard to state. Four service boundaries, each with a mature precedent and a shipping implementation.
Mediated execution instead of raw exec: the process asks a broker for what it can no longer do itself, the Capsicum and Casper model. A credential broker instead of secrets in the environment: scoped, short-lived leases in the style of Vault and workload identity, so a leak expires fast and no standing secret sits with the agent. A reference monitor that gates the effect rather than the command string, so a deny rule cannot be defeated by rewording. And a configuration store guarded like a registry hive: per-key ownership, integrity labels, protected execution keys, provenance checked on bind.
The industry is starting down this path. A Windows Insider preview runs registered MCP servers in contained agent sessions under a separate agent account, packaged servers only for now. The credential-broker pattern is being argued in the open. What is missing is the decision to build the kernel before shipping more of the application.
The harness is going to grow up into an operating system. It is going to acquire credential brokers, mediated execution, a policy decision point, and a guarded configuration hive. The only question is whether it builds them deliberately or rediscovers each one through an incident. The model is untrusted by construction, which means the harness has to be the kernel. Right now it is still shipping apps.
That subsystem, when it arrives, gives tool calls what COM gave Windows: typed, permissioned interfaces at a traceable call boundary, instead of environment variables and opaque shell-outs. Windows is already moving; macOS and Linux will follow at their own pace. What none of it solves is the token stream. The OS can attest which harness made a call and with what credentials, never why the model chose to make it. That gap is the next piece.
Sources
- Every CVE in the table links to its CNA or vendor advisory.
- TrustFall: Adversa AI, May 2026.
- n8n credential-store exposure: Pillar Security, 2026.
- DLL sideloading named at scale: ACROS, Rapid7, and Microsoft Security Advisory 2269637, all 2010.
- Secrets in the clear: Morris and Thompson, 1979. Namespaces: Plan 9, 1992. Privilege separation: Provos, Friedl, and Honeyman, 2003.
- Reference monitor and least privilege: Saltzer and Schroeder, 1975. The confused deputy: Hardy, 1988.
This piece is an architecture argument built on public CVEs and the classic operating-systems literature. It deliberately omits product-specific, unreported findings.
