Agent Wallet Security in 2026: Lessons from Bybit, Trust Wallet, and LangChain

TL;DR — 2025 produced the first real dataset of production wallet security failures relevant to autonomous agents. Three incidents — Bybit ($1.5B), Trust Wallet ($8.5M), and LangGrinch (CVE-2025-68664) — exposed failure patterns that apply directly to betting agents. The OWASP Top 10 for Agentic Applications, released December 2025, gives us a framework to categorize them. This guide maps each incident to that framework and extracts the production security patterns that would have prevented each failure.

Why Post-Mortems Matter More Than Best Practices

Security best practices tell you what to do. Post-mortems tell you what actually goes wrong.

Every incident in this guide involves organizations that knew the best practices. Bybit used multisig cold wallets. Trust Wallet had CI/CD infrastructure. LangChain had serialization safeguards. Each one failed anyway, because the attack surface shifted to places their security model didn’t cover.

For betting agent builders, these failures are more instructive than any checklist. Your agent holds money, processes adversarial inputs, and transacts autonomously — the same properties that made each of these systems vulnerable. The difference is that you can learn from their post-mortems before deploying to production.

For the prescriptive guide to wallet architectures and spending limits, see Agent Wallet Security & Spending Limits. For broad agent security beyond wallets, see Security Best Practices for Agent Betting. This guide focuses specifically on what the 2025 incidents teach us.

The OWASP Agentic Top 10: A Framework for What Goes Wrong

In December 2025, OWASP released the Top 10 for Agentic Applications — the first industry-standard framework addressing security risks specific to autonomous AI agents. Shaped by over 600 security experts, it defines ten risk categories (ASI01 through ASI10) that cover the full attack surface of agentic systems.

The full list:

Four of these map directly to the wallet security failures we’ll analyze:

• ASI01 (Goal Hijack) — Prompt injection leading to unauthorized wallet transactions. The Lobstar Wilde incident is a concrete example: a state-loss crash caused the agent to rebuild an incorrect mental model, leading to a 1,000x overshoot on a transfer.
• ASI02 (Tool Misuse) — An agent using its legitimate wallet permissions to do something harmful. Not because it was hacked, but because its logic failed. The LangGrinch CVE enables this by extracting credentials through normal framework operations.
• ASI03 (Identity & Privilege Abuse) — Weak credential scoping that lets a compromised component escalate to full wallet access. The Trust Wallet hack exploited a single leaked API key to publish malicious code to millions of users.
• ASI04 (Supply Chain) — Compromised dependencies or infrastructure that cascade into wallet compromise. Both the Bybit and Trust Wallet hacks were supply chain attacks at their core.

The rest of this guide uses these OWASP categories to tag each failure pattern, giving you a standardized vocabulary for assessing your own agent’s risk profile.

Post-Mortem #1: Bybit — $1.5 Billion via Blind Signing

Date: February 21, 2025 Loss: 401,347 ETH ($1.5 billion) Attacker: Lazarus Group (North Korean state-sponsored) OWASP categories: ASI04 (Supply Chain), ASI09 (Human-Agent Trust)

What Happened

On February 4, 2025, a senior developer at Safe{Wallet} — the multisig wallet provider Bybit used for cold storage — unknowingly ran a malicious Docker project. This compromised their workstation and gave attackers access to Safe’s AWS infrastructure, including the S3 bucket hosting Safe’s frontend code.

Two weeks later, on February 21, the Lazarus Group injected malicious JavaScript into Safe’s frontend. The code was surgically targeted: it activated only when Bybit’s specific Ethereum multisig cold wallet initiated a transaction. When Bybit’s authorized signers reviewed what appeared to be a routine internal transfer, the injected JavaScript modified the transaction details displayed on their screens. They signed a delegatecall to an attacker-controlled contract that overwrote the wallet’s master copy address — routing all subsequent calls through the attacker’s code.

Within minutes, 401,347 ETH and stETH were drained. Within two minutes of the theft, the malicious JavaScript was removed from the S3 bucket. Intentional forensic evasion.

Root Cause

The attack never touched Safe’s smart contracts. The contracts were audited, the multisig logic was sound, the threshold required three signers. None of that mattered because the attack targeted the layer between the contracts and the humans: the signing interface.

The signers were shown one transaction. They signed a different one. This is blind signing — approving a transaction without independent verification of the actual payload.

The Agent Betting Lesson

