A2A SHIB Payment System

• Outcome: Review
• Latest audit: May 28, 2026, 12:12 PM
• Version:
  2.0.0

Overview

This is a real SHIB payment agent, but it exposes money-moving functionality with weak defaults and overstates its escrow safety guarantees.

Install only if you are prepared to treat this as experimental financial software. Use a low-value hot wallet, do not expose the default full agent to the internet, prefer the production agent only after rotating API keys and disabling console key printing, and do not rely on the advertised escrow as trustless on-chain custody without independent code changes and testing.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (48)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 86% confidence
• Finding: The skill metadata declares required binaries and installation steps but does not declare permissions despite documented and inferred access to environment secrets, network communication, and shell-like installation/execution behavior. In a payment skill that handles wallet private keys and starts a networked agent, this lack of explicit permission disclosure can mislead operators about the trust boundary and increase the chance of unsafe deployment.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 90% confidence
• Finding: A documented payment/escrow skill that also performs unrelated behaviors such as GitHub monitoring, Telegram messaging, Qdrant storage, and admin or audit wrapper tooling creates a significant transparency gap. Hidden or under-declared secondary capabilities are dangerous because they can enable data exfiltration, surveillance, or privileged administrative actions beyond what a user expects from a payment agent.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: This file embeds detailed social-media posting, outreach, and reputation-boosting instructions that are unrelated to the stated payment-system functionality. In an agent skill context, such instructions can cause an agent to perform unsolicited external actions, spam communities, or manipulate visibility metrics, expanding the skill beyond its declared scope and creating social-engineering and misuse risk.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: The checklist explicitly directs outreach campaigns, asks for GitHub stars, and targets social channels and awesome-list submissions, which are not justified by a payment-system skill. If exposed to an autonomous or semi-autonomous agent, this could be interpreted as permission to contact third parties, generate promotional content, and influence platform metrics, creating abuse, trust, and policy-compliance issues.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: This file documents automation for GitHub pull request handling, cron-based repository monitoring, and Telegram notifications, which are materially unrelated to the declared skill purpose of SHIB payments, escrow, negotiation, and reputation. In an agent skill context, unexplained extra capabilities expand operational scope and can enable data exfiltration, unintended repository surveillance, or privileged workflow actions beyond what a user would reasonably expect from a payments skill.

Context-Inappropriate Capability

Medium

• Confidence: 93% confidence
• Finding: The documented cron job that monitors GitHub pull requests every 10 minutes and sends detailed Telegram alerts introduces continuous outbound data sharing and monitoring behavior not justified by the payment-system mission. Because this capability bridges repository metadata to an external messaging platform, it creates a covert or at least unnecessary data-transfer path that increases risk if enabled in an agent environment.

Description-Behavior Mismatch

Medium

• Confidence: 86% confidence
• Finding: This document shows the skill encompasses marketing, launch, and community-growth operations that are materially broader than the declared purpose of an A2A payment system. Scope expansion like this is dangerous in agent settings because operators may grant payment-related trust to a skill that also drives unsolicited external actions, messaging, or promotion workflows they did not expect.

Context-Inappropriate Capability

Medium

• Confidence: 89% confidence
• Finding: The file explicitly includes promotion and community-growth tasks such as social posting, star campaigns, awesome-list submissions, and community engagement, which are unrelated to core payment processing. In an agent environment, these extra capabilities increase the risk of unauthorized external communications, reputation abuse, spam, or social-engineering actions under the cover of a trusted financial skill.

Context-Inappropriate Capability

Low

• Confidence: 82% confidence
• Finding: Telegram notifications and external submission activities are context-inappropriate for a payment-system skill and indicate the skill may trigger outbound communications beyond user expectations. While this looks more like poor scope hygiene than overt maliciousness, such behavior can still cause information leakage, spam, or unintended third-party interactions if wired into an autonomous agent workflow.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The README makes a materially misleading security claim: it says escrows are stored on-chain, then immediately concedes they are in memory. For a payment/escrow system, this can cause operators and users to trust crash-resistance, trustlessness, and fund-safety properties that may not actually exist, leading to loss of funds, failed dispute handling, or broken escrow guarantees.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The document materially overstates the implemented capabilities by implying trustless escrow, price negotiation, and reputation features, while the content only demonstrates direct token transfers and balance checks. This can mislead users or integrators into relying on protections that do not actually exist, increasing the chance of unsafe deployment, fund loss, or incorrect trust assumptions.

