Skip to content
skillsafebeta
← Report library
Purpose / Development

Insforge Debug Skill Security Audit

What the author says it does (original text)

>-

Independent security check

Do not install or run it yet

Files checked
11
Risks found
7
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 2
High risk

An unpinned npm package is executed during diagnostics

Source references: 3
What we found

Every command uses `npx -y @insforge/cli` without a version or integrity value. The `-y` flag automatically accepts npm's installation prompt, so the code executed depends on the registry version available at that time.

Why this matters

If the package, publisher account, or dependency chain is compromised, code could run in an agent environment that is logged into InsForge and may have access to project files and environment variables.

This is an active execution requirement, not merely an example. Diagnostics use an unpinned `@insforge/cli`, and `npx -y` automatically accepts installation prompts, so execution depends on the package npm resolves at that time. No version or integrity pin is provided. A user can ask for a reviewed pinned version or restrict npm network access.

SKILL.md:21In the instructionsOpen original file
**Always use `npx -y @insforge/cli`** — never install the CLI globally.
Show 2 other places
SKILL.md:28In the instructionsOpen original file
```bashnpx -y @insforge/cli diagnose --ai "<issue description>"```
SKILL.md:37In the instructionsOpen original file
All commands run via `npx -y @insforge/cli ...`. The `(command)` shown next to each primitive is the actual CLI command — primitive names are concept labels, **not** CLI subcommand names (e.g., "DB health" is `diagnose db`, not `diagnose db-health`; "Policies" is `db policies`, not `diagnose policies`).
Medium risk

Deployment troubleshooting recommends redeploying a function, which can change live state

Source references: 2
What we found

The failed-function-deployment workflow recommends rerunning `functions deploy <slug>` when needed. Redeployment is not a read-only check: it can replace an active function or repeat a partially successful deployment, and the instructions do not require confirming the target environment or obtaining permission.

Why this matters

A production function could be replaced, become temporarily unavailable, or enter a different state before the original failure is understood, expanding the incident and obscuring evidence.

The function-deployment troubleshooting flow does include rerunning `functions deploy <slug>`. Its first two steps observe state, but the third mutates the remote deployment and could replace an active function or repeat a partially successful deployment; “if needed” is not an explicit authorization gate. Users can require read-only checks first and approve the project, slug, and release impact before redeployment.

references/deploy-state.md:46In the instructionsOpen original file
For "function deploy failed":1. `npx -y @insforge/cli logs function-deploy.logs --limit 50` — find the build/push error2. `npx -y @insforge/cli functions list` — confirm the function did or didn't make it into the active list3. Re-run `npx -y @insforge/cli functions deploy <slug>` if needed and capture stdout for the explicit error
Show 1 other places
references/deploy-state.md:33In the instructionsOpen original file
## Edge function deploys`function-deploy.logs` captures backend deploy events (compile errors, push failures, registration errors). `functions list` confirms the final state — if the function isn't there or `status != active`, the deploy didn't fully take.
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 3
High risk

Problem descriptions and project observability data may be given to a backend LLM

Source references: 4
What we found

The AI path explicitly sends the user's problem description to a backend LLM, which can also combine logs, database health, policies, and metadata. Errors, URLs, or logs may contain user identifiers, request content, tokens, or internal structure. The supplied material does not identify the LLM provider, retention period, or training use.

Why this matters

Project or user data may leave the local environment and be processed by an unspecified data processor. Disclosed tokens or internal details could affect account and backend security.

The AI path sends a user-supplied error, URL, status, or function name to a backend LLM that can combine logs, policies, metadata, and database-health data. If those inputs contain tokens, user data, or internal structure, they may leave the local environment. The source does not state provider, retention, or training terms. Users can request those terms, redact inputs, or disable `--ai`.

