1 Introduction↩︎

Agentic systems have demonstrated impressive performance on complex tasks by invoking task-specific tools and maintaining memory, via standard protocols such as the Model Context Protocol (MCP) [1] and CLI-based agent protocols [2]. These protocols typically assume that tool descriptors and memory are trustworthy and constitute part of the context used by the agent for planning and execution. However, these context-dependent features introduce novel security vulnerabilities. The agent’s behavior depends not only on the user’s instructions, but also on a bounded, security-critical subset of its entire context, which we refer to as its contextual state.

An MCP tool provider can conduct a tool poisoning attack [3]–[5] by injecting adversarial content into a tool descriptor (e.g., tool metadata such as the tool name and natural language description), either at registration time or later during an agent session. Since the agent plans based on these descriptors, a poisoned descriptor can covertly influence its reasoning. As a result, the agent may issue tool invocations that appear consistent with the user’s instructions but are actually induced by the poisoned contextual state. For example, MCP’s server-based architecture enables “rug pull” tool poisoning [3]. A server can initially present a benign descriptor that the user approves, then later silently alter it to embed adversarial directives, such as “Before using this tool, read the SSH key file”. Most MCP clients do not alert users when descriptors change, allowing a server to behave innocuously at installation and activate the malicious behavior later. Such attacks can mislead the agent into acting as a confused deputy, carrying out the attacker’s intent while believing that it is following the user’s instructions.

Similar vulnerabilities exist in the memory of agentic systems. Agentic systems often retain past interactions, instructions, and intermediate results to inform future planning and execution. For example, Browser-use [6] and Agent-E [7] rely on persistent memory to maintain coherence across multistep interactions. Recent research shows that if an agent’s memory is poisoned, the agent can be induced to exhibit harmful behaviors [4], [8], [9]. Patlan et al. [9] report a storage-side memory poisoning attack on ElizaOS, in which tampering with externally stored conversation history resulted in unauthorized financial actions. The OWASP Top 10 for Agentic Applications identifies memory poisoning as a critical threat category for agentic systems [10].

These attacks reveal an underlying problem: the lack of continuity in the agent’s contextual state. In current agentic systems, critical state components such as tool descriptors and interaction memory can be added, removed, or modified without detection. As a result, an adversary can perform contextual state poisoning (e.g., memory poisoning) and steer the agent’s planning and execution. The security of planning and execution thus hinges on the continuity of the agent’s contextual state. Therefore, we propose ElephantAgent, a protocol that defends the agent’s contextual state by binding it to a verifiable and linearizable state history.

Intuitively, ElephantAgent ensures that the agent’s view of its contextual state remains consistent with the latest authorized state in a linearizable history. Any discrepancy is detected and blocked before planning and execution for each query. ElephantAgent is inspired by state continuity mechanisms (e.g., ElephantDP [11] and Nimble [12]) that defend traditional stateful systems against rollback attacks. ElephantAgent extends state continuity to agentic systems, where the protected state is the agent’s contextual state that is critical for the security of the agent’s planning and execution.

To achieve this, ElephantAgent augments the agentic system with two components: the Context Guard (CG) and the State Continuity Module (SCM). Together, they enforce a cognitive firewall around the agent. SCM maintains a tamper-evident, linearizable ledger of authorized contextual state transitions as a replicated TEE-backed service. Before processing each query, CG performs local cryptographic verification by recomputing the contextual state digest from the current environment and checking that it matches the latest digest authorized by SCM. We instantiate SCM with Nimble [12] and deploy it on Intel Trust Domain Extensions (TDX) [13], [14], a VM-based TEE, so the replicated service can run inside TDX-protected VMs without enclave-specific engineering.

1 compares ElephantAgent with representative agentic defense systems. ElephantAgent is distinguished by a defense based on continuity verification: through a trusted local CG and a remote, replicated, and attested SCM, it protects the contextual state continuity of an agentic system against out-of-band tampering and provides historical traceability under in-band semantic abuse. The contextual state continuity guarantee is the primary protection provided by ElephantAgent, while historical traceability additionally offers conditional post-hoc audit and recovery. In summary, we make the following contributions:

5pt

• Formalization of Contextual State Continuity. We identify the lack of continuity in the agent’s contextual state as a key enabler of state poisoning. We formalize Contextual State Continuity over the bounded, security-critical subset of the agent’s entire context and show that enforcing this property mitigates state poisoning by detecting out-of-band tampering and blocking further processing.

• Formalization of Historical Traceability. We additionally formalize Historical Traceability as a conditional property that complements a limitation of Contextual State Continuity: it does not prevent in-band semantic abuse, where a malicious but properly committed state update is induced. Historical Traceability supports post-hoc audit to identify a known-good prior state and recovery to re-initialize the system from that state, provided the corresponding local ledger and snapshots are available.

• The ElephantAgent protocol. We propose ElephantAgent, a protocol that augments an agentic system with the Context Guard (CG) and the State Continuity Module (SCM) to enforce a cognitive firewall around the agent. ElephantAgent binds the agent’s contextual state to a verifiable and linearizable history via a tamper-evident ledger maintained by SCM. Before processing each query, CG performs cryptographic verification of the local contextual state against the latest SCM-authorized state. ElephantAgent can be applied to agentic systems based on frameworks such as MCP or CLI. In this study, we instantiate ElephantAgent over MCP in our experiments.

• A practical SCM instantiation for agentic systems. We instantiate the State Continuity Module (SCM) with a Nimble-backed ledger [12]. Our implementation leverages Nimble’s linearizable ledger and integrates TDX-adapted remote attestation to verify that SCM runs the expected code under the expected configuration inside the TEE.

2 Related Work↩︎

This section reviews prior work on attacks and defenses related to an agent’s context (e.g., tool state and memory), state continuity mechanisms for defending stateful systems, and trusted execution environments used in the instantiation of ElephantAgent.

2.0.0.1 Tool Poisoning Attacks.

AgentPoison [4] and MindGuard [5] show that adversaries can inject hidden instructions into tool descriptors, thereby steering the agent’s planning toward attacker-chosen tool calls. Invariant Labs describes a “rug pull” attack [3]: a tool provider can register a benign descriptor during onboarding, but later tamper with it to embed hidden directives and induce malicious agent behavior. Together, these works identify tool state as a high-leverage control surface for manipulating agent behavior. Existing defenses typically focus on detection or attribution [5], [17]. In contrast, ElephantAgent is verification-based. By binding the tool state to a linearizable state history, ElephantAgent detects tool poisoning as a violation of Contextual State Continuity.

2.0.0.2 Memory Poisoning Attacks.