If your betting agent uses Safe-based wallets (or any multisig), the Bybit hack is your threat model. Multisig does not protect you if the transaction payload is manipulated before signing.

Agents actually have a structural advantage here that human signers don’t: they can programmatically verify every transaction before signing. A human sees a UI and trusts it. An agent can parse raw calldata and compare it against expected patterns.

from eth_abi import decode
from web3 import Web3

ALLOWED_TARGETS = {
    "0x4bFb41d5B3570DeFd03C39a9A4D8dE6Bd8B8982E",  # Polymarket CTF Exchange
    "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174",  # USDC on Polygon
}

ALLOWED_SELECTORS = {
    "0xa9059cbb",  # transfer(address,uint256)
    "0x095ea7b3",  # approve(address,uint256)
    "0x2e1a7d4d",  # withdraw(uint256)
}

def verify_transaction_payload(tx: dict) -> bool:
    """Verify transaction matches expected patterns before signing.
    Rejects anything that doesn't target a known contract with a known selector."""
    target = Web3.to_checksum_address(tx["to"])
    if target not in ALLOWED_TARGETS:
        return False

    selector = tx["data"][:10] if tx.get("data") else None
    if selector and selector not in ALLOWED_SELECTORS:
        return False

    if selector == "0xa9059cbb":
        _, amount = decode(["address", "uint256"], bytes.fromhex(tx["data"][10:]))
        if amount > MAX_TRANSFER_WEI:
            return False

    return True

This is the kind of verification that would have caught the Bybit attack. The delegatecall to an unknown contract would have failed the allowlist check. Human signers couldn’t do this in real time. Your agent can — and should — do it on every transaction.

Pattern extracted: Independent transaction payload verification against allowlists of known contracts, function selectors, and parameter bounds. Never trust the signing interface alone.

Post-Mortem #2: Trust Wallet — $8.5M via Supply Chain Credential Leak

Date: December 24-26, 2025 Loss: ~$8.5 million across 2,520 wallet addresses Attack vector: Shai-Hulud NPM supply chain attack → Chrome Web Store API key exfiltration OWASP categories: ASI04 (Supply Chain), ASI03 (Identity & Privilege Abuse)

The Shai-Hulud Attack Chain

In November 2025, a massive NPM supply chain attack dubbed “Shai-Hulud 2.0” compromised 500-800 packages and over 25,000 GitHub repositories in under 48 hours. The malware exploited npm preinstall lifecycle scripts to execute before installation completed — even if the installation itself failed. It exfiltrated developer secrets to attacker-controlled GitHub repos, including roughly 400,000 raw secrets with 3,760+ verified as valid.

Among the compromised credentials: Trust Wallet’s Chrome Web Store API key and GitHub developer secrets.

On December 24, attackers used the stolen Chrome Web Store API key to publish Trust Wallet extension v2.68 — a malicious update that bypassed Trust Wallet’s internal review process entirely. The injected code exfiltrated users’ mnemonic seed phrases by routing them to api.metrics-trustwallet.com, disguised as legitimate PostHog analytics traffic. Roughly $8.5 million in crypto was drained from 2,520 wallets before Trust Wallet revoked the credentials and published a clean v2.69 on December 26.

A Single Leaked Credential

One leaked credential — a Chrome Web Store API key — gave attackers the ability to push code to millions of users without any internal review. The credential was exposed because it lived in a CI/CD environment that was accessible to a compromised NPM dependency.

The scope of Shai-Hulud 2.0 is worth absorbing:

• 500-800+ compromised NPM packages
• 400,000+ raw secrets exfiltrated
• 775 GitHub access tokens, 373 AWS credentials, 300 GCP credentials, 115 Azure credentials
• Over 60% of leaked NPM tokens were still valid a week later

Your CI/CD Is Your Wallet’s Attack Surface

Your betting agent’s wallet security extends to your entire development and deployment pipeline. If your GitHub Actions workflow secrets include wallet keys, signing credentials, or API tokens for services that manage funds, a single compromised dependency in your package.json or requirements.txt can exfiltrate all of them.

The attack pattern applies directly to agent builders:

1. You install or update a dependency
2. A compromised preinstall/postinstall script runs during npm install or a malicious setup.py runs during pip install
3. The script reads your environment variables and CI secrets
4. Your wallet keys, API tokens, and signing credentials are exfiltrated

This is not theoretical. It happened to 25,000+ repositories in two days.

# The problem: wallet key accessible to any dependency at install time
# .env or CI secret:
# WALLET_PRIVATE_KEY=0xdeadbeef...
# POLYMARKET_API_KEY=abc123...

