T01 · Skill Instruction Hijacking
- Location
SKILL.md:213- Finding
Untrusted Monday.com Content Is Propagated as Agent Instructions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is not clearly malicious, but it gives an agent broad recurring authority to act, delegate, and message people from Monday.com task content without enough boundaries.
Review before installing. Use a least-privilege Monday token limited to the intended board, avoid automatic cron execution until you add approval gates, restrict who the agent may message, and treat Monday item text as untrusted task data rather than instructions. The helper script should be hardened before relying on it for writes.
SKILL.md:213Untrusted Monday.com Content Is Propagated as Agent Instructions
scripts/monday-api.sh:27Unsafe GraphQL and JSON Construction Allows Injection and Request Corruption
The README expands the skill from Monday.com accountability management into broad autonomous action: executing work, making config changes, invoking coding agents, and sending messages. That creates a scope mismatch where operators may install a seemingly board-management skill that in practice authorizes much wider and potentially dangerous behavior, increasing the chance of unauthorized actions on code, systems, or communications.
The README specifically instructs the agent to write code, delegate to other agents, and send messages, none of which are justified by the declared accountability-board role. In agent ecosystems, such instructions can be operationalized as authority, enabling lateral actions beyond the expected trust boundary and creating risk of unintended code changes or unsolicited external communication.
The skill's declared purpose understates important behavior, especially local credential access from ~/.openclaw/.env and broader operational actions beyond simple board management. Description-behavior mismatches are dangerous because they defeat informed consent and make reviewers and users underestimate what the skill can access or trigger.
The activation text is broad enough to trigger on vague phrases like being 'accountable for X' or general status questions, increasing the chance the skill runs in contexts the user did not intend. With this skill's expansive instructions, overbroad triggering materially raises the risk of autonomous actions, messaging, or work execution being initiated from ambiguous prompts.
These instructions expand the skill from board tracking into arbitrary non-Monday task execution, code orchestration, and contacting other people. In context, that scope expansion is especially risky because the skill can pivot from passive project tracking into autonomous real-world actions without a clear per-action approval boundary.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# MONDAY_COL_STATUS — column ID for status (default: color_mm0yr4nm)
set -euo pipefail
# Read token from env, then fallback to .env file
TOKEN="${MONDAY_API_TOKEN:-$(grep MONDAY_API_TOKEN ~/.openclaw/.env 2>/dev/null | cut -d= -f2 || echo '')}"
BOARD="${MONDAY_BOARD_ID:-}"
COL_LAST_CHECKED="${MONDAY_COL_LAST_CHECKED:-date_mm0y8p9j}"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# MONDAY_COL_STATUS — column ID for status (default: color_mm0yr4nm)
set -euo pipefail
# Read token from env, then fallback to .env file
TOKEN="${MONDAY_API_TOKEN:-$(grep MONDAY_API_TOKEN ~/.openclaw/.env 2>/dev/null | cut -d= -f2 || echo '')}"
BOARD="${MONDAY_BOARD_ID:-}"
COL_LAST_CHECKED="${MONDAY_COL_LAST_CHECKED:-date_mm0y8p9j}"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
API="https://api.monday.com/v2"
if [ -z "$TOKEN" ]; then
echo "Error: MONDAY_API_TOKEN not set and not found in ~/.openclaw/.env" >&2
exit 1
fi
The documentation emphasizes that the agent should do 'real work' rather than merely manage accountability status, which conflicts with the stated purpose of accountability-item management. This can cause downstream agents or users to interpret the skill as authorization to take substantive actions unrelated to board tracking, leading to unsafe overreach.
The README describes autonomous code/config changes and messaging without a prominent user warning, despite these being materially higher-risk than simple Monday board updates. Lack of disclosure undermines informed consent and can cause users to enable the skill without understanding that it may modify systems or contact others autonomously.
Encouraging the agent to spawn sub-agents and message people broadens the skill from project tracking into autonomous orchestration and outbound communications. Even if framed as a design principle, this can normalize unsafe behavior and lead an agent to act on third-party systems or contact humans without explicit consent.
The skill implicitly expects shell capability via the helper script and operational instructions, but it does not declare any explicit tool scope or permissions boundary. This makes the skill harder to review and can lead an agent runtime to execute broader local actions than users would reasonably expect from a Monday.com board-management skill.
The skill tells the agent to message people who can help, including people beyond the owner, without a strong user-facing warning or approval requirement. This is dangerous because it can cause unauthorized outreach, disclosure of project context, and social-engineering style escalation under the guise of unblocking work.
The daily summary requires outbound reporting to the owner, which is a messaging capability not clearly bounded by the declared skill purpose. Even if benign, unannounced reporting can leak sensitive project details or normalize autonomous communications the user did not explicitly authorize.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
BOARD="${MONDAY_BOARD_ID:-}"
COL_LAST_CHECKED="${MONDAY_COL_LAST_CHECKED:-date_mm0y8p9j}"
COL_STATUS="${MONDAY_COL_STATUS:-color_mm0yr4nm}"
API="https://api.monday.com/v2"
if [ -z "$TOKEN" ]; then
echo "Error: MONDAY_API_TOKEN not set and not found in ~/.openclaw/.env" >&2
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
BOARD="${MONDAY_BOARD_ID:-}"
COL_LAST_CHECKED="${MONDAY_COL_LAST_CHECKED:-date_mm0y8p9j}"
COL_STATUS="${MONDAY_COL_STATUS:-color_mm0yr4nm}"
API="https://api.monday.com/v2"
if [ -z "$TOKEN" ]; then
echo "Error: MONDAY_API_TOKEN not set and not found in ~/.openclaw/.env" >&2
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
fi
query() {
curl -s -X POST "$API" \
-H "Content-Type: application/json" \
-H "Authorization: $TOKEN" \
-d "{\"query\": \"$1\"}"
The example configuration sets the messaging timezone to Asia/Jerusalem, which imposes a locale-specific default in the natural-language documentation without explaining that users should choose their own locale. This can violate language/locale policy expectations when a specific locale is presented as the default behavior rather than an explicit user-selected option.
The credential setup explains how to obtain and use a Monday API token with board write access but does not warn users that the token is sensitive and grants modification capability. While common in setup docs, omission of token-handling guidance increases the chance of accidental exposure or over-privileged deployment.