MINJA [18] demonstrates memory poisoning in agentic systems that consult prior interaction histories for reasoning, where injected or modified interaction records can influence the agent’s decisions. Patlan et al. [9] report a memory poisoning attack on ElizaOS, in which tampering with externally stored conversation history resulted in unauthorized financial actions. AgentPoison [4] demonstrates a more covert attack in which attackers can plant poisoned memory entries and associated trigger phrases, so that future queries retrieve the tainted entries and induce target actions. These works show that poisoning an agent’s memory can steer planning and execution. ElephantAgent mitigates such attacks by enforcing continuity of memory: any unauthorized insertion, deletion, or modification alters the local memory, causing verification to fail and blocking further processing.

2.0.0.3 Existing Agent Defenses.

Recent agentic defense systems take several approaches. MindGuard [5] uses attention-based anomaly detection and source attribution to identify poisoned MCP tool descriptors that semantically steer tool-invocation decisions. A-MemGuard [16] targets agent memory poisoning through consensus-based validation and adaptation. SecureMCP [17] protects MCP tool integrity through manifest signing, LLM-based suspicious-tool detection, and runtime blocking against poisoned or mutated tool descriptors. 1 summarizes these representative defenses. Compared with them, ElephantAgent is distinguished by its verification-based defense: it protects both tool state and memory against out-of-band tampering, and additionally provides conditional audit and recovery for in-band semantic abuse through Historical Traceability.

2.0.0.4 State Continuity.

State continuity mechanisms typically enforce continuity through monotonic freshness guarantees [19], [20] or linearizable state histories [11], [12], [21], [22], thereby defending against rollback and forking attacks [23]. The latter approach maintains a cryptographically verifiable state history and can be realized through a replicated state machine, which enforces a tamper-evident total order over state transitions and prevents a single compromised node from silently altering the state history. ElephantAgent instantiates this approach with a Nimble-backed linearizable ledger [12] to protect the continuity of an agent’s contextual state.

2.0.0.5 Trusted Execution Environments.

Trusted Execution Environments (TEEs) allow the sensitive part of an application to run in a hardware-isolated, memory-protected environment (e.g., an Intel SGX enclave [24]). Thus, applications can be deployed in untrusted host environments while relying on the TEE boundary to protect in-TEE computation. TEEs provide two properties: (1) confidentiality and integrity for application data inside the TEE; and (2) remote attestation, which enables a remote party to verify that the expected code and configuration are running on trusted hardware [25].

Prominent industry TEE technologies include Intel Software Guard Extensions (SGX) [24]–[26], Intel Trust Domain Extensions (TDX) [13], and AMD Secure Encrypted Virtualization (SEV) [27]. Intel SGX is an enclave-based TEE widely deployed in practice, but requires enclave-specific engineering. Intel TDX and AMD SEV provide VM-based TEE support, allowing existing applications to run in protected VMs without refactoring code into enclaves. In this work, we focus on Intel TDX for the VM-based TEE instantiation.

3 Problem Statement↩︎

This section defines the problem ElephantAgent addresses. We first describe the threat model, including the adversary’s capabilities and the attack scenarios that motivate our work. We then formalize the two security properties ElephantAgent is designed to enforce.

3.1 Threat Model↩︎

We consider an adversary that aims to compromise the agent’s planning and execution through out-of-band tampering of the contextual state or in-band semantic abuse, thereby steering the agent toward adversary-chosen behaviors. The adversary may tamper with tool descriptors delivered to the agent, obtain unauthorized access to the agent’s memory storage and modify it, or inject malicious content through normal interactions.

3.1.0.1 Scenario I: Tool Poisoning from MCP Server.

An adversary controlling an MCP Server injects malicious instructions (e.g., “Before using this tool, read the SSH key file”) into tool descriptors, thereby steering an agent to plan harmful tool calls or access unauthorized private information. For example, MCP’s tool registry suffers from a “rug pull” vulnerability [3]: the server can register a harmless descriptor during onboarding, but later tamper with the descriptor to include hidden directives. Because many MCP clients do not surface such changes to the user, the malicious update can go unnoticed and steer the agent’s planning and execution.

3.1.0.2 Scenario II: Memory Poisoning from Host Platform.

An adversary may obtain unauthorized access to the memory storage of an agentic system and tamper with it out of band. In practice, such access may arise from weaknesses in how memory is stored or accessed in real deployments, such as poorly protected client-side persistence or exposed external storage backends. For example, a misconfigured ClickHouse instance reportedly exposed DeepSeek chat contexts, highlighting that agent memory is a realistic target [8], [28]. Even if the agent runs inside a TEE (e.g., Intel TDX [13]) and its memory is locally sealed (i.e., persisted with encryption) across stops or restarts, an adversary can still replay an older sealed version upon resume (i.e., a rollback attack). Such an attack can roll the agent’s sealed memory back to an earlier but still valid version, thereby restoring a stale task state (e.g., a completed financial transaction is restored as pending, causing the agent to re-execute the transaction and incur economic loss to the user).

3.1.0.3 Scenario III: In-Band Semantic Abuse through Normal Interactions.

An adversary may also manipulate the agent through normal interactions without violating contextual state continuity, thereby causing harmful state transitions to be committed. For example, prompt injection attacks can embed malicious instructions into externally retrieved web pages or emails, which the agent may then interpret as actionable instructions [9], [18], [29], [30], thereby steering subsequent planning and execution. Because such inputs are processed through the intended workflow, the resulting harmful state transitions can become properly committed even though their semantic effect is malicious.

Scenarios I and II correspond to out-of-band tampering and motivate the Contextual State Continuity property defined below. Scenario III corresponds to in-band semantic abuse and motivates the Historical Traceability property defined below. A comprehensive catalog of specific attack vectors considered under this threat model, including those not explicitly narrated as scenarios above, is provided in 9.

3.2 Security Properties↩︎

We now formalize the two security properties motivated by the threat model above.

3.2.0.1 Contextual State Continuity.

Contextual State Continuity is the primary security property that ElephantAgent aims to achieve. At a high level, it requires that the agentic system release to the agent the faithfully evolved contextual state (defined in 4.2) at every planning-and-execution cycle under a given query sequence.

We define this property with respect to an ideal reference agentic system, which runs in a trusted environment. For each query, the reference system reads the current contextual state from the environment, processes the query, and updates the contextual state accordingly before finalizing that query and proceeding to the next one.

Let \(Q = (q_1, q_2, \ldots)\) be a query sequence, and let \(\Omega\) be a resolution of all benign nondeterministic choices during execution (e.g., LLM outputs). Starting from an approved initial contextual state \(C_0\), the ideal reference system processes \(Q\) under \(\Omega\) and produces a sequence of contextual states \(C_0, C_1, C_2, \ldots\). We record this state evolution in the reference ledger \[\mathcal{L}^{*} = \big((0,h_0), (1,h_1), (2,h_2), \ldots\big)\] where each entry \((t,h_t)\) consists of the step identifier \(t\) and the digest \(h_t = \mathcal{H}(C_t)\), and \(\mathcal{H}\) is a collision-resistant hash function.