# The fix: wallet signing happens in an isolated process
# that dependencies cannot access

import boto3
import json

def get_signing_key():
    """Retrieve signing key from AWS Secrets Manager at runtime only.
    The key never exists in environment variables or CI secrets."""
    client = boto3.client("secretsmanager", region_name="us-east-1")
    response = client.get_secret_value(SecretId="agent-wallet/signing-key")
    return json.loads(response["SecretString"])["private_key"]

def sign_transaction(tx: dict) -> bytes:
    """Sign in a short-lived context. Key is never stored in memory
    longer than the signing operation."""
    key = get_signing_key()
    signed = web3.eth.account.sign_transaction(tx, key)
    del key  # Explicit cleanup, though not cryptographically guaranteed
    return signed.rawTransaction

Even better: use hardware-backed signing (Turnkey MPC, Coinbase Agentic Wallets with TEE, or AWS CloudHSM) where the private key never leaves the secure enclave. A compromised dependency can read environment variables — it cannot extract keys from a TEE.

Pattern extracted: Zero wallet credentials in CI/CD or environment variables. Hardware-backed signing where possible. Dependencies pinned with integrity hashes. Secrets manager for runtime-only credential injection.

Post-Mortem #3: LangGrinch — CVSS 9.3 Serialization Injection in LangChain

CVE: CVE-2025-68664 Severity: CVSS 9.3 (Critical) Affected: langchain-core < 0.3.81, langchain-core 1.0.0 to < 1.2.5, @langchain/core (JS) OWASP categories: ASI02 (Tool Misuse), ASI05 (Unexpected Code Execution)

The Serialization Injection

The LangGrinch vulnerability is a serialization injection flaw in LangChain’s core dumps() and dumpd() functions. LangChain uses an internal 'lc' key to mark serialized objects. The dumps and dumpd functions failed to escape user-controlled data that contained this key — meaning attacker-crafted inputs (including LLM outputs) could inject payloads that the deserialization process treated as legitimate LangChain objects.

The attack surface:

1. An attacker crafts a prompt that causes the LLM to produce output containing a malicious 'lc' key structure in its metadata, additional_kwargs, or response_metadata fields
2. When the application serializes this output (for logging, caching, or state persistence), the malicious payload is embedded
3. On deserialization, the payload executes — instantiating arbitrary classes within LangChain’s trusted namespaces
4. If secrets_from_env=True (the previous default), environment variables are extracted — including API keys and wallet secrets

The Confused Deputy

LangChain’s serialization boundary didn’t distinguish between framework-internal markers and user-controlled data. The 'lc' key was a reserved namespace marker, but nothing prevented external data from containing it. This is a classic confused-deputy problem: the framework trusted data that came through the LLM processing pipeline.

From Market Data to Wallet Key in Five Steps

This is the most directly relevant incident for betting agent builders. If your agent uses LangChain — and many do, for orchestration, RAG, or tool calling — and you store wallet keys or API secrets in environment variables, the LangGrinch vulnerability was a direct path from “LLM processes adversarial market data” to “attacker has your wallet key.”

The kill chain for a betting agent:

1. Agent reads a Moltbook post or market description containing a crafted payload
2. LLM processes the payload and includes the malicious 'lc' structure in its response metadata
3. Agent serializes the response (for logging, caching, or context persistence)
4. On deserialization, the payload extracts WALLET_PRIVATE_KEY from environment variables
5. Attacker receives the key via a callback or exfiltration channel

This is the exact “authorized agent doing unauthorized things” pattern from the OWASP framework. The agent framework itself — not a bug in your code — becomes the exfiltration vector.

# VULNERABLE: wallet key in environment, LangChain has access
# export WALLET_PRIVATE_KEY=0xdeadbeef
# export OPENAI_API_KEY=sk-...

from langchain_core.load import dumps, loads

response = llm.invoke(market_data)  # market_data contains crafted payload
serialized = dumps(response)  # Malicious 'lc' key embedded
restored = loads(serialized)  # Payload executes, env vars exfiltrated

# SECURE: wallet key isolated from agent framework
# Agent process has NO wallet-related env vars
# Signing happens in a separate service

from langchain_core.load import dumps, loads

response = llm.invoke(market_data)
serialized = dumps(response)  # Even if exploited, no wallet keys to steal
restored = loads(serialized)