references/ai-assisted.md:3In the instructionsOpen original file
The meta-primitive: hand a natural-language problem description to a backend-side LLM agent that combines the other primitives ([logs](logs.md), [metrics](metrics.md), [db-health](db-health.md), [advisor](advisor.md), [policies](policies.md), [metadata](metadata.md)) on its own and returns a diagnosis plus suggested solutions.**Unlike every other primitive in this skill, `diagnose --ai` returns suggestions, not just observations.** Verify before acting.
Show 3 other places
references/ai-assisted.md:10In the instructionsOpen original file
```bashnpx -y @insforge/cli diagnose --ai "<issue description>"```The description should include: the error / failing URL / HTTP status / function slug — whatever concrete signal the user has.
references/ai-assisted.md:13In the instructionsOpen original file
The description should include: the error / failing URL / HTTP status / function slug — whatever concrete signal the user has.
references/logs.md:33In the instructionsOpen original file
Each line has timestamp + source + level + message. When chasing a known-time symptom:1. Get the approximate timestamp from the user (when did the request fail?)2. Increase `--limit` until the window covers it (start 50, bump to 200 if needed)3. Look for the level (`ERROR` / `WARN`) and message — the message usually names the failing componentFor request-correlated symptoms (single failing URL), look for the request line in `postgREST.logs` (REST calls) or `insforge.logs` (auth/realtime/function dispatch) — both include the URL path.
High risk

RLS troubleshooting reads cross-user database rows as the service role

Source references: 2
What we found

The empty-result recipe explicitly calls for an unrestricted `SELECT id, user_id FROM <table>` as the service role. That role bypasses user-level RLS, and the example has no WHERE clause, LIMIT, or existence-only check.

Why this matters

Identity relationships for every user in the table could appear in terminal and agent context, exceeding what is needed to confirm whether one user's data exists. Terminal history or later model calls could broaden the exposure.

For an empty RLS-filtered read, the recipe explicitly requests a service-role query with no `WHERE` or `LIMIT`. Although diagnostically motivated, it can bypass user-level visibility and expose row and user identifiers across the table. The risk arises only if that placeholder query is executed. Users can require a narrowly filtered existence/count query and confirm its scope first.

SKILL.md:74In the instructionsOpen original file
3. **metadata** — verify auth config (which claim feeds `auth.uid()` / `requesting_user_id()`; for third-party auth like Clerk/Auth0, is the provider registered as a JWT issuer?).4. **db query** (`db query "<sql>"`) — *empty-result variant only*: confirm rows that *should* be visible actually exist by querying as service role (not as the user): `npx -y @insforge/cli db query "SELECT id, user_id FROM <table>"`. Distinguishes "RLS filtered everything" from "no matching data exists".
Show 1 other places
SKILL.md:69In the instructionsOpen original file
> Same bug, two surfacings. Writes (INSERT / UPDATE / DELETE) fail loudly with **403**. Reads (SELECT) fail silently with an **empty array** — PostgREST filters denied rows out instead of returning 403, so the request looks successful with zero rows. Diagnosis path is the same except step 1 only applies to the 403 variant.1. **logs** (`postgREST.logs`) — *403 variant only*: find the policy violation event with table and role context. *Empty-result variant*: skip — no error is logged for silently-filtered rows.2. **policies** — list policies for that table; walk USING / WITH CHECK against the actual request and the JWT claim used.3. **metadata** — verify auth config (which claim feeds `auth.uid()` / `requesting_user_id()`; for third-party auth like Clerk/Auth0, is the provider registered as a JWT issuer?).4. **db query** (`db query "<sql>"`) — *empty-result variant only*: confirm rows that *should* be visible actually exist by querying as service role (not as the user): `npx -y @insforge/cli db query "SELECT id, user_id FROM <table>"`. Distinguishes "RLS filtered everything" from "no matching data exists".
Medium risk

The feedback command externally reports raw errors and reproduction details

Source references: 4
What we found

For suspected platform defects, the Skill calls `feedback` with the failing command, detailed reproduction, and a “verbatim” log error. It acknowledges that local redaction is only pattern-based, which can miss business data, nonstandard credentials, or other sensitive context, and it does not require consent before submission.