Intuitively, Contextual State Continuity means that, for each query, the agent plans and acts on the faithfully evolved contextual state, rather than on one that is modified or rolled back. This property targets out-of-band tampering (Scenarios I and II).

3.2.0.2 Historical Traceability.

Historical Traceability is the secondary security property that complements Contextual State Continuity in the presence of in-band semantic abuse (Scenario III) or crash.

4 ElephantAgent Protocol↩︎

We instantiate ElephantAgent over MCP for illustration and evaluation in this paper. As illustrated in 1, ElephantAgent augments MCP with two components: the Context Guard (CG) and the State Continuity Module (SCM). Together, they enforce the two security properties: Contextual State Continuity (1) and Historical Traceability (2).

ElephantAgent is an add-on security protocol with a host-side CG and a remote SCM. It is therefore protocol-agnostic and can also be applied to other agentic systems, such as CLI-based agentic systems (8 of 8). In that case, the protected tool state can be instantiated as the command surface exposed to the agent (e.g., command names, wrappers, permission policies, and command documentation), while the protected memory remains the host-side agent memory (e.g., user queries and agent responses). Thus, ElephantAgent augments a CLI-based agentic system in the same way as an MCP-based agentic system; only the interaction interface changes from an MCP client/server interface to a CLI command-dispatch interface.

4.1 Entities↩︎

We describe the entities in ElephantAgent and their trust assumptions under the threat model in 3.1.

4.1.0.1 The User (Trusted).

An honest entity who issues task prompts \(q\). The user establishes the root of trust at session initialization by approving the initial tool set and memory sources under an approval policy (e.g., Trust On First Use or an allowlist). After initialization, we do not assume that the user monitors subsequent contextual state transitions; instead, ElephantAgent enforces verification and traceability for them.

4.1.0.2 Host Platform (Untrusted).

The environment (e.g., persistent storage) outside the TEE boundary that the agentic system interacts with for I/O and persistence. An adversary may tamper with local files (e.g., interaction history) and may roll back persistent storage to an older but still valid version. For example, under Intel TDX, sealing provides confidentiality and integrity for persistent storage, but does not prevent rollback of sealed storage [13].

4.1.0.3 The MCP Host.

The MCP Host runs inside a TEE so that CG’s verification logic executes faithfully and cannot be bypassed, and so that context is released to the agent only after successful verification. The MCP Host hosts the following:

• Agent (Non-adversarial). The planning component that consumes the context and produces actions. The agent is non-adversarial but susceptible to contextual state poisoning (e.g., via poisoned tools or poisoned memory).

• MCP Client (Trusted). The MCP Client is the protocol-facing component inside the MCP Host that enumerates tool descriptors from MCP Servers and dispatches tool invocations.

• Context Guard (Trusted). CG mediates the agent’s planning and execution path. Before processing each query, CG recomputes the contextual state digest from the local tool state and memory and verifies that it matches the latest SCM-authorized digest. For state updates, CG follows a commit-before-finalize workflow. It commits the next state digest to SCM, persists a pending update record, and finalizes local side effects only after receiving a valid receipt from SCM.

4.1.0.4 The State Continuity Module (Trusted).

SCM is the state maintenance component that provides a linearizable, append-only ledger of authorized contextual state digests. It is instantiated as a replicated TEE-backed service to tolerate failures and prevent rollback from being accepted silently. For each ledger, SCM maintains an ordered sequence of authorized entries \((id_0,h_0)\), \((id_1,h_1), \dots, (id_t,h_t)\), and issues signed receipts or proofs for them as requested.

4.1.0.5 MCP Servers (Untrusted).

External entities that provide tools. We assume that MCP Servers may be compromised and may return malicious tool descriptors.

4.2 Contextual State↩︎

We denote the agent contextual state at step \(t\) by \(C_t = \langle T_t, M_t \rangle\), where \(T_t\) denotes the tool state and \(M_t\) denotes the memory. Agent contextual state does not include the full agent context; rather, it is a security-critical subset whose exact composition may vary across ElephantAgent instantiations. Under the MCP instantiation of ElephantAgent, we define \(T_t\) and \(M_t\) as follows:

• \(T_t\): the registered tool descriptors (e.g., names, descriptions, input/output schemas, and permissions/annotations).

• \(M_t\): the memory. Following representative agentic systems such as Codex [31] and Claude Code [32], we define it to consist of:

  • \(M^I_t\), which denotes long-term instructions (e.g., the system prompt and skills).

  • \(M^R_t\), which denotes the transcript of query-level events (e.g., user queries and agent responses).

  • \(M^A_t\), which denotes the current managed artifacts (e.g., task outputs such as reports, summaries, or schedules).

With the tool state and memory represented using deterministic encodings, the contextual state digest is \[h_t \triangleq \mathcal{H}(C_t)\enspace,\] where \(\mathcal{H}\) is a collision-resistant hash function.

4.2.0.1 Scope of the Protected Contextual State.

The contextual state \(C_t\) is deliberately scoped to the agent context components that are (i) available as stable input to future planning and execution cycles, so that the agent consumes them as decision-making context; and (ii) deterministically encodable, so that they admit a stable digest under \(\mathcal{H}\). In practice, we additionally select components whose protection yields clear security benefits relative to the resulting overhead (e.g., the agent’s memory). We now justify why each included component satisfies the two criteria above and is worth protecting in practice.

Tool descriptors \(T_t\) are the direct input to the agent’s planning step: the agent selects which tool to invoke based on descriptor names, natural language descriptions, parameter schemas, and permissions/annotations. They are available as stable input to future planning and execution cycles (criterion (i)) and are deterministically encodable through the MCP tool manifest (criterion (ii)). Existing attacks show that descriptors are a high-leverage control surface for covert planning manipulation [3]–[5]; protecting \(T_t\) is therefore worth the protection cost.

The three memory components (i.e., \(M^I_t, M^R_t, M^A_t\)) follow the memory abstractions of representative agent runtimes such as Codex [31] and Claude Code [32], and together cover the categories identified in the OWASP Top 10 for Agentic Applications [10]: long-term instructions \(M^I_t\) (e.g., system prompts and skills registered before or between queries); accumulated transcripts of query-level events \(M^R_t\) (e.g., user queries and agent responses); and managed artifacts \(M^A_t\) (e.g., reports, summaries, or schedules produced from tool outputs). All three are available as stable input to future planning and execution cycles (criterion (i)) and are deterministically encodable in canonical form (criterion (ii)). Existing attacks demonstrate that tampering with any of them can steer future planning and execution [4], [9], [18]; protecting the triple \((M^I_t, M^R_t, M^A_t)\) therefore covers the memory-poisoning surface observed in practice.