# Wallet operations go through an isolated signing service
signed_tx = requests.post(
    "http://signing-service:8080/sign",
    json={"tx": tx_payload},
    headers={"Authorization": f"Bearer {get_short_lived_token()}"}
)

Pattern extracted: Never store wallet secrets in environment variables accessible to your agent framework. Isolate signing into a separate process or service. Pin framework versions and monitor CVEs. Update to langchain-core >= 0.3.81 or >= 1.2.5 immediately.

Mapping the Lessons: OWASP Risks to Production Patterns

Each post-mortem maps to specific OWASP categories and produces a concrete defensive pattern. Including the Lobstar Wilde incident for completeness:

The pattern is clear: every failure exploited a trust boundary that the system assumed was secure. Bybit trusted the signing UI. Trust Wallet trusted the CI/CD pipeline. LangChain trusted that serialized data was safe. Lobstar Wilde trusted that the LLM had accurate context.

For betting agents, the lesson is architectural: never trust a single layer. Defense in depth means that every layer — signing, credential management, framework code, spending controls — must independently enforce security constraints.

Seven Production Security Patterns

These patterns are extracted directly from the post-mortems. Each one would have prevented or mitigated at least one of the incidents above.

1. Hardware-Backed Key Isolation

Prevents: Trust Wallet pattern (credential exfiltration), LangGrinch pattern (env var extraction)

Signing keys must live in environments that software cannot exfiltrate from. Three options in order of increasing operational complexity:

• TEE (Trusted Execution Environment): Coinbase Agentic Wallets use AWS Nitro Enclaves. The key exists inside the enclave; signing requests go in, signed transactions come out. The agent code — and any compromised dependency — cannot read the key. See the Coinbase Agentic Wallets Guide for implementation.
• MPC (Multi-Party Computation): Turnkey, Fireblocks, and Privy split the key across multiple parties. No single party holds the complete key. Even if one share is compromised, the full key is not exposed. Key share rotation happens without changing the wallet address.
• HSM (Hardware Security Module): AWS CloudHSM, Azure Dedicated HSM. FIPS 140-2 Level 3 certified. The most secure option, but highest operational overhead. Best for high-value treasury wallets.

For a detailed comparison, see Best Agent Wallet for Prediction Markets.

2. Independent Transaction Verification

Prevents: Bybit pattern (signing UI manipulation)

Every transaction your agent signs must be verified against known-good parameters before the signature is produced. The verification code must be independent of the signing interface — it reads the raw transaction bytes, not what a UI displays.

Minimum checks:

• Target address is in a contract allowlist
• Function selector matches expected operations
• Parameter values are within bounds (amounts, slippage, deadlines)
• Nonce is sequential (no replay)
• Gas parameters are reasonable (no MEV extraction via inflated gas)

See the Python example in the Bybit section above for a concrete implementation.

3. Automated Credential Rotation

Prevents: Trust Wallet pattern (stolen credentials remaining valid)

In the Shai-Hulud attack, over 60% of stolen NPM tokens were still valid a week after exfiltration. Automated rotation closes the window of exposure.

import boto3
import json
from datetime import datetime, timedelta

class CredentialRotator:
    """Rotates API credentials on a schedule via AWS Secrets Manager."""

    def __init__(self, secret_id: str, rotation_hours: int = 48):
        self.client = boto3.client("secretsmanager")
        self.secret_id = secret_id
        self.rotation_hours = rotation_hours

    def get_current_credential(self) -> str:
        response = self.client.get_secret_value(SecretId=self.secret_id)
        secret = json.loads(response["SecretString"])
        rotated_at = datetime.fromisoformat(secret["rotated_at"])
        if datetime.utcnow() - rotated_at > timedelta(hours=self.rotation_hours):
            return self.rotate_and_get()
        return secret["api_key"]

    def rotate_and_get(self) -> str:
        new_key = self._generate_new_key()
        self.client.put_secret_value(
            SecretId=self.secret_id,
            SecretString=json.dumps({
                "api_key": new_key,
                "rotated_at": datetime.utcnow().isoformat(),
            }),
        )
        return new_key

    def _generate_new_key(self) -> str:
        """Platform-specific key regeneration logic."""
        raise NotImplementedError

Recommended rotation intervals:

4. Dependency Supply Chain Hardening

Prevents: Trust Wallet pattern (malicious dependency → credential theft), Shai-Hulud-class attacks

The Shai-Hulud attack compromised packages from Zapier, ENS Domains, PostHog, Postman, and Maven. It used preinstall scripts in NPM and Bun (not Node.js) to evade detection tools. Your npm install or pip install is an attack surface.