Why this matters

Internal project information, user data, or secrets not recognized by the patterns could be sent to InsForge in the report.

When a problem is judged to be an InsForge defect, the skill actively directs submission of detailed reproduction data, the failing command, and a verbatim log error. It warns that redaction is pattern-based and says to omit user data, which mitigates but does not eliminate exposure of business data or unusual credentials; no pre-submission approval step is shown. Users can require a full payload preview, manual redaction, and explicit consent.

SKILL.md:201In the instructionsOpen original file
  --title "<one-line summary>" \  --detail "<what happened vs expected, minimal repro>" \  --command "<the failing call>" \  --error "<verbatim error from logs>" \  --workaround "<what you did instead>"```
Show 3 other places
SKILL.md:207In the instructionsOpen original file
No login required; common PII patterns (emails, credential/key formats, public IPs, home-directory usernames) are redacted locally — pattern-based, so still keep user data out. Use `--component sdk --language <lang>` for SDK defects; `--component docs` or `--component skills` with `--doc` and `--expected` when documentation contradicts reality; `--type feature-request` when the finding is "not supported". Then continue the user's task with the workaround — never block on the report, and never file feedback for problems in the user's own app code or config. Full flag reference: the **insforge-cli** skill's Feedback section.
SKILL.md:193In the instructionsOpen original file
## When the Root Cause Is InsForge ItselfSome diagnoses end at an InsForge-side defect, not a project misconfiguration: a platform bug or regression, an SDK call that misbehaves, docs or a skill that contradict observed behavior, or a missing capability. A debug session is exactly where these get confirmed — report them while the evidence is in hand:
SKILL.md:198In the instructionsOpen original file
```bashnpx -y @insforge/cli feedback --json \  --type bug --component backend --area db \  --title "<one-line summary>" \  --detail "<what happened vs expected, minimal repro>" \  --command "<the failing call>" \  --error "<verbatim error from logs>" \  --workaround "<what you did instead>"```
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Medium risk

The audit workflow extends into RLS, secret, and configuration changes without separate approval

Source references: 5
What we found

The stated scope includes diagnosis and proactive audits, but the Advisor workflow then directs the agent to apply migrations, RLS edits, secret rotation, or configuration updates. It requires validating recommendations but does not require user confirmation before production changes.

Why this matters

A user who requested only a report or audit could unexpectedly have access policies, database structure, credentials, or runtime configuration changed, causing outages, incorrect permissions, or application failure.

The Advisor workflow extends from read-only scanning into migrations, RLS edits, secret rotation, and configuration updates. These can alter access, invalidate existing keys, or affect production service. The document requires validating static recommendations but shows no separate environment, backup, or user-approval gate before mutation. Users can restrict the skill to read-only auditing and require approval for each production change.

SKILL.md:7In the instructionsOpen original file
  or timeout, login/OAuth/auth errors, RLS denial, realtime channel issues,  slow query on one endpoint, edge function or Vercel deploy failure), proactive  audits (security/RLS review, performance/index review, system health check,  pre-launch readiness), or when the user has an error but doesn't know where  to start.license: Apache-2.0
Show 4 other places
references/advisor.md:52In the instructionsOpen original file
```text1. Scan:    diagnose advisor --severity critical --json2. Triage:  pick one issue, read affectedObject + recommendation3. Verify:  inspect the affected object (db query / db policies / metadata)4. Fix:     apply the change (migration / RLS edit / secret rotation / config update)5. Re-scan: diagnose advisor --json — confirm isResolved=true for that ruleId6. Repeat with next critical, then warnings, then info
references/advisor.md:62In the instructionsOpen original file
- **Scans are not real-time.** A new scan triggers when the platform schedules it; recommendations lag behind very recent changes. Force a fresh scan if needed.- **Recommendations are static suggestions, not auto-fixes.** Always validate against current schema state before applying.- **`affectedObject` is a string, not a typed reference.** It names the object but doesn't link to it — combine with [metadata](metadata.md) / [policies](policies.md) to inspect.- **Not available when linked via `--api-key`.** Requires `insforge login` (Platform auth).
references/advisor.md:44In the instructionsOpen original file
1. **Start with severity**: `--severity critical` first; critical issues block launch.2. **Group by category** to keep the fix mode coherent (don't context-switch between RLS edits and index migrations).3. **`affectedObject` tells you where to fix** — it names the concrete schema object.4. **`recommendation` is usually actionable as-is**. Verify it makes sense (the recommendation may be generic), then apply via the appropriate primitive's tooling.
references/advisor.md:51In the instructionsOpen original file
```text1. Scan:    diagnose advisor --severity critical --json2. Triage:  pick one issue, read affectedObject + recommendation3. Verify:  inspect the affected object (db query / db policies / metadata)4. Fix:     apply the change (migration / RLS edit / secret rotation / config update)5. Re-scan: diagnose advisor --json — confirm isResolved=true for that ruleId6. Repeat with next critical, then warnings, then info```
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.Risks found: 1
Low risk

An OOM diagnosis leads to paid resizing, recurring cost, and a restart

Source references: 4
What we found

For OOM with supporting evidence, the Skill directs the user to a paid plan and larger instance and states that resizing changes the bill and restarts the project. It does require approval, but the cloud-side `oom_likely` verdict and indirect crash-recovery evidence still warrant independent verification.

Why this matters

The user may incur higher recurring charges and a project restart. If the real cause is a query, connection leak, or abnormal traffic, resizing may only conceal it.

Legitimate use of this code

Resizing does change billing and restart the project, but the instructions limit it to evidence-backed OOM cases and explicitly require the user's go-ahead; the CLI also asks for interactive confirmation. The manual fallback requires correlating crash-recovery logs with the 5xx burst before treating OOM as the leading diagnosis. This is therefore a gated recovery action, not a silent purchase. Users should still verify size, price, and maintenance window.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:163In the instructionsOpen original file
must line up before OOM becomes the leading diagnosis([references/metrics.md](references/metrics.md)). With that evidence the fix is headroom, not aretry loop:1. **Upgrade the instance** — `npx -y @insforge/cli projects upgrade-instance <type>`   (`nano` → `micro` → `small` → `medium` → `large` → `xl`), or dashboard → Project Settings →   Compute & Disk. On the free plan, upgrade to a paid plan first, then pick the size. The   resize changes the bill and the CLI asks for interactive confirmation — get the user's   go-ahead first, then run unattended with the CLI-level `--yes` (the `-y` in `npx -y` is   npm's install flag, not the confirm-skip). The resize is async — poll `projects get` until
Show 3 other places
SKILL.md:173In the instructionsOpen original file
   `operation_status` clears before declaring the incident resolved.2. The resize **restarts the project as part of the change**, which also clears any wedged   state — there is no separate user-facing restart, and a bare restart would only buy minutes   before the next spike OOMs again. OOM under real load on the smallest sizes is common and   expected, not a bug.
