IGA Pages

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:02 AM UTC
• Version: 1.0.6

Overview

The skill is mostly coherent for deploying to IGA Pages, but it asks agents to handle cloud credentials, mutable installs, local secret files, and deployment actions with scoping gaps users should review first.

Review before installing. Use this skill only when you intend to deploy with IGA Pages, prefer a pinned project-local CLI install, avoid pasting long-lived cloud secrets into chat or shell commands, confirm before production deploys or remote env changes, and only run env pull when you need local development secrets and .env.local is protected and gitignored.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:21

Finding

Mutable CLI Package Is Installed Globally Without Version Pinning

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:21-25; additional occurrence at references/functions.md:15-20
Vulnerability Type: Unsafe installation of an unpinned third-party dependency
Risk Level: Medium

The skill directs the agent to install the latest available release of the IGA Pages CLI globally:

bash

npm i -g @iga-pages/cli@latest

The functions documentation similarly recommends a global installation without an exact version:

bash

npm i -g @iga-pages/cli
iga pages dev

Technical Analysis

The package version is resolved dynamically from the npm registry at execution time. Consequently, the code installed and executed may differ from the code that existed when this skill was audited. The global installation also permits npm package lifecycle scripts to run under the invoking user's privileges and makes the installed executable available outside the audited project.

Although the package name is consistent throughout the documentation and there is no evidence that the current package is malicious, using @latest or omitting the version creates a supply-chain trust boundary that is not reproducible or integrity-verified. A compromised npm account, registry response, or future malicious release could introduce arbitrary install-time or runtime behavior.

Attack Path

1. An attacker compromises the npm publisher account, package distribution process, or another component of the package supply chain.
2. The attacker publishes a malicious release under @iga-pages/cli and makes it the latest version.
3. The agent follows the skill instructions and runs npm i -g @iga-pages/cli@latest or npm i -g @iga-pages/cli.
4. npm downloads the mutable release and may execute its lifecycle scripts during installation.
5. The installed global iga executable subsequently runs attacker-controlled code when the agent performs authentication, linking, environment management, or deploymen ...[truncated 762 chars]

Remediation

View remediation

Remediation Suggestions

• Pin the CLI to an exact, reviewed version rather than using @latest, for example:

  bash

  npm install --save-dev --save-exact @iga-pages/cli@1.1.0
  

• Prefer a project-local development dependency invoked through npm exec or an npm script instead of a global installation.
• Commit a lockfile and use npm ci so dependency resolution is reproducible.
• Verify package provenance and registry integrity before installation. Where supported, validate package signatures, attestations, and expected integrity hashes.
• Review version upgrades separately before changing the pinned version.
• Disable npm lifecycle scripts with --ignore-scripts when the CLI does not require them, or explicitly review all lifecycle scripts before allowing their execution.
• Update both SKILL.md and references/functions.md so they provide one consistent, pinned installation procedure.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:45

Finding

Access Key and Secret Key Are Passed Through Command-Line Arguments

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:45-48
Vulnerability Type: Sensitive credential exposure through process arguments and command history
Risk Level: Medium

The documented headless authentication method places both credentials directly in command-line arguments:

bash

iga login --accessKey <YOUR_AK> --secretKey <YOUR_SK>

Technical Analysis

Command-line arguments are not an appropriate secret transport mechanism on many operating systems and execution platforms. After placeholders are replaced with real values, the secret key may become visible through process inspection facilities, shell history, terminal capture, CI logs, command auditing, debugging output, or agent transcripts.

Masking input in the application cannot protect a secret that has already been included in the process argument vector. The exposure window exists from shell command construction through process termination, while historical or logged copies may persist indefinitely.

Attack Path

1. A user provides a real Volcengine access key and secret key for headless authentication.
2. The agent substitutes those credentials into the documented iga login command.
3. The shell records the command in history, the orchestration environment captures it in logs, or another local process reads the command arguments while iga is running.
4. An attacker with access to that history, log, transcript, audit record, or process-inspection interface extracts the credentials.
5. The attacker uses the AK/SK pair to authenticate to Volcengine APIs and perform operations permitted by the associated IAM identity.

Impact Assessment

Exploitation discloses long-lived cloud credentials rather than only a temporary browser session. The privileges obtained are those granted to the corresponding Volcengine IAM identity. Depending on its policies, an attacker could inspect or modify IGA Pages projects, access deployment-re ...[truncated 403 chars]

Remediation

View remediation

Remediation Suggestions

