T01 · Skill Instruction Hijacking
- Location
references/task-routing-rules.md:89- Finding
Hardcoded Third-Party Telegram Escalation Route
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill broadly matches agent management, but it hardcodes task escalation to a specific Telegram user and uses unsafe mock/placeholder scripts for registry, routing, and health decisions.
Review this carefully before installing. Do not use it in a workspace containing private prompts, code, credentials, or business data unless you remove the hardcoded Telegram recipient, disable external reporting by default, replace mock scripts with real validated discovery and authorization logic, and add explicit confirmation before any task content leaves the session.
references/task-routing-rules.md:89Hardcoded Third-Party Telegram Escalation Route
scripts/scan_agents.js:18Mock Agent Discovery Can Overwrite the Real Registry
scripts/can_assign.js:7Authorization Bypass Through Unauthenticated Main-Agent Identity
scripts/health_check.js:8Random Values Presented as Real Agent Health Measurements
scripts/log_analyzer.js:17Fixed Mock Logs Presented as Agent Performance Statistics
scripts/validate_registry.js:53Registry Validator Always Passes Hierarchy Checks
scripts/generate_card.js:7Generated Agent Cards Contain Fabricated Capabilities and Routing
scripts/setup_wizard.js:28Persistent Markdown Injection Through Setup Wizard Inputs
Referenced artifact was not completely inspected
1. **Discovery:** Always check `scan_agents.js` before assuming an agent exists.
Referenced artifact was not completely inspected
1. **Discovery:** Always check `scan_agents.js` before assuming an agent exists.
Referenced artifact was not completely inspected
1. **Discovery:** Always check `scan_agents.js` before assuming an agent exists.
Referenced artifact was not completely inspected
1. **Discovery:** Always check `scan_agents.js` before assuming an agent exists.
Referenced artifact was not completely inspected
| **Health** | `node scripts/health_check.js` |
Referenced artifact was not completely inspected
| **Health** | `node scripts/health_check.js` |
Referenced artifact was not completely inspected
| **Stats** | `node scripts/log_analyzer.js` |
Referenced artifact was not completely inspected
| **Stats** | `node scripts/log_analyzer.js` |
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.
|------|------|-------------|--------|
| 2026-01-31 | Create agents-manager skill | main | ✅ Completed |
| 2026-01-31 | Profile all available agents | main | ✅ Completed |
| 2026-01-31 | Update skill with routing fields | main | ✅ Completed |
---
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
### Core Rules
1. **Discovery:** Always check `scan_agents.js` before assuming an agent exists.
2. **Permission:** Never assign a task without checking `can_assign.js` or `agent-registry.md`.
3. **protocol:**
- IF `requires_approval` is FALSE -> Assign directly.
- IF `requires_approval` is TRUE -> Ask supervisor (Human or Agent).
This markdown file states that the agent can perform file operations and execute shell commands, but it does not include any user-facing warning about possible effects on user data or system integrity. For markdown files, the skill description should disclose behaviors that can modify files or run commands so users understand the risk before use.
The markdown enumerates tools for web access, browser control, node control including camera/screen/location, memory access, gateway control, and messaging, but provides no warning about privacy-sensitive access or external interactions. Because this file documents capabilities that could affect privacy or system integrity, it should clearly disclose those behaviors to users.
The development-task router relies on broad keywords like 'code', 'API', and 'bug fix', which can appear in ordinary conversation and cause tasks to be delegated or spawned without sufficient intent validation. In a routing skill, this increases the chance of misclassification, unnecessary agent invocation, and inappropriate exposure of user context to development-oriented agents.
Keywords such as 'research', 'analyze', 'study', 'find', and 'investigate' are extremely common and can match many benign requests, causing over-routing to research agents or spawning new sessions unnecessarily. Because this file defines core routing behavior, the ambiguity directly affects how user data and tasks are distributed across the agent system.
The communication matrix explicitly allows sending messages to a human over Telegram but does not warn that task details or summaries may leave the internal agent boundary. This creates a real risk of unintended disclosure of sensitive prompts, outputs, or metadata to an external channel without user awareness or consent.
The escalation flow sends direct Telegram notifications to a human as the next escalation step, with no privacy gate, consent check, or content-limiting rule. In an operational routing policy, this can systematically leak unresolved user requests or internal context outside the system whenever escalation occurs.
The reporting protocol instructs agents to send a summary to a human channel when reports_to.type === 'human', but it does not impose restrictions on what the summary may contain. That omission makes external disclosure part of the normal reporting path, increasing the likelihood of sensitive output being shared beyond the agent environment.
This is a real authorization flaw: the function claims to evaluate assignment permissions based on registry data, but it ignores targetId and unconditionally allows any assignment when sourceId is 'main'. If an attacker can cause operations to run under or claim the 'main' identity, they gain broad delegation capability that bypasses the documented access-control model.
The script advertises hierarchy integrity and circular dependency detection in its help text, but the implementation does not perform those checks. This creates a false sense of assurance: users may rely on the validator to approve malformed or dangerous registry data, allowing broken trust relationships or recursive reporting chains to pass unnoticed.
The comments explicitly state that validation is only simulated, yet the script still reports the registry structure as valid when no errors are returned. In a security-sensitive workflow, this is dangerous because it can silently bless invalid configurations and undermine any downstream controls that assume the registry was fully checked.
Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.
### Core Rules
1. **Discovery:** Always check `scan_agents.js` before assuming an agent exists.
2. **Permission:** Never assign a task without checking `can_assign.js` or `agent-registry.md`.
3. **protocol:**
- IF `requires_approval` is FALSE -> Assign directly.
- IF `requires_approval` is TRUE -> Ask supervisor (Human or Agent).
The example language: "tr,en" defines language support in a way that may steer implementations toward a fixed locale configuration without stating that the user can choose their preferred language. This can conflict with language/locale policy expectations when a skill or agent appears to impose language behavior without explicit opt-in.
The decision tree uses Turkish phrases such as "Kendin yapabilir misin?" and "Uygun agent var mı?" while the rest of the document is primarily in English. This imposes a language assumption without user opt-in or a stated region-specific justification.
No suspicious patterns detected.