SKILL.md:158In the instructionsOpen original file
If the command is unavailable (older CLI/backend, `--api-key` link mode), confirm manually in**logs** (`postgres.logs`) via the crash-recovery aftermath — "terminating connection because ofcrash of another server process" / "automatic recovery in progress" — **time-correlated with the5xx burst**: recovery evidence alone only proves an unclean Postgres restart, so the timestampsmust line up before OOM becomes the leading diagnosis([references/metrics.md](references/metrics.md)). With that evidence the fix is headroom, not aretry loop:
SKILL.md:166In the instructionsOpen original file
1. **Upgrade the instance** — `npx -y @insforge/cli projects upgrade-instance <type>`   (`nano` → `micro` → `small` → `medium` → `large` → `xl`), or dashboard → Project Settings →   Compute & Disk. On the free plan, upgrade to a paid plan first, then pick the size. The   resize changes the bill and the CLI asks for interactive confirmation — get the user's   go-ahead first, then run unattended with the CLI-level `--yes` (the `-y` in `npx -y` is   npm's install flag, not the confirm-skip). The resize is async — poll `projects get` until   `operation_status` clears before declaring the incident resolved.2. The resize **restarts the project as part of the change**, which also clears any wedged

Inside this skill

4 instruction sections

The Skill is intended to diagnose and audit InsForge projects and requires fetching and running the InsForge CLI through npm instead of installing it globally.

