T34 · Helmwart ID · OWASP MAS Guide source

Wallet Key Compromise

An agent's blockchain wallet private keys are stolen, letting the attacker drain funds, impersonate the agent, and submit unauthorised on-chain actions under its identity.

Last reviewed 2026-05-14·Severity heuristic: critical

ExtendsT9: Identity Spoofing and Impersonation · base threat in OWASP v1.1 catalog

L4 · Deployment Infrastructure Agent Identity Management AML.T0055 ↗AML.T0083 ↗AML.T0073 ↗

Definition

The private keys associated with an ElizaOS agent’s (an open-source multi-agent operating system built on Solana) Solana wallet are compromised, enabling fund theft, agent impersonation, and the execution of unauthorised on-chain actions. Key compromise may result from plugin vulnerabilities (T29), service account exposure at the deployment layer (T22), or direct compromise of the host infrastructure.

What it looks like in practice

An attacker exploits the plugin vulnerability described in T29 to exfiltrate the agent’s private key from the key management subsystem. With the key in hand, the attacker signs and submits a series of transfer transactions, draining the agent’s holdings to an attacker-controlled wallet. The agent continues to operate normally from its own perspective (it can still sign transactions using the same key), but every transfer the attacker submits carries the agent’s authoritative on-chain identity. Monitoring systems that check transaction volume or pattern may not alert because the attacker submits transfers at a rate designed to stay within normal operating bounds.

A separate attack path: the private key is stored as an environment variable in the container image. An attacker who gains read access to the container filesystem (via a container escape or a misconfigured image registry) retrieves the key without any interaction with the running agent.

Why it’s dangerous in multi-agent context

An agent’s cryptographic wallet key is its identity on the blockchain. Unlike a human who can freeze a compromised card, an agent cannot autonomously detect that its key has been exfiltrated and revoke its own credentials. The attacker inherits the full scope of the agent’s on-chain authority (every contract interaction, every token transfer) while the agent’s monitoring metrics look normal to systems that measure call volume and response time rather than transaction originator verification. In a hierarchical multi-agent system, downstream agents that trust the compromised agent’s on-chain identity as authoritative are also affected.

Detection signals

The primary detection surface is the blockchain itself: the agent’s key is cryptographically active, so every transaction it signs is publicly recorded, but the origin of that signing is not.

On-chain transfers signed by the agent’s wallet address that originate from a process, IP, or time window outside the agent’s normal operating schedule: correlate blockchain transaction timestamps against the agent process’s activity log.
The agent’s nonce sequence on Solana advancing faster than its own invocation rate can account for (e.g., 10 on-chain transactions in a minute when the agent’s task loop runs at one-per-minute).
Destination addresses in signed transactions that have never previously received funds from the agent: flag any first-time recipient above a defined value threshold.
The private key material appearing in a container image layer, in environment variable dumps from docker inspect, or in CI logs: automated secret scanning on image build artefacts should catch this before deployment.
A gap between the value of assets the agent’s application layer records as transferred and the total outflow visible on-chain for that address within the same time window.

Mitigations

Store private keys in a hardware security module (HSM) or a secrets management service with hardware-backed key protection; never in environment variables or container images.
Never log key material or include it in error messages or stack traces.
Restrict key access to the minimum required process scope; apply OS-level controls to prevent plugin code from reaching the key management subsystem.
Monitor for on-chain transactions signed by the agent’s key that originate outside the agent’s normal operating hours or exceed normal value thresholds; alert and freeze on detection.

Relation to base threat (T1–T17)

T34 extends T9 Identity Spoofing and Impersonation. Where T9 addresses the broad class of agent identity compromise, T34 is the blockchain-wallet-key-theft instantiation: the agent’s on-chain identity is fully taken over via cryptographic key compromise. T36 (Smart Contract Vulnerability Leading to Agent Impersonation) is the complementary path: achieving the same impersonation effect by exploiting a smart contract flaw rather than stealing the key.

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. T34 is covered by the following Top 10 entries:

ASI03Identity & Privilege Abusecontributing
When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.
OWASP LLM Top 10:LLM03:2026 LLM01:2026 LLM02:2026

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 T34 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-DepthOnce the private key is exfiltrated (whether through the plugin vulnerability path or via a container image with the key in an environment variable) the agent cannot detect the theft, and the attacker operates at normal transaction rates specifically to avoid volume-based alerts. No single control closes all three entry paths simultaneously. Depth means hardware-backed key storage in an HSM or secrets manager as the prevention layer, OS-level process restrictions that prevent plugin code from reaching the key management subsystem as an independent barrier, a prohibition on logging key material so that error paths cannot leak it, and on-chain transaction monitoring for activity outside normal hours or above normal value thresholds as the detective layer: each covering an entry or exfiltration path the others do not.
Agent-as-principal IdentityThe wallet private key is the agent's on-chain identity, and because it is a static long-lived credential rather than a short-lived scoped token, its theft grants the attacker the agent's full on-chain authority indefinitely. Every contract interaction and token transfer is available to the attacker while monitoring systems that measure call volume see nothing anomalous. The identity controls that counter this are hardware-backed key storage that prevents the credential from ever existing in a copyable form in process memory, OS-level access restrictions that scope key access to the minimum required process so that plugin code cannot reach the key management subsystem, and on-chain transaction monitoring that alerts when the agent's signing key is used outside expected operating parameters, establishing the detective capability that static key storage alone cannot provide.

Recommended mitigations

Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T34, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).

Tier 1SPIFFE(SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service)
In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.
why it helps Wallet key compromise is adjacent to SPIFFE coverage. A wallet signing key stored as a workload-specific secret fetched via the SPIFFE Workload API is not accessible to other workloads even on the same host, bounding the blast radius of any single workload compromise.
Tier 2Blockchain tx guard(Blockchain transaction guard — pre-commit safety checks for every agent-initiated transaction)
A blockchain transaction, once committed, cannot be undone. An agent that signs and broadcasts a transaction without an enforcement layer before it can exceed its authorised value, call a contract it was never provisioned to reach, or drain a wallet in a runaway loop, and by then the funds are gone. A transaction guard intercepts each proposed transaction before signing, checks it against value bounds, a contract allowlist, a gas or compute-unit limit, and a replay-protection nonce, and refuses to sign anything that falls outside declared policy.
why it helps Wallet Key Compromise allows an attacker to submit arbitrary transactions through the compromised signing key. The transaction guard's per-session value limit and contract allowlist bound the financial exposure until the key is rotated. This is a partial mitigation: it does not prevent the compromise or detect it.

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.T0055Unsecured Credentialsview on ATLAS ↗

Adversary discovers credentials stored in plain configuration files, environment variables, or model context where they should not be exposed.

Agentic angle: Agent configuration files (system prompts, tool descriptors, MCP manifests) are a fresh credential exposure surface.

AML.T0083Credentials from AI Agent Configurationview on ATLAS ↗

Adversary extracts credentials, API keys, or service-account tokens from an agent's configuration files, system prompts, or environment.

AML.T0073Impersonationview on ATLAS ↗

Adversary poses as a trusted entity (user, service, peer agent) to gain access or influence decisions.

References

OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 4 Deployment Infrastructure.

Sources

OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 4 Deployment Infrastructure

Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.