Hardening checklist:

• Pin all dependencies with integrity hashes. Use npm ci with package-lock.json (includes integrity fields) or pip install --require-hashes -r requirements.txt. Never install with floating versions in CI.
• Disable lifecycle scripts in CI. npm install --ignore-scripts prevents preinstall/postinstall execution. Run necessary build scripts explicitly afterward.
• Audit continuously. npm audit, pip-audit, Dependabot, or Snyk in CI. Block merges on critical vulnerabilities.
• Minimize your dependency tree. Every transitive dependency is an attack surface. Audit your tree: npm ls --all or pipdeptree. Question every dependency that pulls in 50+ sub-packages.
• Use lockfile-only installs. Ensure CI uses the exact locked versions, not resolved versions. npm ci (not npm install) and pip install --no-deps with explicit requirements.

5. Secrets Isolation from Agent Runtime

Prevents: LangGrinch pattern (framework-level env var exfiltration)

The LangGrinch CVE extracted secrets from environment variables because the agent process had direct access to them. The fix is architectural: the agent process should never have wallet secrets in its environment.

┌──────────────────────────────────────────────────────┐
│                   Agent Process                       │
│  ┌──────────┐  ┌───────────┐  ┌──────────────────┐  │
│  │ LLM /    │  │ Strategy  │  │ Market Data      │  │
│  │ LangChain│──│ Engine    │──│ Feeds            │  │
│  └──────────┘  └─────┬─────┘  └──────────────────┘  │
│                      │                                │
│               Trade Decision (JSON)                   │
│                      │                                │
│  ┌───────────────────▼───────────────────────────┐   │
│  │        Execution Layer (validates limits)      │   │
│  └───────────────────┬───────────────────────────┘   │
└──────────────────────┼───────────────────────────────┘
                       │ Unsigned TX
                       ▼
┌──────────────────────────────────────────────────────┐
│          Signing Service (isolated process)           │
│  ┌────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │ Payload    │  │ Secrets Mgr  │  │ TEE / MPC /  │ │
│  │ Verifier   │──│ (Vault/AWS)  │──│ HSM Signer   │ │
│  └────────────┘  └──────────────┘  └──────────────┘ │
└──────────────────────────────────────────────────────┘

The agent process handles LLM reasoning, strategy, and market data. It produces unsigned transaction payloads. A separate signing service — running as an isolated process, container, or serverless function — retrieves the signing key from a secrets manager, verifies the payload, and returns the signed transaction.

Even if the agent framework is fully compromised (LangGrinch, prompt injection, dependency attack), the signing key is in a different process with a different environment.

6. Protocol-Level Spending Controls

Prevents: Lobstar Wilde pattern (unbounded agent transactions)

This is covered in detail in Agent Wallet Security & Spending Limits. The core principle: spending controls must be enforced at the wallet/smart contract layer, not just in application code. A compromised application layer (prompt injection, framework bug) should not be able to override spending limits.

Minimum controls: per-transaction caps, session rolling limits, daily rolling limits, contract allowlists, and a kill switch. See the SpendingGuard implementation in the wallet security guide for complete code.

7. Blind-Signing Elimination

Prevents: Bybit pattern (signing manipulated transactions)

Agents should never pass through signing requests without parsing them. Every transaction the agent signs must be fully decoded and validated against its expected behavior:

from eth_abi import decode

def decode_and_validate(calldata: bytes, expected_action: dict) -> bool:
    """Decode raw calldata and validate it matches the agent's intended action."""
    selector = calldata[:4].hex()
    if selector != expected_action["selector"]:
        return False

    param_types = expected_action["param_types"]
    decoded = decode(param_types, calldata[4:])

    for i, (name, constraint) in enumerate(expected_action["constraints"].items()):
        value = decoded[i]
        if constraint.get("max") and value > constraint["max"]:
            return False
        if constraint.get("allowlist") and value not in constraint["allowlist"]:
            return False

    return True

# Example: validate a USDC transfer
expected = {
    "selector": "a9059cbb",
    "param_types": ["address", "uint256"],
    "constraints": {
        "recipient": {"allowlist": {POLYMARKET_CTF, KALSHI_SETTLEMENT}},
        "amount": {"max": 10_000 * 10**6},  # $10K max per transfer
    },
}

is_valid = decode_and_validate(tx_calldata, expected)