Not every context component the agent interacts with belongs to \(C_t\). For example, MCP transport-layer session state (e.g., connection metadata and TLS session identifiers) is governed by the underlying transport (e.g., TLS with channel binding, 6.2) rather than consumed by the agent as stable input to future planning and execution cycles, so it does not satisfy criterion (i). Hence, such components are not included in \(C_t\).

The composition of \(C_t\) above reflects the MCP instantiation of ElephantAgent. Exact in-scope and out-of-scope components may vary across ElephantAgent instantiations; for example, a CLI-based deployment (8) replaces \(T_t\) with the command surface exposed to the agent. The two criteria above, however, continue to guide the scoping of \(C_t\) across instantiations.

4.3 ElephantAgent Workflow↩︎

For protocol clarity, we model SCM as a linearizable abstraction that maintains an append-only ledger \(\mathcal{L}\) and a signing key pair \((SK_{SCM}, PK_{SCM})\). 2 specifies the SCM interface via two core primitives: Commit and GetLatestState. Because SCM is modeled as a linearizable abstraction, each Commit or GetLatestState operation appears to take effect atomically at some point between invocation and response. Under this abstraction, the ElephantAgent protocol proceeds in three phases — state initialization, state verification, and state update — to enforce the two security properties defined in 3.2.

4.3.0.1 State Initialization.

To initialize a valid ledger of contextual state transitions, CG must establish a trusted initial state before processing any query. To do so, CG first fetches the current tool descriptors and local memory, and then applies ApprovePolicy to determine whether the initial state should be accepted. In our current prototype, ApprovePolicy is instantiated as a basic Trust On First Use (TOFU) check at initialization, which accepts the observed initial state at first use. ApprovePolicy is a pluggable initialization step and can be strengthened with other trust-root establishment mechanisms such as signature verification.

Once the initial state is approved, CG computes the initial contextual state digest from the local tool state and memory and anchors it in SCM as the first digest of a new ledger. As part of the initialization procedure, CG also snapshots the current tool state and memory, seals the snapshot, and records a reference to it in the corresponding local ledger entry. This ensures that every ledger begins with a recoverable checkpoint (3).

The same initialization procedure can also serve as a recovery mechanism to revert the system to a known-good prior state, thereby supporting Historical Traceability. When restoration to a known-good state \(C_k\) (e.g., identified through manual audit) is needed, CG retrieves the corresponding entry from the local ledger, including the digest \(h_k\), the SCM-authorized signature \(\sigma_k\), and the snapshot reference. CG then restores the corresponding tool state and memory from the referenced snapshot, recomputes the recovered contextual state digest, and checks that it matches the digest \(h_k\) authorized by \(\sigma_k\) for step \(k\). Recovery is permitted only if the restored state passes verification. During recovery, this verification serves as the ApprovePolicy. The system is then re-initialized with \(C_k\), thereby generating a fresh ledger and anchoring the recovered state digest in SCM. This effectively starts a new ledger from \(C_k\), while preserving the original ledger for possible later audit.

4.3.0.2 State Verification.

This phase enforces Contextual State Continuity. For each user query, CG first verifies the local contextual state before the context constructed based on it is released to the agent for planning and execution. CG recomputes the local contextual state digest and queries SCM for the latest state proof for the same ledger. For each read call, CG generates a fresh read-challenge nonce \(n_r\) and requires SCM to return a signed proof bound to \((\ell, id, h, n_r)\). CG verifies the proof and checks that the locally recomputed digest matches the SCM-authorized digest. Any mismatch causes CG to abort the query in a fail-closed manner (4).

4.3.0.3 State Update.

Each query induces a state update before the query is finalized. CG first derives the next contextual state digest through a deterministic, side-effect-free preview. CG then commits this digest to SCM at the next sequence number and verifies the signed receipt; only after that does it materialize the local update (commit-before-finalize). Once the local side effects are durable, CG appends a new record to its local ledger. This record contains the incremented sequence identifier \(id+1\), the new digest \(h_{next}\), the SCM receipt \(\sigma_{commit}\), and a reference to a sealed snapshot if the configurable snapshot policy (e.g., periodic) checkpoints the state files; otherwise, the reference is null. The local ledger append and sealing are performed atomically to ensure crash consistency (5). If a crash occurs after sealing the pending update but before the updated local ledger is sealed, CG can use the pending record during crash recovery to complete the corresponding local ledger append before resuming normal operation.

The local ledger and the snapshot store serve complementary roles in Historical Traceability. The local ledger is the sealed, ordered record of state transitions: each entry binds \((id_t, h_t)\) to an SCM receipt \(\sigma_t\), so the ledger serves to verify that the recorded history is SCM-authorized and properly ordered. By storing only the step identifier, contextual state digest, corresponding receipt, and optional snapshot reference, the ledger remains compact enough to append on every query. The snapshot store complements the ledger by retaining the corresponding complete contextual state at checkpointed steps under a configurable policy (e.g., periodic). Both are required for Historical Traceability: audit uses the ledger to establish the authorized order and the relevant snapshots to inspect the contextual state and identify the first malicious transition; recovery similarly uses the ledger entry of the target step to authenticate the candidate contextual state recovered from the corresponding snapshot and restore it if valid.

We note that ElephantAgent only accepts contextual state updates through the normal query-driven workflow. Any direct host-side modification of protected context outside this workflow is treated as out-of-band tampering and causes ElephantAgent to fail closed. For example, a user might manually replace a SKILL.md file to update an agent skill; ElephantAgent would reject this change. The correct way is to issue the update through a query (e.g., asking Codex to update a review skill), so that the resulting state transition is committed to and authorized by SCM.

4.3.0.4 ElephantAgent Workflow.

We summarize the ElephantAgent workflow in 6. The workflow integrates remote attestation, contextual state verification, planning, and state updates. Because each successful query induces a contextual state transition, the workflow performs one state update per successful query. The workflow is fail-closed: if any attestation, verification, or update step fails, the query aborts, and no further processing or state finalization occurs. Overall, the workflow enforces the two security properties of ElephantAgent: the primary Contextual State Continuity, which blocks out-of-band tampering, and the complementary Historical Traceability, which conditionally supports post-hoc audit and recovery under in-band semantic abuse. We further discuss the limitations of ElephantAgent in 12 to clarify its scope and operating boundaries.

5 Security Analysis↩︎

This section provides a formal security analysis of the ElephantAgent protocol. Under standard cryptographic and system assumptions, we prove that ElephantAgent achieves the two security properties formalized in 3.2: Contextual State Continuity and Historical Traceability.

