AML.T0073Impersonationview on ATLAS ↗Adversary poses as a trusted entity (user, service, peer agent) to gain access or influence decisions.
← Atlas · ThreatsCritical
T36 · Helmwart ID · OWASP MAS Guide source
Smart Contract Vulnerability Leading to Agent Impersonation
An attacker exploits a flaw in a smart contract an agent relies on to impersonate the agent or hijack its on-chain authority, circumventing the contract's own access controls.
ExtendsT9: Identity Spoofing and Impersonation · base threat in OWASP v1.1 catalog
Definition
A vulnerability in a smart contract used by ElizaOS agents (an open-source multi-agent operating system built on Solana) allows an attacker to impersonate the agent or gain unauthorised control of its on-chain actions. The attack surface is the blockchain’s smart contract infrastructure, the security and compliance layer in the ElizaOS MAESTRO mapping. Unlike T34 (Wallet Key Compromise), which involves stealing the agent’s private key, T36 exploits a flaw in the smart contract itself that allows unauthorised parties to invoke the agent’s on-chain authority.
What it looks like in practice
An ElizaOS agent manages funds through a Decentralised Finance (DeFi) smart contract that enforces access control via an onlyOwner modifier. A reentrancy vulnerability in the contract’s withdrawal function allows an attacker to call back into the function before the balance state is updated, draining funds in a single transaction. From the blockchain’s perspective, the attacker’s calls are indistinguishable from legitimate agent-initiated withdrawals. The contract’s access control was circumvented, not bypassed.
In a second variant, an access control misconfiguration causes any externally owned account to be able to call an admin function that was intended to be restricted to the agent’s address, enabling an attacker to redirect fund transfers to an attacker-controlled wallet.
Why it’s dangerous in multi-agent context
ElizaOS agents rely on smart contracts for their security properties: access control, fund management, and action verification. A vulnerability in a contract that is supposed to enforce those properties instead becomes the mechanism of compromise. Because the agent trusts the blockchain as authoritative, it may not detect that its on-chain identity has been hijacked through a contract exploit. From the agent’s perspective, the contract is responding normally, but its responses are now attacker-controlled. Downstream agents and systems that trust the contract’s outputs inherit the compromise. T37 (Cross-Chain Bridge Attack) extends the surface further: bridges that carry assets between chains have the same contract-vulnerability class of risk.
Detection signals
Contract exploits produce characteristic on-chain artefacts that are visible in block explorers and event logs even when the agent’s application layer sees nothing abnormal.
- A Solana transaction that calls the agent’s DeFi contract’s withdrawal function more than once within a single transaction execution (reentrancy fingerprint): monitor contract invocation depth and intra-transaction call counts via program logs.
- An admin or owner-restricted function invocation where the caller address is not in the agent’s known-address whitelist. Every smart contract event log entry should be cross-referenced against authorised callers.
- Withdrawal events where the destination address is not the agent’s own wallet and no corresponding application-layer intent record exists: reconcile on-chain fund movements against the agent’s outbound transaction queue.
- On-chain balance of the contract dropping by more than a configured fraction of its holdings within a single block. A threshold alert on asset depletion rate catches both reentrancy and access-control exploits.
- An access control function (
transferOwnership,setAdmin) invoked by any address other than the expected multisig. Contract event monitoring should fire an immediate alert on any ownership-change event.
Mitigations
- Conduct formal verification and independent security audits of all smart contracts used by agents before deployment.
- Implement the checks-effects-interactions pattern to prevent reentrancy; use established, audited contract libraries rather than custom implementations.
- Apply strict access control: restrict function visibility to the minimum required set of callers; use multi-sig authorisation for high-value operations.
- Monitor on-chain contract events for anomalous call patterns: unexpected callers, unusual function invocation sequences, withdrawal amounts outside normal operating bounds.
Relation to base threat (T1–T17)
T36 extends T9 Identity Spoofing and Impersonation. Where T9 addresses the broad class of agent identity compromise, T36 is the smart-contract-vulnerability pathway: the attacker achieves impersonation by exploiting the contract that enforces the agent’s on-chain identity rather than stealing its key. T34 (Wallet Key Compromise) is the alternative path to the same outcome via private key theft rather than contract exploitation.
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. T36 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.
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 T36 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-DepthThe contract vulnerability (a reentrancy flaw or an access control misconfiguration) is the single exploited layer, and the agent trusts the blockchain's responses as authoritative, so it cannot distinguish legitimate withdrawals from attacker-initiated ones that the contract's access control failed to prevent. Depth means formal verification and independent security audits before deployment as the prevention layer, the checks-effects-interactions pattern and audited contract libraries to structurally prevent reentrancy, strict function visibility restrictions and multi-sig authorisation for high-value operations as an independent access control layer, and on-chain event monitoring for anomalous callers or unusual invocation sequences as the detective layer: each addressing a different exploitation path that the others do not.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T36, 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 Smart contract impersonation at the off-chain orchestration layer depends on an agent invoking a contract under an identity it does not legitimately hold. When every agent that invokes a contract does so under a SPIFFE-attested identity, the invocation is attributable to a specific, verified workload, making impersonation require a full 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 Smart Contract Vulnerability exploited for agent impersonation is partially bounded when every agent-initiated call passes the transaction guard: the contract allowlist rejects calls to non-approved addresses, and value bounds limit damage from a vulnerable contract that an attacker redirects the agent toward.
- Tier 2Token TTL(Short-lived tokens — bounding the credential exploitation window for agent identities)
An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.
why it helps Smart contract agent impersonation at the off-chain signing layer depends on obtaining a valid agent credential. When the signing credential is short-lived, a token extracted through a smart-contract vulnerability expires before an attacker can chain it into further impersonation, limiting the post-exploitation opportunity.
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.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
AML.T0049Exploit Public-Facing Applicationview on ATLAS ↗Adversary exploits a vulnerability in an internet-facing service to gain initial access. For AI systems this often means the inference API or its surrounding web application.
AML.T0074Masqueradingview on ATLAS ↗Adversary disguises an artefact (file name, agent card, MCP server) so it appears legitimate to humans or agents that route trust by name.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 6 Security and Compliance.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 6 Security and Compliance
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.