InsForge Cli Skills

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:46 AM UTC
• Version: 1.0.0

Overview

This skill is coherent for managing InsForge projects, but it gives agents high-impact account, database, deployment, secrets, and skill-installation workflows with some under-scoped safety guidance.

Review this skill before installing in production or CI. Prefer OAuth or scoped tokens over password environment variables, avoid `-y` for destructive/admin actions unless the exact command is known, inspect what will be uploaded or exported, keep database dumps and `.insforge/project.json` out of logs/source control, and be cautious with `insforge create` because it can install additional agent skills through an unpinned remote `npx` command.

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: references/create.md:34
• Finding: Automatic Execution of an Unpinned Remote Dependency During Project Creation## Vulnerability Details **File Location**: `references/create.md`, lines 34-39 **Vulnerability Type**: Supply-chain exposure through unpinned remote package execution **Risk Level**: Medium ### Vulnerable Code ```text 1. Creates the project via the InsForge Platform API 2. Waits for the project to become active (polls every 3s, timeout 120s) 3. Fetches the project's API key 4. Downloads template files (if not `empty`) 5. Installs InsForge Agent Skills via `npx skills add insforge/agent-skills` 6. Creates `.insforge/project.json` in the current directory ``` ### Technical Analysis The documented project-creation workflow automatically invokes `npx` to retrieve and install `insforge/agent-skills`, but it does not pin the dependency to an exact version, immutable commit, or verified artifact digest. Consequently, the effective content installed by the command can change after this Skill has been reviewed. Automatically installing Agent skills is also broader than the minimum privileges and operations required to create and link an InsForge project. Because Agent skills can contain instructions or executable components, compromise of the upstream package, repository, release process, package resolution path, or maintainer account could introduce attacker-controlled behavior. The audit only establishes that this behavior is documented; the implementation of the external `insforge` CLI and the package retrieved by `npx` were not included in the audited project. ### Attack Path 1. An attacker compromises the remotely resolved package, its publishing account, its upstream repository, or the package-resolution infrastructure. 2. The attacker publishes modified content under the dependency name used by `npx`. 3. A user or Agent runs `insforge create`. 4. The CLI executes `npx skills add insforge/agent-skills` without selecting an immutable reviewed version. 5. The modified package is downloaded and processed with the pe ...[truncated 656 chars]
• Remediation: ## Remediation Suggestions 1. Remove automatic Agent-skill installation from the minimum project-creation workflow. 2. Require explicit user confirmation or a separate opt-in flag before downloading or installing additional skills. 3. Pin the package to an exact version or, preferably, an immutable commit or content digest. 4. Verify downloaded artifacts using a trusted checksum or cryptographic signature before installation. 5. Use a lockfile and a trusted package registry with strict namespace controls. 6. Disable package lifecycle scripts unless they are required and independently reviewed. 7. Display the source, selected version, integrity value, and destination directory before installation. 8. In CI/CD, run installation in an isolated, least-privileged environment without unrelated secrets.

T09 · Insecure Skill Coding Practices

Warning

• Location: references/deployments-deploy.md:146
• Finding: Deployment Guidance May Expose Secrets Through Public Frontend Environment Variables## Vulnerability Details **File Location**: `references/deployments-deploy.md`, lines 146-153 **Vulnerability Type**: Sensitive information exposure through client-visible build variables **Risk Level**: Medium ### Vulnerable Code ```text 1. **Exclude unnecessary files from zip** - Never include `node_modules`, `.git`, `.env`, `.insforge`, or build output - Large assets should go to InsForge Storage, not the deployment 2. **Pass sensitive values via envVars, not in code** - API keys, secrets should be in `envVars` array - Never commit `.env` files to source or include in zip - Use the correct env var prefix for your framework: `VITE_*`, `NEXT_PUBLIC_*`, `REACT_APP_*`, etc. ``` ### Technical Analysis The guidance recommends placing “API keys, secrets” in deployment environment variables while also directing users to framework prefixes such as `VITE_*`, `NEXT_PUBLIC_*`, and `REACT_APP_*`. These prefixes are conventionally intended for values exposed to browser-side application code. During a frontend build, variables using these prefixes can be embedded into generated JavaScript and other public assets. Excluding `.env` files from the uploaded archive does not prevent this exposure. If a secret is passed through the deployment interface and consumed through a public framework prefix, the build process can still place its value in publicly downloadable output. Public or anonymous client keys may legitimately be exposed when the service explicitly designs them for browser use and enforces authorization through controls such as row-level security. Privileged administrative keys, service credentials, private API keys, and reusable bearer tokens must not use public prefixes. ### Attack Path 1. A user follows the documentation and supplies a privileged API key or secret through the deployment `--env` option. 2. The user assigns the value to a variable with a frontend-public prefix such as `VITE_`, `NEXT_PUB ...[truncated 913 chars]
• Remediation: ## Remediation Suggestions 1. Explicitly state that `VITE_*`, `NEXT_PUBLIC_*`, `REACT_APP_*`, `PUBLIC_*`, and equivalent prefixes are public and must never contain privileged secrets. 2. Replace the generic recommendation with separate guidance for: - intentionally public client configuration; and - private server-side credentials. 3. Store privileged values in server-side secret storage and access them only from edge functions or other trusted backend code. 4. Clarify that deployment environment variables are not inherently confidential when used by a frontend build. 5. Add validation that warns or fails when sensitive names such as `PASSWORD`, `PRIVATE_KEY`, `SERVICE_ROLE`, `ADMIN_KEY`, or `SECRET` use public prefixes. 6. Document that anonymous client keys are acceptable only when explicitly designed for public distribution and protected by server-side authorization controls. 7. Recommend reviewing compiled frontend artifacts for embedded credentials before deployment. 8. Rotate any privileged credential that has already been included in a public frontend bundle.

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
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (13)