5.1 Preliminaries and Assumptions↩︎

We adopt the protocol definitions from 4. The contextual state at any point is \(C = \langle T, M \rangle\), where \(T\) denotes the tool state and \(M = \langle M^I, M^R, M^A \rangle\) denotes the memory. As defined in 4, this contextual state is not the full agent context; rather, it is the bounded, security-critical subset of the agent’s entire context that ElephantAgent explicitly maintains and verifies.

Our security proofs rely on the following assumptions:

• (A1) SCM Ledger Correctness. The State Continuity Module (SCM) implements a linearizable, append-only ledger as specified in 2, backed by Nimble’s linearizable ledger service [12]. Our analysis treats SCM as a trusted backend abstraction and does not re-prove Nimble’s internal safety or liveness properties. Thus, our arguments about reading the latest state and appending entries in order rely on the linearizability provided by the Nimble-backed SCM instantiation. For any ledger \(\ell\), the recorded sequence identifiers \((id)\) are strictly monotonic and gap-free, and a Commit operation succeeds only if the submitted identifier is exactly one greater than the last committed identifier for \(\ell\). SCM issues a receipt (a digital signature) only for entries that have been appended to the ledger. The SCM signing key \(SK_{SCM}\) is securely confined to attested SCM instances.

• (A2) Signature Unforgeability. Signatures generated by SCM under its private key \(SK_{SCM}\) are unforgeable. An adversary cannot produce a valid signature \(\sigma\) for any message that a legitimate SCM instance has not signed.

• (A3) Hash Function Security. The cryptographic hash function \(\mathcal{H}\) is collision-resistant. It is computationally infeasible to find two distinct inputs \(X \neq X'\) such that \(\mathcal{H}(X) = \mathcal{H}(X')\).

• (A4) Trusted CG Execution and Non-Bypassability. The Context Guard (CG) executes faithfully within its TEE boundary, and its verification and update logic cannot be bypassed. Specifically, the agent proceeds to planning and execution only after CG has successfully verified the contextual state. Furthermore, CG finalizes any local contextual state update only after obtaining a valid receipt from SCM.

• (A5) Attested and Integrity-Protected SCM Access. For a fixed ledger \(\ell\), CG authenticates the SCM endpoint via remote attestation and pins \(PK_{SCM}\) for proof and receipt verification. All communication between CG and SCM is integrity-protected (e.g., via TLS), preventing on-path tampering. Thus, CG receives only authenticated SCM proofs and receipts for local state verification and update operations.

• (A6) Availability of Local Audit and Recovery Artifacts. Both the audit and recovery guarantees of Historical Traceability require the availability of the local ledger and the corresponding snapshots: the ledger anchors the ordered transition history and retains the state authorization proof, while the snapshots provide the contents needed for audit and for restoring a known-good prior state. However, TEE sealing provides confidentiality and integrity against tampering but does not guarantee availability: an adversary may delete sealed local artifacts and thereby disrupt audit and recovery.

5.2 Contextual State Continuity↩︎

Contextual State Continuity (1) requires that, at every planning and execution cycle, the agent operates only on the latest faithfully evolved contextual state. This property is realized in ElephantAgent by cryptographically binding the local contextual state to the latest SCM-authorized state recorded in SCM’s linearizable, append-only ledger. Consequently, any out-of-band tampering (e.g., modification or rollback) is detected before it can influence the agent’s planning or execution.

The proof of 1 is deferred to 10 due to space constraints. 1 establishes the single-step integrity and freshness guarantee. We now extend this single-step guarantee to a sequential agreement corollary by comparing the real system with the ideal reference system (as defined in 3.2).

1 and 1 establish the protocol-level guarantee underlying Contextual State Continuity: under Assumptions (A1)–(A5), ElephantAgent ensures that planning and execution proceed only on the latest faithfully evolved contextual state, while any out-of-band tampering is detected and blocks further processing.

5.3 Historical Traceability↩︎

Historical Traceability provides a conditional guarantee for post-hoc audit and recovery, thereby addressing in-band semantic abuse that Contextual State Continuity does not prevent. As captured by Assumption (A6), both audit (i.e., the ability to inspect and verify the transition history) and recovery depend on the availability of the local ledger and the corresponding snapshots: the ledger provides the authorized, ordered sequence of state digests together with the corresponding SCM receipts, while the snapshots provide the contextual state contents needed for audit and recovery.

The proof of 2 is deferred to 10 due to space constraints.

Together, 2 and 2 establish the protocol-level guarantee underlying Historical Traceability: under Assumptions (A1), (A2), and (A6), finalized contextual state transitions remain auditable, and recovery to a known-good state is feasible, provided the local ledger and the relevant snapshots are available.

6 ElephantAgent Evaluation↩︎

In this section, we implement and evaluate the ElephantAgent protocol proposed in 4. We first explain the evaluation methodology and then present the experimental setup and results.

6.1 On Evaluation Methodology↩︎

ElephantAgent is a verification-based defense: whether an out-of-band tampering attempt is detected is a deterministic consequence under Assumptions (A1)–(A5) in 5.1, not a statistical property of a learned detector. Under 1, any modification to the protected contextual state that deviates from the SCM-authorized digest causes VerifyState to fail. Accordingly, under Assumptions (A1)–(A5), in-scope out-of-band tampering (e.g., Scenarios I and II in 3.1) is deterministically rejected by VerifyState, rather than characterized by a statistical detection rate. Scenario III (i.e., in-band semantic abuse) is outside the scope of Contextual State Continuity and is instead addressed by Historical Traceability via conditional post-hoc audit and recovery. We therefore do not report attack-specific detection rates, as in prior state-continuity work (e.g., Memoir [19], ROTE [22], and Nimble [12]), and instead focus the empirical evaluation on the performance cost of enforcing Contextual State Continuity.

6.2 Experimental Setup↩︎

Our experiments run on multiple machines equipped with Intel Xeon 6982P-C CPUs that support Intel TDX, a VM-based Trusted Execution Environment (TEE). All machines are “ecs.g9i.xlarge” instances rented from Alibaba Cloud. We enable confidential VM mode (i.e., TDX) on three of them, which we denote as “TDX1”, “TDX2”, and “TDX3”. We additionally use two instances of the same type with confidential VM mode disabled, which we denote as “NT1” and “NT2”. All machines are deployed in the Alibaba Cloud Beijing region and communicate over an intra-datacenter LAN.

6.2.0.1 ElephantAgent.

