Opensea Skill

• Outcome: Review
• Latest audit: Sep 1, 2026 · 7:34 PM UTC
• Version: 2.21.1

Overview

This appears to be a real OpenSea integration, but it needs Review because it can perform wallet-backed trades, swaps, account changes, and credential persistence with uneven confirmation guidance.

Install only if you want an agent to work with OpenSea and potentially initiate wallet-backed trades, swaps, listings, offers, cancellations, tool payments, and account relationship changes. Use a managed wallet provider with caps and allowlists, keep only limited funds in the agent wallet, avoid production raw private keys, review exact order/quote/transaction details, and require explicit user confirmation before any state-changing operation. Treat cached API keys, auth.json, wallet JWTs/PATs, and provider secrets as sensitive credentials and rotate or revoke them when no longer needed.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (25)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence
• Finding: The skill advertises operational capabilities that involve network access and shell-based tooling via sub-skills and declared dependencies, but it does not declare corresponding permissions at the router level. This creates a trust and review gap: an agent or operator may invoke the skill without understanding it can reach external services and potentially execute shell commands indirectly through its routed sub-skills.

Description-Behavior Mismatch

Medium

• Confidence: 91% confidence
• Finding: The skill is branded primarily as a query/API skill, but it explicitly includes wallet-authenticated and state-changing operations such as profile/settings changes, wallet linking, order cancellation, and auth flows. This scope mismatch can cause an agent or operator to invoke mutating actions under the assumption that the skill is read-only, increasing the chance of unintended account changes.

Description-Behavior Mismatch

High

• Confidence: 95% confidence
• Finding: The file says certain capabilities should be handled by other sub-skills, yet it still documents overlapping functions such as drop mint transaction building, deploy flows, saved tools management, and agent-account relationship writes. This undermines routing boundaries and can bypass safer specialization, causing an agent to perform higher-risk actions from a skill expected to be limited to API queries.

Intent-Code Divergence

Medium

• Confidence: 86% confidence
• Finding: The documentation presents marketplace queries as read-only, but the same file elsewhere includes wallet-scoped write operations such as saved-tool modifications, agent relationship changes, and order-cancellation-related operations. This inconsistent messaging can mislead consumers and policy layers into trusting the skill as non-mutating when it is not.

Intent-Code Divergence

Medium

• Confidence: 94% confidence
• Finding: The documentation presents a 'Private Key Setup' flow that strongly suggests the agent will use the supplied PRIVATE_KEY for signing, but later clarifies that signing is actually delegated to the RPC node via eth_sendTransaction and that the PRIVATE_KEY is only validated, not used. This mismatch can mislead operators into believing they are using local-key semantics while actually trusting a node-managed key, which changes the security boundary and can result in accidental exposure, use of the wrong signer, or unsafe deployment against non-local or misconfigured RPC endpoints.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The README explicitly advertises transaction-capable skills for NFT trading, token swaps, and wallet-backed execution, but it does not prominently warn that these actions can move funds, incur gas costs, or be irreversible. In an agent-skill context, weak safety framing increases the chance that an operator or downstream agent invokes high-risk actions without adequate confirmation or human review.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The saved-tools operations include state-changing actions like save and remove, but the documentation does not prominently warn that these modify persisted wallet-scoped server state. In an agent setting, lack of explicit mutation warnings increases the risk of accidental writes based on ambiguous prompts or misunderstood examples.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The agent account commands can declare, confirm, revoke, and withdraw persisted public or semi-public relationship state, yet the section lacks a strong up-front warning that these actions alter account metadata visible to others. Because these are identity/relationship operations rather than obvious financial transactions, users may underestimate their significance and authorize unintended changes.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This reference lists transaction-building and fulfillment endpoints for listings without any nearby warning that these calls can lead to wallet-affecting or irreversible on-chain actions once signed or submitted. In an agent skill context, omission of such warnings increases the chance that downstream automation treats these endpoints as routine data fetches, which can cause unintended listings, purchases, or approvals.

Missing User Warnings

Low

