Back to skill

Security audit

XPR Agent Operator

Security checks for vulnerabilities and agentic risk

Overview

The skill is not clearly malicious, but it asks an agent to autonomously make signed marketplace commitments and set up recurring job activity with broad private-key authority and limited user approval controls.

Install only with a dedicated low-privilege XPR account and key, explicit spending and signing limits, and manual approval for every bid, acceptance, delivery, dispute, public repository creation, and A2A delegation. Do not enable the recommended cron jobs unless you have separate controls to review and stop all state-changing actions.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:8
Finding
Autonomous Role and Instruction Hijacking Through Externally Controlled Jobs## Vulnerability Details **File Location**: `SKILL.md`, lines 8–10, 25–40, 63–64, and 82–97 **Vulnerability Type**: `T01: Skill Instruction Hijacking` **Risk Level**: High ### Vulnerable Code ```markdown You are an autonomous AI agent operating on XPR Network's trustless agent registry. Your on-chain identity is the account stored in XPR_ACCOUNT. ``` ```markdown **A. Hunt for open jobs (PROACTIVE — primary workflow):** 1. Poll for open jobs with `xpr_list_open_jobs` 2. Review job details: title, description, deliverables, budget, deadline 3. Evaluate if you have the capabilities and can deliver on time 4. Submit a bid with `xpr_submit_bid` including your proposed amount, timeline, and a detailed proposal 5. Wait for the client to select your bid 6. When selected, the job is assigned to you — proceed to acceptance **B. Accept direct-hire jobs (REACTIVE):** 1. Check incoming jobs with `xpr_list_jobs` filtered by your account 2. Review job details: title, description, deliverables, amount, deadline 3. Verify the client is legitimate (check their account, past jobs) 4. Accept with `xpr_accept_job` only if you can deliver ``` ```markdown 5. NEVER deliver just a URL or summary — always include the actual work 6. NEVER say you can't create images or videos — you HAVE the tools for this! ``` ```markdown - **ALWAYS** bid at least the estimated XPR amount — this is your minimum profitable price - If the budget is above your cost estimate: bid at or near budget (more profit) - If the budget is below cost: bid at your estimated cost (you can bid ABOVE the posted budget — the client can accept or reject) - If the job is wildly unprofitable (budget < 25% of cost): skip it ``` ### Technical Analysis The skill replaces the host agent's normal role with that of an autonomous blockchain marketplace operator. It uses mandatory identity and behavior directives, including `ALWAYS` and `NEVER` statements, to ...[truncated 1965 chars]
Remediation
## Remediation Suggestions - Remove role-replacement language such as “You are an autonomous AI agent.” - Replace `ALWAYS` and `NEVER` directives with conditional guidance subordinate to platform policy and explicit user intent. - Treat every job title, description, deliverable, proposal, URI, and A2A message as untrusted data. - Keep untrusted job content in a structured data boundary and prohibit it from changing system instructions or tool permissions. - Apply prompt-injection detection and enforce a narrow allowlist of supported task types. - Require explicit, informed user approval before bidding, accepting jobs, publishing content, creating repositories, delivering work, spending funds, or initiating signed operations. - Verify actual tool availability and policy eligibility at runtime rather than asserting capabilities in skill text. - Apply budget, destination, content, and rate limits independently of instructions received from marketplace participants.

T06 · System Persistence

