Definition
The ElizaOS (an open-source multi-agent operating system built on Solana) framework does not provide strong enough isolation between the actions of different agents, or between different actions of the same agent. A vulnerability or side effect in one part of the system propagates to other parts: one agent’s state leaks into another’s execution context, or one action’s resource consumption starves subsequent actions.
What it looks like in practice
An ElizaOS trading agent’s plugin writes wallet key material to a shared mutable global walletCache object during a signing operation. A second agent running on the same Node.js process, executing a concurrent unrelated task, reads from that same object and retrieves the first agent’s key material. Both agents stay within their declared permission boundaries; the framework never enforced the per-agent isolation boundary that would have prevented one agent’s runtime state leaking into another’s.
A resource exhaustion variant: a runaway agent (T32) consuming CPU at maximum rate on the shared process starves other agents of execution time, causing them to miss time-sensitive transaction windows.
Why it’s dangerous in multi-agent context
ElizaOS hosts multiple agents on a shared runtime. Insufficient process or memory isolation means a compromised agent, a runaway agent, or an agent with a logic error can interfere with all its peers simultaneously. Unlike a single-agent system where failures are self-contained, insufficient isolation in a multi-agent OS creates a fault propagation path across the entire agent fleet. Isolation failures are particularly dangerous in combination with T20 (Framework Vulnerability Leading to Code Injection): injected code in one agent’s context gains access to shared memory belonging to all agents on the process.
Detection signals
Isolation failures manifest as cross-agent data leakage (one agent reading another’s private state) or resource contention (one agent starving another). Both leave measurable traces at the OS and framework level.
- An agent reading from a global or cross-agent-scope variable (e.g.
walletCache,sharedContext) that is not declared in its own dependency manifest: instrument variable access at the module level and alert on any first-seen cross-agent scope read. - A wallet signing operation’s key identifier appearing in a second agent’s log output or error trace: alert on any agent process emitting a log entry whose content matches another agent’s registered key identifier pattern.
- A per-agent CPU-usage metric for one agent exceeding its defined quota (e.g. > 80 % of its allocated core for more than 10 consecutive seconds) correlated with a latency spike in peer agents on the same host: requires per-agent accounting via cgroups or container-runtime metrics.
- An inter-agent message containing a field value (e.g. a wallet address or signing key reference) that was never passed through the declared message-passing channel but was only ever present in a peer agent’s in-process state: a cross-agent state-leak indicator caught by auditing message field provenance against the sender’s declared output schema.
- A memory-isolation test during QA detecting a read address in one agent’s process that falls within the virtual address range mapped to another agent’s heap: treat any such finding as a production-class isolation breach requiring immediate framework remediation.
Mitigations
- Run each agent in a separate process or container with no shared mutable memory; use structured message-passing (not shared objects) for all inter-agent communication.
- Prohibit plugins from writing to global or cross-agent-scope variables; enforce this at the framework level with module-scoped sandboxing.
- Enforce per-agent resource quotas (CPU time, memory, network bandwidth) using the host OS or a container runtime; alert when an agent’s resource consumption crosses its quota.
- Conduct regular isolation audits: verify that no agent’s private state is reachable from another agent’s execution context in the shared runtime.
Relation to base threat (T1–T17)
T31 extends T2 Tool Misuse. Where T2 addresses a single agent misusing a tool it is authorised to call, T31 addresses the framework’s failure to prevent one agent from inadvertently accessing another agent’s resources, effectively granting tool-call capability across agent boundaries that were never intended. T21 (Inconsistent Workflow State) is the workflow-layer analogue: shared state corruption arising from race conditions rather than from missing process isolation.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T31 is covered by the following Top 10 entries:
-
ASI08 Cascading Failures contributing A single low-severity fault (a hallucinated value, a corrupted tool output, a poisoned memory entry) propagates across a network of agents that each build on the last agent's output, compounding into system-wide harm that is disproportionate to the original defect. ASI08 is about propagation and amplification, not the fault's origin; the initial trigger may itself be innocuous.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T31 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth Insufficient isolation fails because the framework trusts that agents running on the same process will not reach one another's runtime state: a single architectural assumption that, when wrong, propagates failures across the entire fleet simultaneously. The mitigations operate at four independent layers: process or container separation so that no shared mutable memory exists at all, module-scoped sandboxing that prevents plugins from writing to cross-agent variables, per-agent resource quotas enforced by the host OS or container runtime to contain exhaustion side effects, and regular isolation audits that verify the boundary holds. Defeating any one of these layers still leaves the others standing, unlike the single shared-process assumption that T31 exploits.
- Microsegmentation The failure mode is that the ElizaOS framework hosts multiple agents on a shared runtime without enforcing the per-agent isolation boundary that would prevent one agent's runtime state from leaking into another's execution context. Microsegmentation at the process or container level (with no shared mutable memory and structured message-passing for all inter-agent communication) is precisely the east-west control that eliminates this lateral leak path. Per-agent memory namespaces ensure that a compromised agent, a runaway agent, or one with a logic error operates within a zone whose walls it cannot cross regardless of what the framework-level code assumes.
- Containment (blast radius) When a key material leak like the shared `walletCache` scenario occurs, the blast radius is every agent running on the same process: each inherits the first agent's private key without any of them breaching their declared permission boundaries. Containment controls map directly onto the mitigations: separate processes or containers remove the shared memory surface, per-agent resource quotas prevent a runaway agent's CPU consumption from starving peers, and the prohibition on plugins writing to global variables eliminates the specific mechanism by which one agent's signing operation could deposit sensitive state into a scope reachable by all others.
- Sandboxing & Isolation The vulnerability is that the framework enforces declared permission boundaries on what agents may call, but does not enforce memory isolation between agents sharing a process. A plugin that writes to a global object escapes its declared scope without violating any explicit permission rule. Sandboxing at the module level (enforcing that no plugin can write to cross-agent-scope variables) and running each agent in a separate process with no shared mutable memory are the isolation controls that make the declared permission model match the actual runtime boundary. Without this physical isolation layer, the permission model is a policy on paper rather than an enforced constraint.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T31, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1 gVisor (gVisor sandbox — a user-space kernel that intercepts every syscall a container makes)
When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. gVisor prevents this by inserting a user-space kernel implementation between the container and the host: the container's syscalls go to the Sentry process, not to the host kernel, so the reachable attack surface from inside the container is structurally smaller.
why it helps Insufficient isolation between agent executions allows one agent's code to observe or affect another's through shared kernel state. gVisor assigns each sandboxed workload its own Sentry instance, so kernel-state side-channels between parallel agent executions are structurally blocked rather than policy-controlled.
- Tier 3 Workflow state consistency (Workflow state consistency — distributed-state integrity checks for multi-agent workflows)
When multiple agents read and write shared workflow state concurrently, a network partition, a delayed message, or an adversarially timed race condition can produce divergent views. An agent acting on stale or conflicting state may authorise an action it would reject given correct current state. Hash-chained state snapshots, merge-point conflict detection, and optimistic concurrency control close that window.
why it helps Insufficient isolation between agent actions allows a write in one parallel stage to corrupt shared state visible to an agent in another. Per-stage state scoping confines each stage's writes to its own scope, preventing cross-stage corruption at the consistency layer.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
AML.T0053 AI Agent Tool Invocation view on ATLAS ↗ Adversary causes an agent to invoke a legitimate tool with attacker-controlled parameters, turning a sanctioned capability into an attack vector.
Agentic angle: Maps directly to OWASP T2 Tool Misuse: the agent's tools are operating within their declared scope, but the chosen invocation is unsafe.
AML.T0086 Exfiltration via AI Agent Tool Invocation view on ATLAS ↗ Adversary exfiltrates data by chaining the agent's legitimate tools (e.g. read-only DB query plus an outbound email tool), neither of which is alarming on its own.
Agentic angle: Each step looks routine in audit logs; the *combination* is the attack.
AML.T0110 AI Agent Tool Poisoning view on ATLAS ↗ Adversary achieves persistence by compromising tools integrated into an agent's environment, altering parameters, descriptions, or logic to redirect agent behaviour.
Agentic angle: Poisoned MCP tools are invisible to the agent: every tool call silently executes attacker logic while appearing to return normal results.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 3 Agent Frameworks.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 3 Agent Frameworks