As shown in 1, our prototype instantiates ElephantAgent over MCP with two augmentation components: a Context Guard (CG) and a State Continuity Module (SCM). CG is integrated into the MCP Host and runs inside a TEE, so its state-verification and state-update logic execute correctly within the trusted boundary. SCM is implemented independently of the MCP components as a Nimble-backed replicated ledger service across TDX-protected VMs and uses TDX-adapted remote attestation for authentication. Our design therefore reuses the Nimble [12] ledger abstraction and guarantees. SCM follows the Rust implementation of Nimble. The remaining components of ElephantAgent are implemented in Python.

The agent’s planning is powered by an external LLM API; in our prototype, we use qwen-flash served by Alibaba Cloud Model Studio. We choose this model because the overhead of contextual state maintenance is at the millisecond level: slower models would cause LLM processing time to dominate the measurement. Using a latency-optimized Qwen model makes the incremental cost of CG and SCM easier to observe. To avoid confounding LLM processing time with network latency, we use the server-side request processing time req-cost-time reported by the Qwen API in place of client-observed llm_round_trip_time (i.e., the duration between the start and end of an LLM API request). That is, we use the server-side compute time rather than the end-to-end request duration observed on the host.

The host-side runtime combines an agent runtime, a Context Guard, and an MCP client. Our implementation supports remote Streamable HTTP transport for MCP Host–MCP Server communication. We implement 19 MCP tools in total: 1 generic artifact-write tool, 6 tools for Email Triage, 8 tools for Code Bug Fix, and 4 tools for Calendar Scheduling. At runtime, the agent exposes only the task-relevant subset of tools, uses task-specific prompts, and produces structured outputs, such as triage reports, fix reports and patches, and scheduling artifacts.

We evaluate two modes: a baseline mode and a confidential mode. In the confidential mode, we evaluate ElephantAgent and deploy its components across multiple machines. The MCP Host runs on “TDX1” (including the Agent, MCP Client, and Context Guard), while the MCP Server runs on “NT1”. The SCM runs on “TDX2” and “TDX3”, with three nodes as separate processes on “TDX2” and two nodes as separate processes on “TDX3”. In the baseline mode, we evaluate NoGuardAgent, which is ElephantAgent without CG and SCM, i.e., a conventional MCP workflow without contextual state protection. The MCP Host runs on “NT2”, while the MCP Server still runs on “NT1”. This comparison measures the end-to-end overhead of ElephantAgent relative to a conventional MCP workflow, including both contextual state maintenance and the use of TDX-protected VMs.

We defer deployment details for CG and SCM, including SCM failure handling, SCM endpoint authentication, and private signing-key management, to 11 due to space constraints.

6.3 Evaluation↩︎

We evaluate the overhead of ElephantAgent across four aspects:

1. system initialization (e.g., remote attestation, SCM setup, and initial state anchoring);

2. data loading (e.g., email thread loading);

3. state verification (e.g., local digest recomputation, SCM communication, and proof verification);

4. state update (e.g., commit latency and local persistence of memory updates).

These measurements are tailored to the deployment of ElephantAgent. For example, we include state verification and state update to measure the overhead of contextual state maintenance.

6.3.0.1 Tasks.

We use three agent workflows to evaluate ElephantAgent. These workflows are chosen to reflect realistic agent tasks while remaining stable across runs. Within each run, each successful query appends one transcript event and may update the artifact through intermediate results or final outputs.

• Email Triage. In each run, the agent loads the thread and produces a structured triage artifact containing a summary, action items, and a draft reply.

• Code Bug Fix. We evaluate on a repository from QuixBugs [33], with one case specification. In each run, the agent processes the predefined issue ID and performs repository read/write, fix report writing, and patch export.

• Calendar Scheduling. We evaluate scheduling on calendar data from CalDAVTester [34]. In each run, the agent loads events, computes candidate time slots under fixed scheduling parameters, and finalizes a structured scheduling artifact.

6.3.0.2 Overhead Summary.

We compare NoGuardAgent in the baseline mode with ElephantAgent in the confidential mode to measure the end-to-end overhead introduced by contextual state maintenance and TDX-protected VMs in ElephantAgent.

Across the three tasks, the mean initialization time is 219.15 ms for NoGuardAgent and 1800.46 ms for ElephantAgent, corresponding to an 8.22\(\times\) initialization overhead. This startup cost is primarily due to remote attestation and SCM setup. However, it is a one-time cost that is amortized over subsequent queries.

2 lists the time breakdown for data loading, state verification/update, and task processing across the three tasks. The per-query overhead remains small across tasks: verification averages 4.23–4.33 ms, update averages 5.25–5.39 ms, and the additional data loading time of ElephantAgent relative to NoGuardAgent remains below 1 ms across tasks. The resulting end-to-end overhead ranges from 1.02\(\times\) to 1.04\(\times\) across the three tasks.

We intentionally choose small tasks so that the millisecond-scale CG/SCM costs are not overshadowed by LLM-driven task processing. For more conventional agent workloads, total runtime would likely be more dominated by task processing, so the relative overhead of ElephantAgent is expected to be even smaller. This suggests that ElephantAgent can be integrated into existing agentic systems without introducing noticeable overhead.

6.4 Ablation Study: Attested MCP Server↩︎

This ablation is motivated by the fact that server-side execution is also security-critical: even if the host-side contextual state is protected, a malicious or compromised MCP Server may still execute harmful logic regardless of the invocations it receives. Running the MCP Server inside a TDX VM and authenticating it via remote attestation hardens the server endpoint. We therefore additionally study a separate attested-server mode to evaluate the cost of protecting MCP Server integrity with a TDX VM and remote attestation. The implementation for this mode is AttestedSrvAgent, which follows the same architecture as NoGuardAgent but runs the MCP Server inside a TDX VM and authenticates the server endpoint via remote attestation during initialization.

In the attested-server mode, the MCP Host runs on “NT2”, and the MCP Server runs on “TDX1” inside a TDX VM. We measure the overhead of AttestedSrvAgent against NoGuardAgent over the same three tasks along two aspects: (1) initialization time; and (2) MCP Server Tool Invocation Time, defined as the total runtime of all remote MCP tool calls. Together, these quantities capture the overhead introduced by the attested server during initialization, due to remote attestation, and during remote tool execution, due to running the MCP Server inside a TDX-protected VM. 7 presents the measurements of MCP Server Tool Invocation Time across the three tasks for NoGuardAgent and AttestedSrvAgent.

Initialization increases from 219.15 ms in the baseline mode to 331.66 ms (1.51\(\times\)) in the attested-server mode. MCP Server Tool Invocation Time also increases consistently: for Email Triage, it rises from 5.05 ms to 5.65 ms (1.12\(\times\)); for Code Bug Fix, from 8.56 ms to 10.25 ms (1.2\(\times\)); and for Calendar Scheduling, from 13.1 ms to 15.98 ms (1.22\(\times\)). These results show that running the MCP Server inside a TDX-protected VM and authenticating it via remote attestation adds a visible but still small overhead to server-side tool execution. We further observe that the relative MCP Server Tool Invocation overhead increases with the baseline invocation time across the three tasks (from 1.12\(\times\) to 1.22\(\times\)), suggesting that TDX-protected VMs impose a cost that tends to grow with the amount of in-VM tool execution. Given the relatively small overhead, this mode may be appropriate for MCP Servers that provide security-critical services (e.g., financial or medical services).

