Security Model & Threat Mitigations

ElizaPay assumes a hostile environment. The goal is not to create “secure servers,” but to create secure execution outcomes.

Threat: Operator or Developer Data Exfiltration

Attack

• server admins inspect logs

• developers instrument analytics

• support tools capture sensitive data

Mitigation

• sensitive compute stays in enclave

• no plaintext telemetry required

• use commitment-based audit logs (hash-only)

Outcome: even insiders cannot extract the portfolio state.

Threat: Cloud Provider Visibility

Attack

• cloud host sees memory snapshots

• hypervisor compromise

• kernel-level malware

Mitigation

• enclave memory encryption

• remote attestation verification

• minimal host exposure (no secrets outside enclave)

Threat: Prompt Injection / Malicious Input Manipulation

Attack

A malicious contract, dApp, or message tries to force the agent to:

• drain funds

• approve malicious spender

• route via unsafe bridge

• reveal secrets in output

Mitigation

• strict tool-based agent design (no freeform execution)

• policy engine blocks actions outside permissions

• allowlists for contracts/routes

• simulation + calldata validation

• deny infinite approvals by default

Threat: Transaction Simulation Mismatch

Attack

MEV conditions or block-state changes cause:

• expected output differs

• slippage expands

• route becomes dangerous

Mitigation

• enforce max slippage constraints

• re-simulate just before execution

• atomic route bundles where possible

• abort if expected parameters drift

Threat: Malicious Connectors or Supply Chain Risk

Attack

A connector module is compromised:

• sends funds to attacker contracts

• fakes route outputs

• bypasses policy checks

Mitigation

• connectors are signed / verified

• enclave only loads approved modules

• deterministic ABI constraints

• “policy-first” enforcement independent of connector logic

• code attestation pinning (hash-based)

Threat: Key Theft and Signing Exploits

Attack

If signing keys leak, attacker drains funds.

Mitigation

• non-exportable keys inside enclave

• spend limits enforced pre-sign

• multi-party signing for large amounts

• time delays for high-risk actions

• emergency freeze mode

Threat: Replay Attacks / Transaction Duplication

Attack

A signed intent is replayed.

Mitigation

• nonce-bound signing

• session-bound validity windows

• transaction hash commitments

• one-time proofs (nullifier systems)

Threat: De-Anonymization via Payment Patterns

Attack

Even if balance is private, repeated patterns reveal identity.

Mitigation

• randomized routing within constraints

• optional relayer layer

• proof-based gating without address reuse

• privacy-preserving account abstraction schemes

Threat: Compromised User Device

Attack

Device malware tries to:

• steal UI inputs

• modify recipient address

• intercept transactions

Mitigation

• trusted UI confirmation for high-value actions

• address binding proofs (“pay this invoice hash”)

• policy enforcement independent of UI

• signed intent display with checksum verification

• optional external co-sign hardware confirmation