Agentdevx Skill

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:22 AM UTC
• Version: 1.1.0

Overview

This skill openly uses a third-party gateway for setup, API calls, credentials, and memory, but its automatic account creation and broad credential handling need review before installation.

Review this before installing if you are not comfortable with an agent automatically creating an account with AgentDevX and routing API requests, credentials, and persistent memory through that service. Only use it with data and API keys you are willing to expose to that gateway's trust boundary, and verify token scope, revocation, retention, and credential isolation outside the skill text.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:35
• Finding: Autonomous Third-Party Registration and Bearer Token Provisioning<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:35-46, 61-69` **Vulnerability Type**: Autonomous external account creation and credential provisioning **Risk Level**: High ### Vulnerable Code ```markdown ## Transparency — What Happens On First Use This skill connects to **AgentDevX**, a third-party hosted gateway. On first tool call, your agent automatically: 1. **Generates an Ed25519 keypair locally** — private key never leaves your machine 2. **Registers with AgentDevX** (`POST /agents/v1/bootstrap`) — outbound network call to `https://agentdevx.onrender.com` 3. **Receives a JWT + 75,000 free credits** — account created automatically 4. **Gains proxy access to any registered API** — pre-built examples include weather, GitHub, exchange rates, and more. Register your own via OpenAPI spec. This is intentional self-provisioning, not a bug. If you do not want your agent registering with a third-party service, do not invoke this skill's tools. ``` ```bash PUBLIC_KEY=$(openssl rand -hex 32) BOOTSTRAP=$(curl -s -X POST https://agentdevx.onrender.com/agents/v1/bootstrap \ -H "Content-Type: application/json" \ -d "{\"name\":\"openclaw-agent\",\"email\":\"agent@local\",\"public_key\":\"$PUBLIC_KEY\"}") export AGENTDEVX_API_KEY=$(echo "$BOOTSTRAP" | grep -o '"access_token":"[^"]*"' | cut -d'"' -f4) ``` ### Technical Analysis The documented workflow automatically creates an account with an externally controlled service and obtains a bearer token when the skill is first used. The token is exported into the agent process as `AGENTDEVX_API_KEY`, after which the third-party gateway can mediate subsequent operations. Although the document discloses this behavior, the workflow does not require explicit, operation-specific user approval before external registration. It also does not demonstrate token scoping, expiration, audience restriction, secure local storage, or binding of the token to a verified cryptographic key. This grants the external gatewa ...[truncated 1187 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require explicit, informed user confirmation before sending the bootstrap request. - Display the destination, transmitted registration fields, requested privileges, and applicable retention policy before consent. - Issue narrowly scoped, short-lived tokens with explicit audiences and revocation support. - Do not retain bearer tokens in broadly inherited environment variables; use a protected operating-system credential store. - Bind issued credentials to a cryptographically verified client key through a challenge-response protocol. - Provide an offline or manually configured mode that does not automatically create an external account. - Ensure invocation of unrelated or read-only tools cannot silently trigger enrollment. - Document exact token permissions, expiration behavior, revocation procedures, and consequences of gateway compromise. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:125
• Finding: Centralized Third-Party Handling of API Credentials, Requests, and Persistent Memory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:75-79, 84-97, 108-111, 125-127` **Vulnerability Type**: Excessive external trust and sensitive-data exposure **Risk Level**: High ### Vulnerable Code ```markdown - **Encrypted credential vault** — AES-256-GCM. Store API keys securely, auto-injected on every call. - **Access to any registered API** — 7 pre-built examples included. Register any API via OpenAPI spec and agents can use it instantly. - **Per-agent memory** — encrypted state that persists across sessions. - **Policy engine** — OPA/Rego access control. Dry-run mode. Full audit log. ``` ```markdown AgentDevX is not a fixed tool collection. Register any API via OpenAPI spec and it becomes instantly available to all agents with automatic credential injection, rate limiting, and audit logging. ``` ```markdown | Tool | What It Does | |------|-------------| | memory.store | Save a key-value pair to persistent, encrypted agent memory | | memory.recall | Retrieve a stored value by key | | webscrape.scrape | Extract page title, headings, links, images, text (static HTML) | | webscrape.extractDesign | Extract colors, fonts, spacing, layout patterns (static HTML) ``` ```markdown > ⚠️ **Trust Boundary:** AgentDevX is a third-party hosted gateway. API calls, credentials, and memory contents route through AgentDevX servers. All credentials encrypted at rest with AES-256-GCM. All traffic encrypted via TLS. Full audit log of every action, viewable via the AgentDevX dashboard. ``` ### Technical Analysis The skill routes API requests, credentials, and persistent memory through a single third-party gateway. AES-256-GCM encryption at rest and TLS in transit do not establish end-to-end confidentiality from the gateway itself. Automatic credential injection generally requires the service to access credentials, or equivalent usable secret material, while processing requests. Persistent memory increases the exposure window across sessions. The documentati ...[truncated 1727 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Apply client-side encryption using keys controlled by the user where gateway-side plaintext access is unnecessary. - Prohibit secrets, authentication tokens, and sensitive personal data from being stored in general-purpose agent memory. - Require confirmation before forwarding sensitive request bodies, credentials, or memory values to the gateway. - Bind each credential to an explicit destination host, API, operation set, and tenant. - Use short-lived delegated credentials instead of storing long-lived API keys whenever supported. - Enforce strict tenant isolation and private-by-default API registration; do not publish newly registered APIs to all agents automatically. - Define and enforce deletion, retention, backup, incident-response, and cryptographic key-rotation policies. - Add controls to redact secrets from logs and prevent credentials from being returned through memory or audit interfaces. - Clearly document whether service operators can decrypt credentials and memory, and independently verify the advertised security controls. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:61
• Finding: Documented Bootstrap Does Not Generate the Claimed Ed25519 Keypair<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:61-69` **Vulnerability Type**: Incorrect cryptographic identity implementation **Risk Level**: Medium ### Vulnerable Code ```bash PUBLIC_KEY=$(openssl rand -hex 32) BOOTSTRAP=$(curl -s -X POST https://agentdevx.onrender.com/agents/v1/bootstrap \ -H "Content-Type: application/json" \ -d "{\"name\":\"openclaw-agent\",\"email\":\"agent@local\",\"public_key\":\"$PUBLIC_KEY\"}") export AGENTDEVX_API_KEY=$(echo "$BOOTSTRAP" | grep -o '"access_token":"[^"]*"' | cut -d'"' -f4) ``` This conflicts with the documented claim: ```markdown 1. **Generates an Ed25519 keypair locally** — private key never leaves your machine ``` ### Technical Analysis `openssl rand -hex 32` generates 32 random bytes represented as hexadecimal. It does not generate an Ed25519 private key, derive an Ed25519 public key, or retain a private key capable of signing challenges. The command labels those random bytes as `PUBLIC_KEY` and sends them to the bootstrap endpoint. The documented flow contains no proof-of-possession step and no signature generated by a corresponding private key. Consequently, the shown procedure does not establish the claimed Ed25519 identity. Authentication in this example appears to depend solely on the bearer token returned by the server. This mismatch can cause users and downstream systems to rely on cryptographic identity properties that the documented implementation does not provide. ### Attack Path 1. The bootstrap script generates arbitrary random bytes with `openssl rand`. 2. Those bytes are submitted to the service as a purported public key. 3. No corresponding private key is created or retained. 4. No signed server challenge proves possession of an Ed25519 private key. 5. The service returns a bearer token that is extracted and used for authentication. 6. If identity decisions rely only on possession of that token, theft of the token may allow impersonation without defeating any Ed25519 proo ...[truncated 477 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Generate a real Ed25519 keypair using a supported cryptographic API or a correct OpenSSL command. - Store the private key in a protected keychain, hardware-backed keystore, or file with restrictive permissions. - Serialize and transmit only the correctly derived public key in a standard format. - Require the client to sign a fresh, server-generated nonce before issuing an access token. - Verify the signature, nonce freshness, expected algorithm, and public-key encoding on the server. - Bind issued tokens to the verified key and require proof of possession for sensitive operations. - Add automated tests that reject arbitrary random bytes, malformed keys, and bootstrap attempts without a valid signature. - Correct the documentation so that its security claims precisely match the implemented identity flow. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
PUBLIC_KEY=$(openssl rand -hex 32)
BOOTSTRAP=$(curl -s -X POST https://agentdevx.onrender.com/agents/v1/bootstrap \
  -H "Content-Type: application/json" \
  -d "{\"name\":\"openclaw-agent\",\"email\":\"agent@local\",\"public_key\":\"$PUBLIC_KEY\"}")
export AGENTDEVX_API_KEY=$(echo "$BOOTSTRAP" | grep -o '"access_token":"[^"]*"' | cut -d'"' -f4)

• Confidence: 95% confidence
• Finding: The skill explicitly instructs the agent to make an outbound POST request to a third-party service to self-register and obtain an access token automatically. Even though the behavior is disclosed, this still expands the trust boundary by transmitting agent metadata and establishing credentials with an external service without human review, which is risky in an autonomous skill context.

Static analysis

No suspicious patterns detected.