View source
SKILL.md:16In the instructionsOpen original file
Diagnose problems in InsForge projects by combining the backend's observability primitives — logs, metrics, db-health, advisor, policies, metadata, error objects, deploy state, and AI assist. This skill provides:
SKILL.md:21In the instructionsOpen original file
**Always use `npx -y @insforge/cli`** — never install the CLI globally.

The diagnostic process reads backend information including logs, live database state, RLS policies, authentication configuration, storage buckets, and functions.

View source
SKILL.md:41In the instructionsOpen original file
|---------------------|-------------|-----------|| **Logs** (`logs <source>`; `diagnose logs` for cross-source aggregate) | Time-stream of events from 5 backend sources (`insforge.logs` / `postgREST.logs` / `postgres.logs` / `function.logs` / `function-deploy.logs`) | [references/logs.md](references/logs.md) || **Metrics** (`diagnose metrics`) | EC2 instance time-series (CPU / memory / disk / network) over `1h` / `6h` / `24h` / `7d` | [references/metrics.md](references/metrics.md) || **DB health** (`diagnose db`) | Current Postgres state via 7 named checks (`connections` / `slow-queries` / `bloat` / `size` / `index-usage` / `locks` / `cache-hit`) | [references/db-health.md](references/db-health.md) || **Advisor** (`diagnose advisor --json`) | Static-scan issues across 3 categories (`security` / `performance` / `health`) with `ruleId` / `affectedObject` / `recommendation` | [references/advisor.md](references/advisor.md) || **Policies** (`db policies`) | Active RLS rules from `pg_policies` (USING / WITH CHECK per cmd per role) — returns all policies as a dump | [references/policies.md](references/policies.md) || **Metadata** (`metadata --json`) | Declarative backend state dump (auth config / tables / buckets / functions / AI models / realtime channels) | [references/metadata.md](references/metadata.md) || **Error objects** (no command — read SDK / HTTP response) | SDK error envelope + HTTP status — the routing table from a client-visible error to the right log source | [references/error-objects.md](references/error-objects.md) |

The AI-assisted path sends the problem description to a backend LLM and lets that agent combine logs, metrics, policies, and metadata; the Skill also warns that its suggestions may be wrong and require verification.

View source
references/ai-assisted.md:3In the instructionsOpen original file
The meta-primitive: hand a natural-language problem description to a backend-side LLM agent that combines the other primitives ([logs](logs.md), [metrics](metrics.md), [db-health](db-health.md), [advisor](advisor.md), [policies](policies.md), [metadata](metadata.md)) on its own and returns a diagnosis plus suggested solutions.**Unlike every other primitive in this skill, `diagnose --ai` returns suggestions, not just observations.** Verify before acting.
references/ai-assisted.md:39In the instructionsOpen original file
If the verification disagrees with the diagnosis, **trust the primitive observation**, not the suggestion. Suggestions can be plausible-sounding but wrong (LLM may pattern-match on similar errors); raw `pg_stat` numbers and log lines can't lie.

Resizing an instance changes billing and restarts the project; the instructions require user approval before using the non-interactive confirmation flag.