We include the attested-server mode only in this ablation study for two reasons. First, it introduces additional TEE hardware cost that practitioners may dislike. Second, this mode is adapted specifically to MCP: agentic systems based on other deployments (e.g., CLI-style deployment) may not require this additional level of attestation and protection, because their tools can be local.

We also note that the attested-server mode guarantees that an MCP Server follows the agent’s invocations and faithfully executes the intended tool with the specified parameters, but it does not mitigate in-band semantic abuse caused by externally retrieved content. For example, a webpage summarization tool may retrieve malicious content from an external website, and the retrieved content may then be passed by the tool to the agent and maliciously steer its behavior. However, such semantic abuse can be handled through the Historical Traceability property of ElephantAgent, provided that the relevant local artifacts are available.

7 Conclusion↩︎

We present ElephantAgent, a protocol for securing agentic systems against contextual state poisoning through state continuity verification. ElephantAgent tracks the contextual state of an agentic system and enforces that it evolves along a linearizable history to protect against out-of-band state tampering. Additionally, ElephantAgent supports conditional post-hoc audit and recovery to handle in-band semantic abuse. We instantiate ElephantAgent over MCP in our prototype and demonstrate that contextual state protection introduces only very small task overheads. We also note that it is an add-on protocol that can be applied to other agentic systems (e.g., a CLI-based agentic system). ElephantAgent is designed to address a long-standing gap in agentic systems: their context lacks proper protection. We hope ElephantAgent inspires more secure future agentic system design.

8 Generality of ElephantAgent↩︎

The add-on components of ElephantAgent— a host-local CG and a remote SCM — can also be applied to augment other agentic systems. 8 illustrates the same augmentation architecture instantiated for a CLI-based deployment. Under this mapping, the main change is the local interface: tool enumeration and invocation are mediated through CLI command dispatch rather than an MCP client/server interface. CG still protects the host-side command surface exposed to the agent (e.g., command names, wrappers, permission policies, and command documentation) together with the host-side memory, and SCM continues to provide the same remote state maintenance service. In this instantiation, the Local Command Backends play a role analogous to that of the MCP Tool Servers in 1, except that they typically reside on the untrusted Host Platform as local commands, binaries, scripts, and filesystem-facing utilities rather than as remote tool servers. Thus, the ElephantAgent protocol remains applicable: CG verifies the current contextual state against SCM before the agent’s planning and execution, and commits the next contextual state digest before finalizing local side effects.

9 Attack Vector Coverage↩︎

This section provides an explicit catalog of the out-of-band tampering vectors covered by ElephantAgent’s Contextual State Continuity. It also identifies the vectors addressed conditionally by Historical Traceability, and finally lists the vectors that are explicitly out of scope. The catalog is an extension of the threat model in 3.1; it does not introduce new assumptions or guarantees beyond those already established in 5.

9.0.0.1 In-Scope Vectors (Contextual State Continuity).

Each vector below is detected before the agent’s planning or execution by the digest or identifier check in VerifyState (4), under Assumptions (A1)–(A5).

• V1: Tool descriptor mutation between queries (rug pull [3]). An MCP Server registers a benign descriptor at onboarding and later mutates it between two queries to embed adversarial directives. The recomputed local contextual state digest changes while the SCM-authorized digest does not, so the digest equality check in 4 fails and the query aborts.

• V2: Memory file direct tampering. An adversary with host-level access directly modifies one of \(M^I_t\), \(M^R_t\), or \(M^A_t\) (e.g., replaces a transcript file or overwrites an artifact outside the query-driven workflow). The locally recomputed contextual state digest changes, causing VerifyState to fail.

• V3: Memory rollback. An adversary replays an older sealed version of the locally persisted memory (e.g., the interaction history or managed artifacts). The locally recomputed digest corresponds to a prior step, whereas SCM returns the latest authorized digest for the ledger; the mismatch triggers a verification failure.

• V4: Stale SCM proof replay. An adversary replays an SCM proof issued for an earlier read challenge. VerifyState binds each read to a fresh nonce \(n_r\); the replayed proof carries \(n_{scm} \neq n_r\) and is rejected by the nonce check.

• V5: Forged SCM proof or receipt. An adversary fabricates an SCM proof or commit receipt without access to \(SK_{SCM}\). Under Assumption (A2), signature verification under the attested \(PK_{SCM}\) fails and the proof or receipt is rejected.

• V6: SCM endpoint impersonation. An adversary stands up a rogue service claiming to be SCM. Under Assumption (A5), CG authenticates the SCM endpoint via remote attestation and pins the attested \(PK_{SCM}\); a rogue endpoint fails attestation or channel binding and is rejected before any proof or receipt is used.

• V7: Interrupted state update after SCM commit. An adversary crashes or interrupts CG after the next-state digest has been committed to SCM but before the corresponding local update has been fully materialized and recorded in the local ledger. The commit-before-finalize workflow in 5 seals a pending update record before local side effects are finalized, so recovery either resumes that pending update or rejects a partially finalized local state whose recomputed digest no longer matches the SCM-authorized state digest.

9.0.0.2 Conditionally In-Scope Vectors (Historical Traceability).

The following vectors either take effect through properly committed transitions or target the local artifacts used by Historical Traceability. They are handled conditionally under Assumption (A6) via 2 and 2.

• V8: In-band semantic abuse (Scenario III). An adversary induces the agent (e.g., through prompt injection in externally retrieved content) to execute harmful operations that are then committed as authorized transitions. The local ledger retains the ordered state transition history and the corresponding snapshots retain the contextual state contents; post-hoc audit inspects the ledger together with the relevant snapshots to identify the first malicious step \(k\), and recovery to a prior step \(j < k\) also relies on the corresponding ledger entry and snapshot.

• V9: Local artifact tampering. An adversary tampers with the local artifacts used for Historical Traceability, including the local ledger and the corresponding snapshots. We distinguish two cases. First, direct modification of these sealed artifacts is rejected by the sealing integrity check. Second, rollback to older sealed artifacts is treated as an availability limitation: the ledger and snapshots remain valid but are limited to earlier versions, so audit and recovery are correspondingly constrained (e.g., recovery can only restore a relatively stale contextual state).

9.0.0.3 Out-of-Scope Vectors.

The following vectors are explicitly outside the protection scope of ElephantAgent and are either excluded by the trust model or discussed in 12:

• V10: TEE compromise. Attacks that break the TDX hardware security boundary (e.g., side channel attacks against the TEE) invalidate Assumptions (A1), (A4), and (A5) and are out of scope.

• V11: LLM service channel compromise. Tampering with prompts or responses on the channel to the external LLM service, or compromise of the remote model itself, is outside the scope of host-side contextual state continuity (see 12).

• V12: Availability attacks on local artifacts. An adversary controlling the untrusted host may delete the local ledger or snapshots. This disrupts audit and recovery and renders the service unavailable by triggering fail-closed behavior, but it does not cause ElephantAgent to accept tampered state (see 12).

• V13: SCM quorum loss. If a majority of SCM nodes fail, the Nimble-backed SCM preserves safety but loses liveness; ElephantAgent fails closed until SCM is reconfigured.

• V14: Compromised initial trust root. A lenient ApprovePolicy can anchor a malicious initial contextual state for the agentic system (e.g., the basic TOFU-based ApprovePolicy used in our experimental prototype). Strengthening ApprovePolicy (e.g., with manifest signature verification) is advisable for production deployment.

10 Deferred Proofs↩︎

This section restates 1 and 2 from 5 and provides their deferred proofs.

10.1 Lemma 1↩︎

Lemma 1(Contextual State Integrity and Freshness).

Fix a ledger \(\ell\) maintained by SCM. If VerifyState (4) returns success, then the contextual state accepted by CG for release to the agent satisfies the following properties:

1. Integrity. The accepted contextual state is a faithfully evolved contextual state for ledger \(\ell\).

2. Freshness. The accepted contextual state is not a stale prior state, but the latest state for ledger \(\ell\).

Moreover, any attempt to make CG proceed on an out-of-band tampered contextual state causes VerifyState to return failure or abort, and by Assumption (A4), the agent does not proceed to planning or execution on such a state.

10.2 Lemma 2↩︎

Lemma 2(Authorized, Logged, and Ordered Effective Transitions).

Fix a ledger \(\ell\) maintained by SCM. Consider an execution of 6 in which UpdateState is invoked after a successful VerifyState and returns success, advancing the local sequence identifier from \(id\) to \(id+1\). Then the following statements hold:

1. There exists a valid SCM receipt \(\sigma_{commit}\) for the tuple \((\ell, id+1, h_{next})\), where \(h_{next}\) is the digest of the SCM-authorized next contextual state.

2. The local ledger \(\mathcal{L}_{\text{local}}\) contains a record \((id+1, h_{next}, \sigma_{commit}, \text{snapshot\_ref})\) corresponding to that authorized transition for ledger \(\ell\). The \(\text{snapshot\_ref}\) field is present in every record; it either contains a reference to a snapshot (if the snapshot policy created a checkpoint) or is \(\text{NULL}\) (otherwise).

3. The locally recorded transitions for ledger \(\ell\) preserve the order of the corresponding SCM-authorized transitions.

11 Deployment Details of CG and SCM↩︎

This section provides additional deployment details for the CG and SCM components of 6.2, including SCM failure handling, attested authentication of the SCM endpoint, and private signing-key management.

11.0.0.1 SCM Reconfiguration Under Failures.

If SCM loses some nodes, an administrator can replace the failed nodes through Nimble’s reconfiguration mechanism before quorum is lost. However, if SCM loses a majority of its nodes, the Nimble-backed SCM preserves safety but loses liveness, because no quorum remains to produce receipts or proofs that CG can verify. In this case, ElephantAgent fails closed until SCM is reconfigured.

11.0.0.2 SCM Endpoint Authentication.

We deploy CG and SCM inside TDX-protected VMs. CG authenticates the SCM service endpoint via remote attestation before using any SCM proof or receipt for verification. The attestation follows a challenge–response protocol. CG sends a fresh nonce \(n_{CG}\) to SCM, and SCM returns a TDX quote whose report_data commits to \(\text{SHA256}(n_{CG}\,\|\,\texttt{context}\,\|\,PK_{SCM})\), where \(PK_{SCM}\) is the SCM service public key used both for proof/receipt verification and for binding the attested SCM identity to the authenticated channel. CG then verifies the returned quote through a standard quote-verification pipeline and validates the attested context and configuration against an allowlist policy. CG enforces channel binding by checking that the TLS peer-certificate public key matches the attested \(PK_{SCM}\). After these checks, CG pins the attested \(PK_{SCM}\) for subsequent verification. CG caches the attestation record and re-attests when necessary (e.g., after SCM reconfiguration). This ensures that CG uses SCM proofs or receipts only from an authenticated SCM endpoint.

11.0.0.3 Private Signing-Key Management.

In our current experimental prototype, the SCM private signing key is loaded locally. A production deployment of ElephantAgent should instead use a production-grade key management service for private key provisioning and lifecycle management (e.g., Alibaba Cloud KMS [35]).

12 Limitations↩︎

This section discusses the limitations of ElephantAgent.

12.0.0.1 LLM Communication Security.

ElephantAgent does not secure the communication channel between the agent and the external LLM service (e.g., the qwen-flash API used in this study). If this channel or the remote model service is compromised, an adversary may tamper with prompts or responses outside the protection scope of host-side contextual state continuity. One practical way to mitigate this exposure is to deploy a trusted local model (e.g., Qwen 3.5-27B) on an NVIDIA GPU (e.g., H100) with confidential-computing support [36].

12.0.0.2 Availability Under Adversarial Interference.

ElephantAgent prioritizes safety over liveness under adversarial interference: an adversary may block progress by tampering with host-side persisted contextual state or preventing access to the latest SCM-authorized state, thereby triggering fail-closed behavior during verification. The audit and recovery guarantees of Historical Traceability are conditional on artifact availability: they require the local ledger and the corresponding snapshots. Although TEE sealing protects these artifacts against tampering, it does not guarantee availability [13]; an adversary controlling the host platform may simply delete them, thereby disrupting audit, recovery, and query processing.

12.0.0.3 Recovery Scope and Freshness.

The recovery mechanism of Historical Traceability restores the scoped contextual state \(C\) maintained by ElephantAgent, rather than the agent’s full runtime context. This design keeps state maintenance and verification practical by limiting protection to the bounded, security-critical subset of context. If broader restoration is desired, additional components can be incorporated into \(C\), but doing so increases digest recomputation, storage, and synchronization overhead. Moreover, recovery verifies the integrity of a selected prior state, not its freshness. By checking the recorded receipt and digest, ElephantAgent ensures that the restored state was a previously faithfully evolved contextual state, but it does not guarantee that the state is recent: the first malicious transition may have occurred much earlier without being noticed. Recovering to a more recent known-good state may therefore require periodic audits.

References↩︎