This is the inversion of the Bybit failure. Instead of trusting what a UI shows, you trust the raw bytes — and only if they match your expectations.

Ethereum Research: Key Management Standards for Agent Wallets

The Ethereum community has been actively developing standards for how autonomous agents should manage keys. Three developments are directly relevant:

ERC-8004: Trustless Agents

ERC-8004 provides a protocol for discovering, choosing, and interacting with AI agents across organizational boundaries without pre-existing trust. It uses three registries — Identity, Reputation, and Validation — with pluggable trust models including stake-secured validation and TEE oracles.

For betting agents, ERC-8004’s key insight is the separation of agent keys (used for authentication) from account keys (controlling funds). This separation means a compromised agent identity doesn’t automatically compromise the wallet. MetaMask’s implementation uses TEEs (AWS Nitro Enclaves) to keep signing keys in isolated enclaves with no external networking or persistent storage.

ERC-8126: AI Agent Registration and Verification

ERC-8126 establishes standards for self-registering and verifying AI agents on Ethereum. It includes Zero-Knowledge Proof-based verification and a unified risk scoring system (0-100) to assess agent trustworthiness.

For prediction market agents, this standard provides a path to verifiable identity — your agent can prove it is the agent you deployed, without revealing implementation details. Combined with the four-layer agent identity approach described in Moltbook Identity, this creates a chain of trust from identity through wallet to execution.

ethresear.ch: Key Management for Autonomous AI Agents

The Ethereum Research discussion on key management for AI agents with crypto wallets covers the unique challenge that agents face: they need to interact directly with blockchains and sign transactions without human intervention, but they also need key storage that resists extraction.

The consensus from the research thread aligns with what the post-mortems demonstrate:

• MPC with threshold signing for operational wallets (agent holds one share, infrastructure holds others)
• TEE-based signing for high-frequency trading where MPC latency is too high
• Session keys with ERC-4337 for scoped, time-bounded permissions that expire automatically
• Key share rotation on a regular schedule, independent of incidents

These aren’t theoretical recommendations. They’re the patterns that would have prevented or mitigated every incident in this guide.

The Betting Agent Security Checklist (2026 Edition)

This checklist is derived from the post-mortems above. Each item directly addresses a failure pattern from a real incident.

Key Management

• Signing keys in hardware-backed storage (TEE/HSM/MPC) — not environment variables (prevents: LangGrinch, Trust Wallet)
• Agent keys separated from account keys (ERC-8004 pattern) (prevents: full compromise escalation)
• MPC key shares refreshed every 7 days (limits: exposure window)
• Session keys expire within 4-24 hours (limits: exposure window)

CI/CD and Supply Chain

• Zero wallet credentials in CI/CD secrets (prevents: Trust Wallet/Shai-Hulud)
• All dependencies pinned with integrity hashes (prevents: supply chain injection)
• npm install --ignore-scripts in CI; build scripts run explicitly (prevents: preinstall attacks)
• Dependency audit in CI pipeline (npm audit / pip-audit) (detects: known vulnerabilities)
• Agent framework version pinned and CVE-monitored (prevents: LangGrinch-class vulns)

Transaction Security

• Independent calldata verification against contract/selector/parameter allowlists (prevents: Bybit blind signing)
• Protocol-level spending limits (per-tx, session, daily) (prevents: Lobstar Wilde)
• Kill switch operational and tested (prevents: cascading losses)

Runtime

• Secrets injected at runtime via secrets manager (Vault/AWS SM) (prevents: LangGrinch)
• Credential rotation automated (24-72hr API tokens, 30-day signing keys) (limits: stolen credential lifetime)
• Signing isolated in a separate process/service from agent logic (prevents: framework-level exfiltration)
• Incident response runbook documented and rehearsed (enables: fast recovery)

What’s Next

This guide covers what went wrong. The companion guides cover what to build:

• Agent Wallet Security & Spending Limits — Complete implementation guide for MPC, multisig, session keys, TEE, and spending controls with Python code
• Security Best Practices for Agent Betting — Prompt injection, API key management, and operational security
• The Lobstar Wilde Incident — Deep-dive into the $250K agent wallet failure and its three-layer failure chain
• Best Agent Wallet for Prediction Markets — Head-to-head wallet comparison with security scoring
• The Agent Betting Stack — Full four-layer architecture and how security fits across the stack
• Agent Wallet Legal Liability — Who is liable when an agent loses money

Guide published March 2026. Not financial or legal advice. Built for builders.