• Confidence: 82% confidence
• Finding: The authentication section shows how to supply API keys and Bearer tokens but does not warn that these credentials are sensitive and must not be logged, embedded in prompts, or exposed to untrusted tools. In an agent-driven environment, such omissions can lead to credential leakage through transcripts, debug output, or third-party integrations, enabling unauthorized API access within the token's scope.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: This reference gives concrete workflows for buying, selling, fulfilling, and canceling NFT orders, including signing and submitting returned transaction data, but it does not prominently warn that these actions can irreversibly transfer funds, NFTs, approvals, or trigger on-chain transactions with gas costs. In a wallet-integrated agent context, users may follow these steps or allow automation without fully appreciating that fulfillment and approvals can cause permanent asset movement, especially across ERC20 approvals and Seaport order execution flows.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This section gives copy-pastable instructions for signing and broadcasting a live Seaport purchase transaction but does not explicitly warn that the action spends funds and may irreversibly transfer assets on-chain. In an agent-skill context, omission of a transactional safety warning increases the chance that a user or automated agent executes a real purchase without confirming price, token, chain, recipient, and contract details.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The offer-acceptance instructions tell the user to fulfill an offer without warning that doing so transfers ownership of the NFT and cannot be undone once mined. Because this is operational guidance for marketplace execution, the missing warning can directly contribute to accidental asset loss if a user or agent accepts the wrong offer or misunderstands the effect.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The skill provides direct swap execution commands and a helper script without an explicit warning that executing them will submit an on-chain transaction and can irreversibly move assets. In an agent-driven context, this omission increases the chance that a user or downstream agent treats the action as routine automation rather than a high-risk financial operation, leading to unintended token loss, bad routes, wrong recipients, or execution under unfavorable slippage.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The documentation presents `opensea swaps execute` as a recommended path and states it will sign via a Privy-managed wallet, but it does not prominently warn that this submits real on-chain transactions and can move funds immediately. In an agent-skill context, concise copy-pasteable commands without an explicit transactional risk warning increase the chance of accidental fund movement by users or automated agents.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This script performs an on-chain token swap immediately via `opensea swaps execute` with no interactive confirmation, dry-run summary, or explicit opt-in flag. In the context of an agent skill that can be invoked programmatically, this increases the risk of accidental or prompt-induced trades, especially because swaps are financially destructive and generally irreversible once signed and submitted.

Missing User Warnings

Medium

• Confidence: 86% confidence
• Finding: The skill demonstrates setting a raw PRIVATE_KEY in shell commands for wallet-backed registration and tool invocation, but does not pair those examples with explicit handling warnings. In a developer-facing skill, this can normalize insecure secret practices such as shell history leakage, accidental logging, copy/paste into shared terminals, or storing hot keys in plaintext environment files.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The usage-reporting section states that successful calls forward verified caller identity and, for EIP-3009-authenticated calls, the caller's signed authorization to OpenSea's analytics endpoint. Even if intended for legitimate analytics, transmitting identity-linked authorization artifacts to a third party without a prominent privacy warning can surprise operators and create privacy, retention, and compliance risk.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation tells users to supply a raw PRIVATE_KEY directly as an environment variable in a shell command, but gives no warning about secret handling, shell history, process inspection, CI log leakage, or use of safer wallet injection methods. In a developer-facing skill that directly signs blockchain authorizations, this can lead to credential exposure and wallet compromise if copied into insecure environments.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This second CLI example repeats the same unsafe pattern of encouraging raw PRIVATE_KEY use without any safety guidance. Because this skill concerns authenticated payment and gating flows, exposed keys would let an attacker impersonate the caller and authorize onchain actions or payments.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The package description explicitly advertises wallet setup, NFT trading, and ERC20 token swaps, which are financially impactful operations, but it provides no warning that using the skill may trigger signing, token movement, approvals, or market transactions. In an agent-skill context, that omission increases the risk that users or upstream orchestrators invoke high-risk capabilities without appropriate consent gating or risk awareness.

Session Persistence

Medium

• Category: Rogue Agent

Content