Credential Access

High

• Category: Privilege Escalation

Content

| Variable | Description |
|----------|-------------|
| `INSFORGE_ACCESS_TOKEN` | Override stored access token |
| `INSFORGE_PROJECT_ID` | Override linked project ID |
| `INSFORGE_EMAIL` | Email for non-interactive login |
| `INSFORGE_PASSWORD` | Password for non-interactive login |

• Confidence: 95% confidence
• Finding: The skill documents sensitive authentication material in environment variables, including an access token and password, without clear safeguards on storage, exposure, lifetime, or scope. In agentic or automated environments, such variables are commonly propagated to child processes, logs, crash reports, and CI metadata, making credential theft plausible and especially dangerous given the CLI's access to secrets, database operations, deployments, and project administration.

Credential Access

High

• Category: Privilege Escalation

Content

# - Next.js: NEXT_PUBLIC_INSFORGE_URL
# - CRA: REACT_APP_INSFORGE_URL
# - Astro: PUBLIC_INSFORGE_URL
cat > .env.production << 'EOF'
INSFORGE_URL=https://your-project.insforge.app
INSFORGE_ANON_KEY=your-anon-key
EOF

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

| Mistake | Solution |
|---------|----------|
| Including node_modules in zip | Exclude it - will be installed during build |
| Including .env files | Pass via `envVars` parameter instead |
| Missing VITE_* env vars | Add all required build-time variables to `envVars` |
| Checking status too early | Wait 30sec-1min before checking status |
| Missing vercel.json for SPA | Add rewrites config for client-side routing |

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

## Credential Storage

Tokens are saved to `~/.insforge/credentials.json` with restricted file permissions (0600). Includes:
- `access_token` and `refresh_token`
- User info (id, name, email)

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

| Flag | Description |
|------|-------------|
| `--json` | Structured JSON output (for scripts and agents) |
| `-y, --yes` | Skip confirmation prompts |

## Exit Codes

• 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.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The skill explicitly recommends non-interactive login using INSFORGE_EMAIL and INSFORGE_PASSWORD in CI/CD, but it does not warn that plaintext credentials in environment variables can be exposed through logs, process listings, shell history, misconfigured runners, or compromised build environments. Because this CLI manages projects, databases, functions, deployments, and secrets, compromise of these credentials could enable broad account and project takeover.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The documentation states that project creation fetches the project's API key and includes it in output, but does not clearly warn that a sensitive credential will be retrieved and potentially displayed in terminal logs, CI output, shell history context, or agent transcripts. In this skill context, that is especially risky because the command is explicitly positioned for CI/CD and agent use, where outputs are often captured and forwarded to external systems.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 94% confidence
• Finding: The documentation instructs users to run `npx skills add insforge/agent-skills`, which pulls and executes a package/toolchain without pinning an exact version or immutable source. In an agent/CLI bootstrap flow, this creates a supply-chain risk: a malicious or compromised upstream release could execute arbitrary code during project creation and automatically install attacker-controlled skills into the workspace.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation describes exporting full database schema and data to stdout or files but does not warn that exports may contain sensitive or regulated information such as user records, credentials, tokens, or business data. In a CLI skill intended to guide operational database management, this omission can lead users to create unprotected backups, redirect sensitive output into logs, or store dumps in insecure locations.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: This markdown file documents a skill that executes raw SQL against the project database and exposes an `--unrestricted` mode, but it does not warn users that queries may modify schema/data or expose sensitive metadata. Under the markdown criteria for missing user warnings, operations affecting user data or system integrity should be accompanied by clear warnings.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: This markdown file describes zipping the source directory, uploading it to a presigned URL, and starting a deployment with environment variables. While the behavior is documented, it does not clearly warn users that local project files and provided env vars will be sent to remote infrastructure, which is a privacy- and integrity-relevant action for a deployment skill.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The documentation recommends passing a password directly via an environment variable for CI/CD use without warning about the exposure risks. In many environments, environment variables can be leaked through process listings, CI job logs, crash reports, shell history wrappers, or inherited child processes, which can expose reusable credentials to other users or systems.

Missing User Warnings

Low

• Confidence: 86% confidence
• Finding: This markdown file describes a deploy command that creates or updates remote functions via GET/PUT/POST, but it does not include any cautionary note about modifying live remote resources. Although deployment is the command's purpose, the description omits a user-facing warning about potential impact on production behavior or existing function code.

Static analysis

No suspicious patterns detected.