• Modify the CLI and documentation to accept the secret through hidden interactive input, standard input, or a restricted credential file rather than a command-line argument.
• Prefer integration with an operating-system credential manager or the platform's native secret store.
• In CI/CD environments, retrieve credentials from the CI secret manager and pass them through a protected input channel that does not echo or serialize their values.
• If environment variables are the only supported alternative, ensure they are injected by a secret manager, never printed, removed promptly, and unavailable to unrelated processes where the platform permits.
• Explicitly instruct users not to paste real AK/SK values into chat messages, shell history, source files, or deployment logs.
• Apply least-privilege IAM policies, use dedicated deployment identities, rotate keys regularly, and revoke credentials immediately if command logs or transcripts may have captured them.
• Add automatic redaction for access-key and secret-key patterns in agent output, terminal logging, and CI logs as defense in depth.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (9)

Credential Access

High

• Category: Privilege Escalation
• Confidence: 95% confidence

Finding

This guidance enables local retrieval of all project environment variables into .env.local, which is a classic credential-access pattern because it converts remotely managed secrets into plaintext local artifacts. In the context of a deployment skill that may operate on production projects, the secrets could include API keys, tokens, and service credentials with significant downstream impact if exfiltrated.

Content

Scanner excerpt · SKILL.md (reported line 101)May include surrounding context.

md

iga pages env add <NAME>           # add (--value <v> --yes for CI)
iga pages env update <NAME>        # update existing
iga pages env remove <NAME>        # remove (--yes to skip confirm)
iga pages env pull                 # write all project env to .env.local

## integrations (Supabase; linked project required)
iga pages integration list                  # bindings on this project

Credential Access

High

• Category: Privilege Escalation
• Confidence: 60% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · references/env.md (reported line 16)May include surrounding context.

iga pages env update --value --yes iga pages env remove # or: env rm — asks for confirmation iga pages env remove --yes # skip confirmation (required when no TTY) iga pages env pull # write all project env to local .env.local

text

Notes:

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 60% confidence

Finding

Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Content

Scanner excerpt · SKILL.md (reported line 3)May include surrounding context.

md

---
name: iga-pages
description: Deploy frontend and full-stack projects to IGA Pages. Use when the user mentions IGA Pages or requests deployment ("deploy my app", "publish this site", "push this live", "deploy and give me the link", "create a preview deployment", "deploy to IGA Pages", "ship to production"). Also use for API, endpoint, or backend-service work only when the user explicitly mentions IGA Pages, Pages Functions, or an existing IGA Pages project.
metadata:
  author: iga-pages
  version: "1.0.10"

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The trigger phrases are broad enough to activate the skill for generic deployment requests, which can cause the agent to select this skill outside a clearly intended IGA Pages context. That increases the chance of performing authentication, linking, or deployment-oriented actions in the wrong environment or for the wrong platform.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence

Finding

npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The documentation instructs use of iga pages env pull to write all remote environment variables into .env.local without warning that this materializes secrets on disk. In a deployment skill, that can expose credentials to local compromise, accidental backup/sync, or later leakage through tooling and user workflows.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 85% confidence

Finding

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.

Content

Scanner excerpt · references/env.md (reported line 15)May include surrounding context.

iga pages env update # change an existing variable's value iga pages env update --value --yes iga pages env remove # or: env rm — asks for confirmation iga pages env remove --yes # skip confirmation (required when no TTY) iga pages env pull # write all project env to local .env.local

text

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 77% confidence

Finding

The workflow authorizes the agent to continue deployment automatically when it finds an existing Supabase binding, 'without asking again.' That permits a consequential action (iga pages deploy) based on inferred project state rather than fresh user confirmation, which can cause unintended publication or use of linked resources if the user's intent was narrower than 'deploy now.'

Content

Scanner excerpt · references/integration.md (reported line 55)May include surrounding context.

md

1. Ensure logged in with `iga whoami`; only run `iga login` if `whoami` fails.
2. If the directory is not linked yet, run `iga pages link` to create/associate the Pages project (this no longer deploys). If it is already linked, continue without relinking.
3. Inspect the project for supported integrations. If Supabase usage is detected, run `iga pages integration list` first. If the required Supabase binding already exists, continue to deploy without asking again. If no matching binding exists, ask before deploying:
   > "This project appears to use Supabase, which IGA Pages can connect as an integration. Would you like to connect it before deploy?"
4. If yes (Supabase): run `iga pages integration link supabase`. The synced env vars take effect on the next deploy automatically.
5. `iga pages deploy`.

Skill Enumeration

Medium

• Category: Agent Snooping
• Confidence: 80% confidence

Finding

Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.

Content

Scanner excerpt · references/integration.md (reported line 64)May include surrounding context.

md

## Supabase provider work → hand off to `byted-supabase`

This skill only orchestrates link / integration / env / deploy. It does **not** manage Supabase resources (creating workspaces/branches, SQL, migrations, API keys, Storage, Edge Functions). When the user wants to create or manage actual Supabase resources, hand off to the `byted-supabase` skill (`https://github.com/bytedance/agentkit-samples/blob/main/skills/byted-supabase/SKILL.md`). After it finishes, return and confirm with the user before continuing link / integration / deploy — don't auto-continue.

Static analysis

No suspicious patterns detected.