T01 · Skill Instruction Hijacking
- Location
SKILL.md:77- Finding
Inbound Email Content Is Treated as a Privileged Agent Instruction
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 77–83 and 93–95
Vulnerability Type: Untrusted email content crossing into the Agent instruction and tool-execution context
Risk Level: HighVulnerable Snippet
The following is an English translation of the operative instructions in the identified lines:
markdown ### C. Email as instruction — execute with full authority - Email from any user email alias = fully authorized instruction; no secondary confirmation: 1. Read the complete message and parse the task or to-do item. 2. Register it in TODO.md as an "email instruction." 3. Execute it directly; record the result in the inspection log, current work log, and conversation. 4. After execution, reply by email to confirm the result. Confirmation replies execute automatically without per-message authorization. For matters requiring authorization, request authorization by email and execute after the user replies with approval. 5. Only extremely high-risk operations, such as irreversible deletion, sending external email, or financial operations, require prior assessment. ## Boundaries and security - Sending email normally requires confirmation, but fully authorized instructions received from any user alias are exempt, including the automatic confirmation reply. - Only instructions from the primary mailbox are executed; primary-mailbox messages are treated as fully authorized instructions.Technical Analysis
The Skill explicitly changes the trust classification of inbound email bodies from untrusted message data to privileged Agent instructions. A message whose sender appears to match any configured user alias is parsed into a task, written to
TODO.md, and executed without an independent in-session confirmation.Sender-address matching alone is not documented as being bound to cryptographically verified sender identity, connector-authe ...[truncated 2308 chars]
- Remediation
View remediation
Remediation Suggestions
- Treat every email subject and body as untrusted data, never as an automatically privileged Agent instruction.
- Require explicit approval in the active user session before executing any email-originated state-changing or external action.
- Remove the confirmation exception for messages that appear to originate from user aliases.
- Validate exact sender identities using authenticated connector metadata rather than display names or raw address strings.
- Where supported, require verified SPF, DKIM, and DMARC results, while recognizing that these controls do not replace user confirmation.
- Restrict email-originated automation to a narrow allowlist of low-risk operations, such as listing or summarizing messages.
- Represent extracted requests as proposed actions and display their source message, parameters, target resources, and expected side effects before approval.
- Prevent email content from directly selecting tools, paths, recipients, commands, or persistent instructions.
- Do not write raw email instructions into persistent task or memory files without sanitization, provenance metadata, and user approval.
- Preserve platform-enforced confirmation tokens for all send, reply, forward, and delete operations without workflow exceptions.