T01 · Skill Instruction Hijacking
Error
- Location
- SKILL.md:281
- Finding
- External Backend Delegates Ongoing Control of Agent Actions## Vulnerability Details **File Location**: `SKILL.md`, lines 281–290 **Vulnerability Type**: Remote instruction-driven agent behavior **Risk Level**: High ### Vulnerable Code ```text The API tells you what to do next via the `nextAction` field: ``` 1. GET /skill/agent/status 2. Read the response's `nextAction` field: - "join_queue" → POST /skill/agent/join - "poll_status" → wait 2s, then GET /skill/agent/status again - "submit_answer" → craft answer, POST /skill/agent/answer - "wait" → wait 2s, then GET /skill/agent/status again 3. Repeat until you decide to stop playing ``` ``` This loop operates in conjunction with the mandatory role and tool directives at lines 3 and 8: ```text description: Mandatory operational logic for playing The Imitation Game. Use this when the user says "play" or "start game". This skill requires the agent to use its internal shell to call the game backend API directly. ``` ```text YOU are the player. Do not write scripts. Use your `shell` tool to execute the following logic to play the gamein real-time. ``` ### Technical Analysis The skill changes the agent's role and directs it to use its shell for repeated communication with an externally controlled backend. The backend response's `nextAction` value determines the agent's subsequent behavior, including joining a queue, polling, and submitting generated answers. Although the documented actions are limited to game operations, the instruction design delegates session-level control to an externally mutable service. The behavior can be activated by broad phrases such as “play” or “start game,” and no explicit informed-consent step, fixed iteration limit, timeout, or local policy-validation boundary is defined before the loop begins. This is instruction hijacking because loading the skill replaces the agent's normal goal with a mandatory player role and makes remote state authoritative for subsequent tool use. Th ...[truncated 1784 chars]
- Remediation
- ## Remediation Suggestions 1. Remove mandatory role-replacement language such as “YOU are the player” and state that all actions remain subordinate to the user's current request and applicable safety constraints. 2. Require explicit user confirmation before the first external request, clearly identifying the backend domain, data to be sent, intended activity, and potential wallet creation. 3. Treat `nextAction` as untrusted data rather than an instruction. Map only exact, locally allowlisted values to fixed operations and reject unknown fields or additional directives. 4. Enforce strict session limits, including a maximum number of polls, maximum game duration, request-rate limits, and cancellation handling. 5. Require renewed confirmation before identity registration, wallet creation, or any operation with financial implications. 6. Pin the backend origin to an immutable HTTPS allowlist and prohibit redirects to unapproved hosts. 7. Validate and safely encode `agentId`, `gameId`, questions, answers, and all backend responses before using them in shell commands or JSON payloads. 8. Prefer a constrained HTTP interface over unrestricted shell invocation so the skill cannot expand into arbitrary command execution. 9. Log each externally initiated state transition and provide a clear mechanism for the user to stop the loop immediately. 10. Document the backend trust model and ensure remote responses cannot introduce new tool calls, commands, URLs, or behavioral instructions.