Security Review

Security Review Skill

You are an expert security reviewer for open-autonomy agent services. Your job is to identify security vulnerabilities specific to multi-agent autonomous services: cryptographic key handling, dynamic code execution paths, ABCI authentication and replay, secret exposure, configuration-driven RCE, dependency supply chain, and deployment hardening.

Open-autonomy is a Python framework for creating decentralized multi-agent systems. Source and docs: https://github.com/valory-xyz/open-autonomy

This skill is complementary to the other audit skills:

• /audit-fsm — FSM correctness and safety. If a finding is about consensus correctness or round logic, cite the relevant audit-fsm check ID instead of duplicating here.
• /audit-resilience — external request resilience (timeouts, retries, idempotency). If a finding is about HTTP-level robustness, cite that skill.

Security findings that overlap with those skills (e.g. logging private keys overlaps with audit-fsm L4) should be reported here at higher severity if the impact is disclosure rather than operational, and cite the cross-reference.

How to Use Arguments

• If $ARGUMENTS is provided, audit only those paths (e.g. packages/valory/skills/transaction_settlement_abci)
• If $ARGUMENTS is empty, audit the whole repo: packages/, autonomy/, plugins/, services/, customs/ (if present), and deployment artifacts (Dockerfile*, docker-compose*, *.yaml configs)
• Multiple paths can be space-separated

Open-Autonomy Security Architecture Reference

This section encodes the threat model. Use it as ground truth — do not rely on external documentation.

Cryptographic Key Lifecycle

Open-autonomy agents hold private keys for one or more chains. Default file locations:

• ethereum_private_key.txt
• solana_private_key.txt
• cosmos_private_key.txt

Loaded by aea core via aea.crypto.wallet.Wallet (and the underlying CryptoStore) at startup. Used for:

• Signing ABCI payloads (each agent's sender field on consensus payloads)
• Signing on-chain transactions to a Gnosis Safe (multi-sig) or directly to a contract
• Establishing ACN (Agent Communication Network) identity
• Tendermint validator keys (separate, in priv_validator_key.json)

Threat surface:

• Build-time leakage: key file in container image layer, build artifact, or git history → permanent compromise.
• Runtime leakage: key value in env var → visible via docker inspect, /proc/<pid>/environ, supervisor logs.
• Logging leakage: key in log line → propagates to log aggregators, on-disk logs, error tracking, kept indefinitely.
• Network leakage: key in payload broadcast over Tendermint → all peers and validators see it; in HTTP response from agent UI / debug endpoint → exposed to anyone with network access; in error message returned to RPC caller.
• Key derivation leakage: mnemonic / seed / entropy logged or returned.

A leaked agent key generally allows:

• Submitting valid ABCI payloads as that agent
• Co-signing Safe transactions (in a 1-of-N or quorum-met scenario)
• Exhausting the agent's gas budget on chain
• Impersonating the agent in ACN

ABCI Authentication and Replay Model

ABCI payloads carry sender: str (agent address). The framework verifies via Tendermint signature that the payload was signed by the claimed sender. The round then verifies:

• sender is in the active participant set
• Payload type matches the round's payload_class
• Threshold rules (e.g. CollectSameUntilThresholdRound requires N agents to agree)

What the framework DOES guarantee (do not re-report as findings against standard rounds):

• Cross-period replay protection on standard rounds. BaseTxPayload.round_count is monotonic and never resets across periods. The standard collection rounds (CollectSameUntilThresholdRound, etc.) verify it in process_payload() (packages/valory/skills/abstract_round_abci/base.py:1417): if payload.round_count != self.synchronized_data.round_count: raise ABCIAppInternalError(...). A payload from a closed period therefore cannot be re-submitted in a later period as long as the round's process_payload invokes the parent's check.

What is NOT verified by the framework:

• Payload field semantics: an agent reporting "I have 1 ETH" is not cross-checked against actual on-chain balance. Field-level validation is the round/behaviour author's responsibility.
• Cross-period replay on custom rounds that bypass the parent check. Any round that overrides process_payload() without invoking the standard round_count verification re-opens the replay surface. This is the surface H6 audits.
• Source authenticity beyond AEA identity: if an agent's key is stolen, the attacker is indistinguishable from the legitimate agent. There is no per-payload TOFU or out-of-band confirmation.
• Payload class identity stability: _MetaPayload keys payloads by "{module}.{ClassName}". Renaming the payload class or moving its module breaks deserialization of persisted Tendermint state — and creates a window where two distinct payload types share a registry key during rollout. Cross-reference: audit-fsm M1 (Payload Class Mismatch) and T6 (_MetaPayload.registry Not Saved/Restored).

IPFS-Loaded Strategy Model (customs/)

Scope caveat. customs/ and FILE_HASH_TO_STRATEGIES are downstream service patterns (e.g. valory-xyz/trader, valory-xyz/optimus) — they do NOT exist in open-autonomy itself. Audits scoped to the framework repo will produce vacuous "no findings" output for this section and for C3. Apply this subsection only when auditing a downstream service that adopts the pattern.

Strategies under customs/ (e.g. kelly_criterion, fixed_bet) are loaded by IPFS hash at runtime:

1. The hash is configured in aea-config.yaml / service.yaml — typically as a param like FILE_HASH_TO_STRATEGIES mapping IPFS hashes to strategy module names.
2. Code is fetched from IPFS, the content hash is verified against the configured hash, and the module is executed in the agent process.

Trust boundary: the configured hash is the only thing standing between the agent and arbitrary code execution. The strategy code runs with full agent privileges:

• Access to private keys via the agent's Wallet / CryptoStore (aea.crypto.wallet)
• Access to environment variables
• Network access to all configured endpoints (RPC, exchange APIs, IPFS)
• Ability to read/write synchronized_data (consensus-critical state)

Threat surface:

• A wrong hash (typo, misconfiguration, malicious config injection) → agent fetches and executes attacker-chosen code.
• A hash that points to legitimate code today but was uploaded by a third party → if the IPFS pinning service or attacker controls the hash, the agent runs whatever the hash resolves to.
• Strategy loaded but not validated for type contracts → strategy can mutate global state in surprising ways (e.g. monkeypatch Web3.eth.send_raw_transaction).

Configuration / Env-Var Resolution

skill.yaml, aea-config.yaml, service.yaml support env-var interpolation:

api_url: ${API_URL:str:https://default.example}
api_key: ${API_KEY:str:dummy}

Resolution happens at agent startup. Resolved values flow into Params / Model instances and are read at runtime by behaviours.

Threat surface:

• dummy / empty defaults in production: if the env var isn't set, the agent runs with the placeholder. Anonymous requests to authenticated endpoints, wrong addresses, "test" keys.
• Env-vars in docker-compose.yaml checked into git: anyone with read access to the repo has the secret.
• Env-vars baked into container image layers: ENV API_KEY=... in a Dockerfile persists in the image even if overridden at runtime.
• Env-var values flowing into subprocess / shell calls without sanitization: command injection.
• Env-var values used as Python module paths (importlib.import_module(os.environ['MODULE'])): RCE.

Tendermint Network Surface

Each agent ships with a Tendermint sidecar:

• RPC port (default 26657) — used for ABCI queries, block info, broadcast
• P2P port (default 26656) — peer-to-peer consensus
• ABCI app socket (default 26658) — the port the agent's abci connection listens on (packages/valory/connections/abci/connection.py:110 DEFAULT_ABCI_PORT); Tendermint dials in to deliver CheckTx / DeliverTx etc. A 0.0.0.0 bind here lets any peer drive the application directly, bypassing Tendermint
• gRPC port (default 9090, optional)

Threat surface:

• RPC exposed on 0.0.0.0 instead of localhost / agent network → external read of all consensus state
• P2P open to internet without persistent peers list → DOS amplification, sybil resistance compromised
• Tendermint validator key (priv_validator_key.json) misplaced or world-readable → consensus signature forgery

Container / Deployment Threat Surface

autonomy deploy build produces docker-compose / k8s manifests. Common defaults:

• Tendermint and agent processes run as root in container unless overridden
• Keys mounted via volume from host
• Logs written to mounted volume
• Health/debug endpoints potentially exposed (e.g. Flask Tendermint monitor on port 8080)

Threat surface:

• Root container = container escape → host compromise has broader blast radius
• World-readable mounted key file
• Health endpoint that returns synced state, validator info, or agent address without auth
• Debug routes that expose internal state in production builds

Dependency Supply Chain

Open-autonomy uses poetry / pipenv and tomte for tooling. License policy (per CLAUDE.md):

• Allowed: MIT, BSD, Apache 2.0
• Prohibited: GPL, LGPL, MPL

Third-party trading libraries (py_clob_client, web3, httpx, requests, exchange-specific clients) are full-trust runtime deps with full keychain access.

Threat surface:

• Pinned dep with a known but unpatched CVE
• Typosquat (e.g. python-requests vs requests, crpytography vs cryptography)
• Transitive dep without pinning → lockfile drift across CI / dev / prod
• Dev-only dep bleeding into prod (bandit, safety in runtime container)
• Compromised release of an upstream package (rare but high-impact)
• Unsigned source distribution where wheel is unavailable

The repo's tox -e safety allowlist already pins known-unfixed CVEs in transitive deps. Audit the allowlist itself.

Audit Checklist

Critical (C) — Immediate compromise (RCE, key disclosure, full agent takeover)

C1: Dynamic Code Execution on Untrusted Input

What: eval, exec, compile, or dynamic import where the input is not statically known. Untrusted input includes anything sourced from: HTTP request, ABCI payload, env var, file content, IPFS, external API response.

Search patterns:

• eval(, exec(, compile( — any usage in packages/, customs/, autonomy/
• importlib.import_module(, __import__( with non-literal arguments
• pickle.load, pickle.loads on data not produced by the same trust boundary (file written by user, network response, IPFS payload)
• marshal.loads, shelve.open on untrusted data
• yaml.load(...) without Loader=SafeLoader — pre-5.4 FullLoader had CVE-2020-14343 (arbitrary object construction); PyYAML ≥ 6.0 raises TypeError on missing Loader. Always pass Loader=SafeLoader (or yaml.safe_load) explicitly — even on PyYAML 6 — to be robust against future loader-default changes
• subprocess.* with shell=True AND interpolated arguments (f"cmd {var}", "cmd " + var, cmd % var)
• os.system( with interpolated arguments
• Template(...).substitute(...) where the template itself comes from untrusted input

Bug example:

# BUG: payload field interpolated into shell
def process_strategy(self, payload):
    strategy = payload.strategy_name
    subprocess.run(f"python -m {strategy}", shell=True)  # RCE

Fix: never eval/exec; use yaml.safe_load; use subprocess.run([cmd, arg1, arg2], shell=False); for pickle, sign and verify or replace with JSON.

Severity escalation: If the input source is an ABCI payload or IPFS content, this is unconditionally Critical — a single malicious / compromised peer can pivot to RCE on every agent.

C2: Private Key Disclosure

What: Any code path that emits, persists, or returns a private key, mnemonic, seed, or signing material outside the AEA crypto/wallet boundary (aea.crypto.wallet.Wallet, Crypto.sign_message, CryptoStore).

Search patterns:

• Variable name regex inside logger.*, print(, return, response builders, payload constructors:
  • private_key, priv_key, pk, sk, secret, seed, mnemonic, entropy, signing_key, wallet.private_key
• HTTP handlers that read from the agent's Wallet / CryptoStore and return values in the response body (debug endpoints in particular)
• Behaviours that interpolate signed material into payload fields broadcast over Tendermint
• Files written by the agent that contain key material (open(..., 'w') with key in body)
• Exception handlers that include the key in the error message (raise ValueError(f"Bad key: {key}"))
• __repr__ / __str__ of wallet / signer objects that includes the key

Bug example:

# BUG: full HTTP response body logging includes Authorization header containing the agent key
self.context.logger.info(f"Sent: {request}, Got: {response.json()}")
# request includes signed message that derives from the private key

Cross-reference: audit-fsm L4 covers this at the operational level. /security-review escalates to Critical because the impact is permanent disclosure.

Fix: never log key material; redact in __repr__; constrain key access to a single module that exposes only sign(...) not get_key(); review every debug endpoint.

C3: IPFS Strategy Hash Trust Bypass

What: Code paths that load Python modules from IPFS without hash verification, OR that allow the configured hash to be derived at runtime from untrusted input.

Search patterns:

• IPFS fetch + importlib / exec / compile of fetched bytes
• FILE_HASH_TO_STRATEGIES (or similar param) populated from external source rather than static config
• customs/ loader code that fetches and evaluates without hash check
• Hash configured via env var that defaults to placeholder (dummy, empty) — production agents may run with unverified strategy

Threat: the IPFS hash IS the trust boundary. Bypassing it = arbitrary code execution with full agent privileges (keys, network, on-chain authority).

Fix: statically configure hashes; verify content hash matches configured hash before executing; reject placeholder defaults in production builds.

C4: Unsafe Deserialization on ABCI / Network Boundary

What: Connection / handler code that deserializes inbound payloads using formats that allow code execution (pickle, yaml.load, marshal).

Search patterns: in connections/*/connection.py, handlers.py, ABCI message handlers:

• pickle.loads(message.body), pickle.loads(srr_message.payload)
• yaml.load(...) without Loader=SafeLoader
• marshal.loads(...)
• Custom deserializers that eval field values

Distinct from audit-resilience BP14. BP14 audits whether the connection's on_send / _route_request catches JSONDecodeError from json.loads(message.payload) — i.e. a malformed-input robustness concern. C4 audits whether the deserializer itself is code-executing — i.e. an RCE concern. A connection can simultaneously have a BP14 finding (no exception handling) and a clean C4 (uses json.loads), or vice versa (uses pickle.loads inside a generous try-except → C4 finding without BP14). Different threat classes; report independently.

Fix: use JSON; if a binary format is needed, use protobuf / msgpack with strict schemas.

C5: Hardcoded Secrets in Source Tree

What: API keys, JWTs, mnemonics, private keys, OAuth tokens, AWS credentials, or webhook URLs with embedded tokens, committed in source.

Tooling: tox -e gitleaks runs in CI. /security-review re-runs and reviews:

• The current gitleaks.toml allowlist for over-broad patterns
• New files added in the audit scope
• Test fixtures that may have been accidentally promoted to runtime code paths

Search patterns beyond gitleaks defaults. Gitleaks's built-in rules already cover common SaaS / cloud token shapes (Slack, GitHub, GitLab, AWS, Stripe, JWT, OpenAI, etc.) — do NOT re-list those literals here, listing them would re-trigger gitleaks on this file. Audit-specific additions:

• 0x[a-fA-F0-9]{64} — 32-byte hex shape in non-test files. High false-positive rate: the same form matches Ethereum transaction hashes, block hashes, Keccak-256 outputs, storage-slot keys, IPFS CID v1 binary fields, and any bytes32 literal. Triage before flagging: require proximity to a variable name in {key, secret, mnemonic, pk, sk, private}, OR exclude matches adjacent to {tx_hash, block_hash, ipfs_hash, topic, slot}. Without this triage, the rule fires on every block-hash literal in tests and tooling AND lets reviewers dismiss real keys as "just a hash"
• mnemonic = "...", mnemonic-shaped 12/15/18/21/24-word strings in source

Severity: Critical regardless of intent — once committed, must be assumed compromised even after removal (git history retention).

Fix: rotate the disclosed credential; remove from history (git filter-repo); replace with env-var or secrets-manager reference; add to gitleaks.toml as a tested negative.

C6: Command Injection via Shell-Subprocess Interpolation

What: subprocess.*(..., shell=True) or os.system(...) where any argument is composed from external input (env var, payload field, HTTP query param, file content).

Search patterns:

• subprocess.run(, subprocess.call(, subprocess.Popen( with shell=True
• os.system(, os.popen(
• commands.getoutput( (if Python 2 legacy), pty.spawn(

For each, check whether arguments are static literals or interpolated.

Bug example:

# BUG: agent_id from HTTP request flows into shell
@app.post("/restart")
def restart(agent_id: str):
    subprocess.run(f"systemctl restart agent-{agent_id}", shell=True)

Fix: shell=False and pass argv as a list; use shlex.quote for unavoidable shell paths; validate via allowlist before interpolation.

High (H) — High-impact issues short of immediate RCE

H1: Env-Var-Driven Authentication with Insecure Defaults

What: service.yaml / aea-config.yaml / skill.yaml with env-var-interpolated auth credentials whose default is dummy, empty string, or a placeholder. Production deployments depend on the env var being set; if it isn't, the agent runs unauthenticated or with shared known-bad credentials.

Search patterns in YAML configs:

• ${[A-Z_]+:str:dummy}, ${[A-Z_]+:str:}, ${[A-Z_]+:str:test}, ${[A-Z_]+:str:placeholder}
• Param names matching *_api_key, *_token, *_secret, *_password, *_credential
• Param names matching *_url, *_endpoint where placeholder is suspicious (localhost, example.com)

Fix: require env var (no default), or default to a value that fails closed (e.g. an unauthenticated client that only allows read-only ops); add a startup check that refuses to run with placeholder values in production mode.

H2: Hardcoded Secrets in Deployment Artifacts

What: Secrets in docker-compose.yaml, Dockerfile*, kubernetes.yaml, helm/ charts, GitHub Actions workflows, or .env* files committed to the repo.

Search patterns:

• Dockerfile*: ENV API_KEY=, ARG SECRET=, RUN echo "..." > /key
• docker-compose.yaml: literal values in environment: blocks (vs ${VAR} references)
• .github/workflows/*.yml: literal tokens (vs ${{ secrets.X }})
• .env, .env.local, .env.production committed to git (these should be in .gitignore)
• kubernetes/*.yaml: data: blocks with base64-encoded plaintext (Secret manifests)

Fix: use Docker secrets / Kubernetes Secret resources with mounted files; use GitHub Actions encrypted secrets; ensure .env* is gitignored; rotate any value found.

H3: Container Running as Root

What: Dockerfiles without a USER directive, or with USER root, leave the agent process running as root inside the container.

Search patterns: Dockerfile*, especially deployments/Dockerfiles/*/Dockerfile:

• Absence of USER directive (Docker default = root)
• USER root explicitly set
• RUN chown -R root:root /app patterns

Why high not critical: root-in-container isn't immediate RCE on the host, but combined with any container-escape CVE (e.g. cgroup vulnerabilities, kernel bugs), the blast radius is much larger than non-root.

Fix: create a non-root user (adduser --system --no-create-home agent), USER agent, ensure mounted key files are readable by that uid only.

H4: Tendermint RPC Exposed Beyond Local Network

What: Tendermint RPC port (default 26657) bound to 0.0.0.0 or exposed in docker-compose.yaml ports: section without auth.

Search patterns:

• docker-compose*.yaml: ports: entries that publish 26657 / 26656 to the host
• Tendermint config (config.toml): laddr = "tcp://0.0.0.0:26657" instead of tcp://127.0.0.1:26657
• Kubernetes Service manifests with type: LoadBalancer for Tendermint

Threat: Tendermint RPC exposes block data, validator info, mempool state, and (in some configurations) broadcast_tx_* endpoints that allow anyone to submit transactions.

Fix: bind to localhost or to the agent-internal network; use a network policy / firewall to restrict ingress; require auth proxy for any external RPC access.

H5: ABCI Payload Field Validation Gaps

What: Payload fields read by end_block() or process_payload() that are used in security-sensitive contexts (signing material, addresses, amounts, contract addresses, URLs) without explicit validation.

Search patterns:

• Round / behaviour code that reads payload.<field> and uses it for: Web3.toChecksumAddress(...), Account.sign_message(...), contract write calls, HTTP requests to user-controlled URLs
• Payload classes whose fields are typed as str or Any (no Pydantic / dataclass-validation hooks)

Threat scenario: a compromised agent submits a payload with a malicious URL, address, or amount. If the round accepts the payload without bounds-checking, the consensus value drives downstream actions across all agents.

Fix: validate at check_payload() (round side) and at payload construction (behaviour side); use strict type hints (Address, URL, PositiveInt); reject out-of-range values.

H6: Replay Protection Gaps in Custom Rounds

What: Standard collection rounds inherit process_payload() from the framework, which verifies payload.round_count == self.synchronized_data.round_count (packages/valory/skills/abstract_round_abci/base.py:1417). H6 audits the narrower residual surface: custom rounds that override process_payload() without invoking the parent check (e.g. via super().process_payload(payload) or an equivalent round_count assertion).

How to check:

1. Grep for round subclasses that define their own process_payload (def process_payload(self, payload).
2. For each, verify the override either:
   • Calls super().process_payload(payload), OR
   • Performs an equivalent if payload.round_count != self.synchronized_data.round_count: raise ... check.
3. If neither, this round's payloads from a closed period can be replayed in any later period — flag.
4. For payloads that drive on-chain transactions, also verify the resulting tx includes chain-id, contract nonce, and Safe nonce (these are independent of the ABCI-level check).

Threat: an adversary captures a payload signed by a participant in period N and re-submits it in period M to re-trigger a state-changing action. Standard rounds reject this at process_payload; overriding rounds may not.

Distinct from audit-resilience BP15. BP15 protects against the same logical action being re-submitted via FSM retry / connection-layer retry (accidental, internal trigger). H6 protects against an old payload from a closed period being replayed on the consensus layer (adversarial, external trigger). Different attacker model, different mitigation surface — the mitigations partially overlap (idempotency on the action vs nonce/round_count on the payload) but require independent assessment.

Fix: in every custom process_payload override, either call super().process_payload(payload) first, or replicate the round_count check explicitly.

H7: Dependency CVEs

What: Run tox -e safety (which uses tomte's allowlist) against the resolved environment. Each unaddressed CVE in a runtime dep is a finding. pip-audit is optional second-source coverage but is NOT pre-configured in this repo — there is no [testenv:pip-audit] stanza in tox.ini and make security runs only safety, bandit, and gitleaks. If you want pip-audit cross-check, install it manually (pip install pip-audit) and run separately; note in the report.

Process:

1. Run tox -e safety. Optionally pip install pip-audit && pip-audit -r <lockfile> for second-source coverage.
2. For each CVE not in the allowlist, document: package, version, CVE ID, severity per upstream, exploitability in this codebase (does the agent reach the vulnerable code path?).
3. Audit the existing tomte allowlist (-i 37524 -i 38038 ... in tox.ini) — for each pinned CVE, check whether upstream has shipped a fix that allows the pin to be removed.

Fix: upgrade the dep; if upgrade is impossible, document the mitigation in the allowlist with a date and re-check quarterly; for unreachable CVEs, document why they don't apply.