Proxy Gateway
Security checks across malware telemetry and agentic risk
Overview
The proxy function is clearly described, but the hosted payment/account handling appears under-scoped enough that users should review it before trusting deposits or balances.
Use this only for non-sensitive public web access unless you self-host it. Be especially cautious with the hosted payment model: avoid depositing meaningful funds until the API-key model and on-chain deposit attribution are clearly fixed and independently verified.
VirusTotal
66/66 vendors flagged this skill as clean.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Deposits and balances may be credited incorrectly or abused, which is significant because the service uses custodial balances and charges users per request.
The verification function accepts an expected_user_id but the visible logic only checks for a Transfer event to the hosted wallet and returns the amount. It does not clearly bind the transaction to the claimed user, verify a per-user deposit address/memo, or verify the token contract in the shown code.
async def _verify_onchain_deposit(self, tx_hash: str, expected_user_id: str) -> Decimal: ... if to_address.lower() == self.settings.HOSTED_WALLET.lower(): ... amount = Decimal(int(log['data'], 16)) / Decimal(10**6) ... return amount
Before depositing funds, confirm the operator has fixed deposit attribution: verify the exact USDC contract, chain, recipient, sender or signed payment session, confirmations, amount, and a user-specific deposit identifier that cannot be claimed by another user.
Anyone who learns or guesses a paid user identifier might be able to consume that account’s proxy balance, depending on the server-side routing logic.
The paid-mode example tells users to use a user_id as the API key. If that identifier is not a high-entropy secret, it is a weak account boundary for spending a paid balance.
# Use your user_id as API Key after deposit
response = requests.post(
"https://proxy.easky.cn/api/v1/fetch",
headers={"X-API-Key": "my_agent_001"},Use a generated, high-entropy API key separate from the public user ID, declare it as a credential in metadata, and document rotation/revocation.
An agent using this skill can send requests to many external sites and APIs, including POST-like actions, if the user or agent supplies those request details.
The proxy can make user-specified HTTP requests with arbitrary method, URL, headers, and body. This is central to the advertised proxy purpose, but it is a broad agent capability.
response = await client.request(
method=method.upper(),
url=url,
headers=request_headers,
content=body
)Use it only for intended public web/API retrieval, and require explicit user approval before sending credentials, non-public data, or state-changing requests.
Anything sent through the hosted proxy may be visible to the service operator, including headers, prompts, API parameters, and returned content.
The skill clearly discloses that the hosted proxy operator can see full request and response data.
All requests transit through the proxy server, including: - Full request URLs - All HTTP headers - Request bodies - Response content
Do not route API keys, passwords, private data, internal endpoints, or confidential business data through the hosted service; self-host if sensitive use is required.
Deposited funds are not fully under the user’s control while held by the platform.
The hosted payment model requires trusting the platform operator with user funds. This is disclosed and purpose-aligned, but it is still a meaningful permission and trust boundary.
| **Custody Risk** | User funds are held in platform-controlled wallets | Use small amounts, withdraw frequently |
Deposit only small amounts you can afford to lose, monitor balances, and prefer self-hosting or non-custodial payment flows for higher-value use.
Users relying only on registry metadata may miss required configuration and credential-handling steps for self-hosting.
The documentation lists required self-hosting configuration such as ADMIN_TOKEN, while the registry metadata says required env vars and primary credential are none. This looks like a metadata/declaration gap rather than hidden behavior.
ADMIN_TOKEN | Yes | - | Admin authentication token
Update skill metadata to declare self-hosting environment variables, credential expectations, and setup requirements.
Users may over-trust the hosted proxy or payment system because of audit wording.
The skill makes strong security-audit claims. The artifacts include security documentation, but users should still treat these as publisher claims unless independent audit evidence is available.
6 security audits completed, 13 critical vulnerabilities fixed. Self-hosting supported.
Review the code and any independent audit reports before sending sensitive traffic or depositing meaningful funds.