Description-Behavior Mismatch

Medium

• Confidence: 84% confidence
• Finding: The skill is presented as an agent-to-agent payment system, but the actual interface is a free-form unauthenticated text command endpoint that interprets natural-language-like payment requests. In a wallet-backed payment context, this increases the risk of accidental or automated misuse because there is no strong protocol-level authorization, schema validation, or trust boundary enforcement.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: Both JSON-RPC and REST handlers are registered with UserBuilder.noAuthentication while the service can invoke shibAgent.sendPayment using a configured wallet. That means any reachable caller can request irreversible blockchain transfers from the agent's wallet, which is effectively an unauthorized payment API.

Description-Behavior Mismatch

High

• Confidence: 99% confidence
• Finding: The file presents itself as a trustless SHIB escrow system, but it only mutates local JSON state and accepts an arbitrary txHash without validating or executing any blockchain payment. In the context of financial/escrow software, this is highly dangerous because users or agents may rely on the escrow state as proof that funds are secured when no on-chain custody or verification exists.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: resolveDispute() claims to perform arbiter resolution, but it calls release() and refund(), both of which reject escrows in the 'disputed' state. This creates a broken dispute path that can leave disputed escrows unresolved indefinitely, undermining the safety guarantees of the payment workflow and enabling denial of service over funds/state progression.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: The skill description advertises escrow, price negotiation, and reputation capabilities, but the implementation only performs direct SHIB balance queries and irreversible token transfers. This mismatch can mislead users or higher-level agents into trusting safety properties that do not exist, increasing the chance of sending funds without expected protections.

Context-Inappropriate Capability

Medium

• Confidence: 91% confidence
• Finding: The skill reads secrets from ~/.env.local and uses a private key to create a signing wallet, which is a sensitive capability. In an agent-skill context, local credential access is dangerous because it expands the trust boundary from payment logic to host secret handling, and can enable unauthorized spending if invoked without strong user controls.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: This script performs GitHub repository surveillance and external alerting, which is unrelated to the stated SHIB payment and escrow functionality of the skill. In a security review, this mismatch is important because unrelated monitoring code can create hidden data flows, expand permissions needed by the skill, and provide a covert notification channel that could be repurposed for exfiltration or operator tracking.

Context-Inappropriate Capability

Medium

• Confidence: 98% confidence
• Finding: The script sends repository activity details to an external Telegram recipient via `openclaw message send` without any indication that users of the payment skill expect or authorize such outbound messaging. Hardcoded external messaging introduces a direct exfiltration path and can leak internal repository activity, contributor identities, or operational metadata to a third party.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The guide recommends exposing the agent publicly via Cloudflare Tunnel and presents internet accessibility as a production path without a prominent warning that this materially increases attack surface. Because this is a payment/escrow agent, public exposure can enable probing of JSON-RPC endpoints, auth weaknesses, and abuse of wallet-linked functionality if operators follow the guide as-is.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The VPS setup instructs the user to place a blockchain private key into .env.local with only a brief note, not a strong adjacent warning about the sensitivity of the credential or safer alternatives. In a payment agent, compromise of that key can directly lead to theft of funds, unauthorized transactions, or irreversible on-chain actions.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The guide promotes automatic payment release and auto-refund flows for a payment/escrow system without prominently warning that these actions may trigger irreversible on-chain fund movements and persistent transaction/state records. In a financial agent context, omission of such warnings can lead operators to enable unsafe automation, misunderstand finality, and accidentally release or refund funds based on incomplete or spoofed conditions.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The document provides executable payment and escrow commands such as sending SHIB and approving or funding escrow without any adjacent warning that these actions can move real funds or release escrowed assets irreversibly. In a payments skill, omission of transaction-risk warnings materially increases the chance of accidental financial loss by operators or downstream agents following the examples literally.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The usage section shows how to start the live agent and send commands over JSON-RPC, but it does not warn that some messages to this service may initiate real payment workflows depending on configuration. Because the skill is explicitly production-oriented and presents itself as 'fully operational' and 'production ready,' users may reasonably treat the examples as safe test steps when they are not.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The integration examples show agents creating escrows and sending SHIB without any warning that these actions can transfer funds or create irreversible on-chain commitments. In an agentic context, examples strongly influence downstream implementations, so omitting confirmation and risk language can normalize unsafe autonomous financial actions.

VirusTotal

65/65 vendors flagged this skill as clean.