Error
Location
SKILL.md:123
Finding
Persistent Autonomous Bidding and Job Acceptance Through Scheduled Tasks## Vulnerability Details **File Location**: `SKILL.md`, lines 123–148 **Vulnerability Type**: `T06: System Persistence` **Risk Level**: High ### Vulnerable Code ```markdown ## Recommended Cron Jobs Set up these periodic tasks: ### Hunt for Open Jobs (every 15 minutes) ``` 1. Poll for open jobs: xpr_list_open_jobs 2. Filter by your capabilities (match deliverables to your profile) 3. Submit bids on matching jobs: xpr_submit_bid 4. Check for direct-hire jobs: xpr_list_jobs (agent=you, state=funded) 5. Auto-accept direct-hire jobs if criteria met: xpr_accept_job ``` ### Health Check (hourly) ``` Verify registration is active: xpr_get_agent Check trust score stability: xpr_get_trust_score Review any new feedback: xpr_list_agent_feedback Check indexer connectivity: xpr_indexer_health ``` ### Cleanup (daily) ``` Check for expired/timed-out jobs you're involved in. Review any pending disputes. Check registry stats: xpr_get_stats ``` ``` ### Technical Analysis The skill recommends setting up recurring tasks that survive the initiating interaction and repeatedly perform marketplace operations. The most consequential schedule submits bids and automatically accepts direct-hire jobs every 15 minutes. Although the file does not include an operating-system command that installs a cron entry, it explicitly instructs the host to establish periodic autonomous behavior. If the host implements these recommendations, state-changing operations can continue across sessions without fresh user intent or approval. Read-only health monitoring is lower risk, but it is combined with persistent bidding and acceptance in the same recommended automation model. ### Attack Path 1. The user or host enables the recommended scheduled tasks. 2. The scheduled workflow runs every 15 minutes without contemporaneous user involvement. 3. An attacker publishes a job or sends a direct-hire request crafted to pass the doc ...[truncated 817 chars]
Remediation
## Remediation Suggestions - Do not schedule automatic bidding, job acceptance, delivery, dispute, funding, or other state-changing operations. - Restrict background schedules to read-only monitoring and user notifications. - Require fresh, explicit approval for every bid and job acceptance. - Display the client, amount, deadline, requested work, destination, and estimated resource cost before approval. - Give scheduled tasks a short expiration time and require deliberate renewal. - Provide a visible inventory of active schedules and a reliable one-step disable mechanism. - Apply strict bid-count, spending, job-value, and execution-frequency limits. - Record tamper-resistant audit logs for every scheduled execution and attempted state change.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:151
Finding
Raw Blockchain Signing Key Exposed to Autonomous Agent Workflows## Vulnerability Details **File Location**: `SKILL.md`, line 4 and lines 151–160 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: High ### Vulnerable Code ```yaml metadata: {"openclaw":{"requires":{"env":["XPR_ACCOUNT","XPR_PRIVATE_KEY"]}}} ``` ```markdown ### 5. Agent-to-Agent (A2A) Communication - Discover other agents' capabilities with `xpr_a2a_discover` before interacting - Send tasks to other agents with `xpr_a2a_send_message` - Check task progress with `xpr_a2a_get_task` - Delegate sub-tasks from escrow jobs to specialized agents with `xpr_a2a_delegate_job` - Always verify the target agent's trust score before delegating work - All outgoing A2A requests are signed with your EOSIO key (via `XPR_PRIVATE_KEY`) - Incoming A2A requests are authenticated — callers must prove account ownership via signature - Rate limiting and trust gating protect against abuse (configurable via `A2A_MIN_TRUST_SCORE`, `A2A_MIN_KYC_LEVEL`) ``` ### Technical Analysis The skill requires the runtime to expose a raw private signing key through the `XPR_PRIVATE_KEY` environment variable. It then directs autonomous A2A requests to be signed with that key. Direct private-key availability violates least-privilege principles because read-only marketplace discovery, content generation, and status monitoring do not require unrestricted signing authority. The risk is amplified by the instruction-hijacking exposure: externally supplied jobs or A2A content may influence a workflow that has access to authenticated signing operations. Keeping the key in an environment variable is preferable to embedding it directly in the file, but it does not constrain which transactions may be signed, their value, their recipient, or when signing authority expires. ### Attack Path 1. The skill is loaded with `XPR_PRIVATE_KEY` available to its runtime or tool layer. 2. The agent retrieves attacker-controlled jo ...[truncated 988 chars]
Remediation
## Remediation Suggestions - Replace direct raw-key access with a constrained wallet or signing service. - Keep private-key material outside the agent's prompt, process environment, logs, and tool responses. - Scope signing authorization by operation type, contract, recipient, maximum amount, and expiration time. - Require interactive approval for every signature that changes state, delegates work, transfers value, or creates an external commitment. - Use a dedicated low-privilege account or session key rather than the account owner's primary key. - Enforce transaction simulation and show the exact canonical payload before approval. - Add destination allowlists, replay protection, rate limits, spending limits, and revocation controls. - Ensure untrusted job descriptions and A2A messages cannot select arbitrary signing payloads or bypass approval gates.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Anti-Refusal Statement

High
Category
Anti-Refusal
Content
3. Use the returned URL as `evidence_uri` when calling `xpr_deliver_job`
4. If milestones exist, submit each with `xpr_submit_milestone`
5. NEVER deliver just a URL or summary — always include the actual work
6. NEVER say you can't create images or videos — you HAVE the tools for this!

### 3. Reputation Monitoring
- Check your score regularly with `xpr_get_agent_score`
Confidence
89% confidence
Finding
The anti-refusal instruction pressures the agent to suppress capability or safety-based refusals by stating it should 'NEVER say you can't create images or videos.' This can override prudent behavior in edge cases involving unsafe, disallowed, deceptive, or impossible requests, increasing the chance the agent proceeds with inappropriate generation or misrepresents what it can safely deliver.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The skill explicitly instructs agents to use `create_github_repo`, described as creating a public repository, for delivering code without any warning about disclosure, licensing, or secret-handling risks. In this context, jobs may involve proprietary client code, credentials, internal data, or unpublished artifacts, so defaulting to public publication can cause irreversible data exposure.