View source
SKILL.md:169In the instructionsOpen original file
   Compute & Disk. On the free plan, upgrade to a paid plan first, then pick the size. The   resize changes the bill and the CLI asks for interactive confirmation — get the user's   go-ahead first, then run unattended with the CLI-level `--yes` (the `-y` in `npx -y` is   npm's install flag, not the confirm-skip). The resize is async — poll `projects get` until   `operation_status` clears before declaring the incident resolved.2. The resize **restarts the project as part of the change**, which also clears any wedged   state — there is no separate user-facing restart, and a bare restart would only buy minutes
Start here · InstructionsSKILL.md
insforge-debug
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 40
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records11 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/advisor.mdFull text included
  • references/ai-assisted.mdFull text included
  • references/db-health.mdFull text included
  • references/deploy-state.mdFull text included
  • references/error-objects.mdFull text included
  • references/logs.mdFull text included
  • references/metadata.mdFull text included
  • references/metrics.mdFull text included
  • references/policies.mdFull text included
  • agents/openai.yamlFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • agents/openai.yamlSupporting file
  • references/advisor.mdSupporting file
  • references/ai-assisted.mdSupporting file
  • references/db-health.mdSupporting file
  • references/deploy-state.mdSupporting file
  • references/error-objects.mdSupporting file
  • references/logs.mdSupporting file
  • references/metadata.mdSupporting file
  • references/metrics.mdSupporting file
  • references/policies.mdSupporting file

Operations mentioned in code and instructions

Install extra software packages
SKILL.md:21In the instructionsOpen original file
**Always use `npx -y @insforge/cli`** — never install the CLI globally.
SKILL.md:28In the instructionsOpen original file
```bashnpx -y @insforge/cli diagnose --ai "<issue description>"```
SKILL.md:37In the instructionsOpen original file
All commands run via `npx -y @insforge/cli ...`. The `(command)` shown next to each primitive is the actual CLI command — primitive names are concept labels, **not** CLI subcommand names (e.g., "DB health" is `diagnose db`, not `diagnose db-health`; "Policies" is `db policies`, not `diagnose policies`).
Run commands
SKILL.md:27In the instructionsOpen original file
```bashnpx -y @insforge/cli diagnose --ai "<issue description>"
SKILL.md:197In the instructionsOpen original file
```bashnpx -y @insforge/cli feedback --json \
references/advisor.md:7In the instructionsOpen original file
```bashnpx -y @insforge/cli diagnose advisor [--severity critical|warning|info] [--category security|performance|health] [--limit <n>] [--json]
Read keys or account settings
SKILL.md:158In the instructionsOpen original file
If the command is unavailable (older CLI/backend, `--api-key` link mode), confirm manually in**logs** (`postgres.logs`) via the crash-recovery aftermath — "terminating connection because of
SKILL.md:180In the instructionsOpen original file
> Requires Platform login (`npx -y @insforge/cli login`). **Not available when the project is linked via `--api-key`** — fall back to `db-health` + `policies` + `metadata` for a manual audit in that case.
references/advisor.md:11In the instructionsOpen original file
Default limit: 50. Requires Platform login — **not available on backends linked via `--api-key`**.
Connect to websites
references/ai-assisted.md:49In the instructionsOpen original file
User pastes: "I invoked `https://kttprzh4.functions.insforge.app/newton` and got `508: Loop Detected (LOOP_DETECTED). Recursive requests to the same deployment cannot be processed.`"
references/ai-assisted.md:52In the instructionsOpen original file
```bashnpx -y @insforge/cli diagnose --ai "I invoked edge function https://kttprzh4.functions.insforge.app/newton, got error: 508: Loop Detected (LOOP_DETECTED)\n\nRecursive requests to the same deployment cannot be processed."```
references/metadata.md:55In the instructionsOpen original file
#    - redirect URLs include the exact callback the app uses#    (e.g., https://myapp.com/auth/callback — protocol + host + path must match)
Lines read
907
File checksum (to compare versions)
211e52001f0877db92d618c15cc8042a6f0a77aebe21c1125240580b32384bfa