1. **Check the environment first.** If `OPENSEA_API_KEY` is already set and
   non-empty, use it as-is. This is the path for users who supply their own key
   — never overwrite or re-fetch it.
2. **Check disk next.** If no env var, look for a cached key at
   `~/.opensea/api_key` (override the dir with `$OPENSEA_CONFIG_DIR`). If the
   file exists and is non-empty, load it into `OPENSEA_API_KEY` and use it.

• Confidence: 84% confidence
• Finding: The skill instructs caching an API key on disk and reloading it across sessions, which is a form of credential persistence. Even with mode 600, persisted tokens increase exposure to local compromise, accidental inclusion in backups, or misuse by other local processes, especially in shared or ephemeral agent environments.

Session Persistence

Medium

• Category: Rogue Agent

Content

export OPENSEA_API_KEY=$(cat "$KEY_FILE")      # 2. reuse cached key
else
  api_key=$(curl -s -X POST https://api.opensea.io/api/v2/auth/keys | jq -r '.api_key')  # 3. fetch
  mkdir -p "$(dirname "$KEY_FILE")"
  (umask 077; printf '%s\n' "$api_key" > "$KEY_FILE")  # 4. SAVE before using it
  export OPENSEA_API_KEY="$api_key"
fi

• Confidence: 89% confidence
• Finding: The example explicitly writes the fetched API key to disk before use, creating a reusable bearer credential on the local filesystem. Persisting secrets in plain files, even with restrictive permissions, can be risky in CI runners, containers, multi-user systems, or environments with aggressive log/backup tooling.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

| Task | CLI Command | Alternative |
|---|---|---|
| Declare self an agent | `opensea agent declare` | `opensea api request PUT /api/v2/accounts/agent` |
| Withdraw the declaration | `opensea agent withdraw` | `opensea api request DELETE /api/v2/accounts/agent` |
| Propose a relationship | `opensea agent propose <address> --role AGENT\|OWNER` | `opensea api request POST /api/v2/accounts/agent-relationships --body propose.json` |
| Confirm a proposal | `opensea agent confirm <address> --role AGENT\|OWNER` | `opensea api request POST /api/v2/accounts/agent-relationships/confirm --body confirm.json` |
| Withdraw or revoke | `opensea agent revoke <address> --role AGENT\|OWNER` | `opensea api request DELETE /api/v2/accounts/agent-relationships --params '{"counterparty_address":"0x...","caller_role":"AGENT"}'` |

• Confidence: 92% confidence
• Finding: The documented `DELETE /api/v2/accounts/agent` operation is a state-changing endpoint that withdraws an agent declaration. In an agent-executed context, exposing destructive parameters and direct request patterns without stronger guardrails can enable unauthorized or unintended identity-state changes, especially if prompts are ambiguous or maliciously crafted.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

| Withdraw the declaration | `opensea agent withdraw` | `opensea api request DELETE /api/v2/accounts/agent` |
| Propose a relationship | `opensea agent propose <address> --role AGENT\|OWNER` | `opensea api request POST /api/v2/accounts/agent-relationships --body propose.json` |
| Confirm a proposal | `opensea agent confirm <address> --role AGENT\|OWNER` | `opensea api request POST /api/v2/accounts/agent-relationships/confirm --body confirm.json` |
| Withdraw or revoke | `opensea agent revoke <address> --role AGENT\|OWNER` | `opensea api request DELETE /api/v2/accounts/agent-relationships --params '{"counterparty_address":"0x...","caller_role":"AGENT"}'` |
| List your own relationships | `opensea agent list` | `opensea api request GET /api/v2/accounts/agent-relationships` |
| Read a public profile | `opensea agent profile <address_or_username>` | `opensea-agent-relationships.sh <address_or_username>` |

• Confidence: 94% confidence
• Finding: The `DELETE /api/v2/accounts/agent-relationships` example allows revoking persisted relationships based on caller-supplied parameters. In a tool-driven environment, parameterized destructive actions are prone to abuse through prompt injection, mistaken identity, or incorrect role/address selection, potentially severing public ownership relationships unintentionally.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: opensea-api/references/authentication.md:45