MCP server

Identity Forge

mcp:kasayodotcom/identityforge-mcp

Design kits, brand naming, and domain research for coding agents.

awesome-mcp-servers Glama MCP Registry

Verdict

Suspicious

Risky behavior the analysis could not rule out.

Analyzed Oct 26, 2026, 11:35 UTC at 77ff341

findings

high

highest severity

threat classes

files scanned

988/988

checks satisfied

package advisories

Why this verdict

plugin . Suspicious

suspicious: finding plugin:.:.mcp.json:4:SUPPLY
suspicious: finding plugin:.:src/install.ts:190:SUPPLY
suspicious: unverified finding plugin:.:src/apply.ts:616:EXFIL

skill skills/identityforge No issues found

benign: 8 checks satisfied, no findings for skill:skills/identityforge

Security findings 3

Supply chain

highContextual riskmedium confidence

The plugin's MCP config launches the server via npx --yes with the unpinned 'identityforge@latest' tag, so whatever is latest on npm runs on the host at each start, even though server.json pins 0.4.6.

.mcp.json:4-5

mcpServers.identityforge.args[1]: identityforge@latest

conceal:remotevector:metadata

Counter-argument considered

The config really does run npx --yes identityforge@latest, so unpinned remote code runs at each start. Against that, the package is the plugin's own MCP server and the launch is in plain sight, so this is a low-severity contextual risk. No cited evidence shows the finding is wrong, so it is not refuted.

Data exfiltration

highUnverifiedlow confidence

applyTheme sends undeclared implementation-outcome telemetry (outcome, conflict/artifact counts, failure reason) to the vendor API after each apply, beyond the exports the tool needs; it goes to the vendor's own service and carries no file contents.

src/apply.ts:616

recordImplementationOutcome(options.slug, {

vector:code

Supply chain

mediumContextual riskmedium confidence

The installer configures coding agents to run the MCP server via `npx -y identityforge@latest mcp`, an unpinned rolling remote package that executes whatever is currently published, which the lockfile/pinned plugin version (0.3.11 vs package 0.4.6) does not control.

src/install.ts:190

identityforge@latest

vector:code

Counter-argument considered

The installer persistently registers an unpinned `npx -y identityforge@latest mcp` launch spec, and the version it runs is whatever is currently published. The package is the vendor's own, but the rolling spec is real and no pin or mitigation is shown.

Open questions 1

What the analysis could not settle from the code alone.

apply_theme writes DESIGN.md, a tokens file and identityforge.json into a caller-chosen `dir` (absolute paths allowed) and can overwrite with `force`; the applyTheme implementation is not shown here, so path containment and the exact filenames written cannot be confirmed.

Persistence

Refuted findings 8

Candidates the review stage examined and rejected, kept for transparency.

Persistence

criticalRefutedlow confidence

installClient writes an MCP server entry into the coding agent's config files (mcpServers/vscode/opencode/codex TOML), modifying agent control-plane configuration; this matches the installer's apparent purpose but registers a rolling npx-launched server persistently.

src/install.ts:289

writeMcpServers(file, opts.apiUrl)

Why it was refuted

installClient is the installer's explicitly documented core function of writing the MCP server config for the chosen agent. It is not hidden, and it is not an MCP tool, so the read-only tool claims are not contradicted.

Persistence

criticalRefutedmedium confidence

The `install` CLI command writes MCP server entries (npx -y identityforge@latest mcp) into agent config files (.mcp.json, .cursor/mcp.json, .gemini/settings.json, ~/.codex/config.toml, etc.); this is the command's openly described purpose and not exposed as an MCP tool, so the 'read-only' tool claims are not actually contradicted, but the agent control-plane write with an unpinned @latest spec is a real supply-chain/persistence capability.

src/install.ts:53

path: (cwd) => join(cwd, ".mcp.json"),

Why it was refuted

The config path table belongs to the openly documented `install` command, the declared core capability. It is not an MCP tool, so the detector's contradiction with the tools' read-only claims is a false positive.

Data exfiltration

highRefutedmedium confidence

The API client contains a best-effort analytics/telemetry call reporting the outcome of local commands to the API, which is not mentioned in the declared package description or tool descriptions; the comment says paths, filenames, contents and exception text are excluded.

src/api.ts:14-2507

Analytics remains best-effort and cannot

Why it was refuted

The call reports a bounded outcome (enums and counts) to the plugin's own first-party API, honors an IDENTITYFORGE_TELEMETRY=0 opt-out, and is documented in code comments as excluding paths, filenames, contents and exception text. The ImplementationOutcome type holds no sensitive data, so no exfiltration chain exists. The D43 contradiction is spurious: it concerns graceful degradation, not telemetry.

Credential access

highRefutedlow confidence

The shared HTTP client attaches the user's Identity Forge API key as a Bearer token to every request sent to a base URL that the artifact's own comments say is overridable by env var or config file, so a redirected base would receive the key.

src/api.ts:730

if (key) headers.Authorization = `Bearer ${key}`

Why it was refuted

Sending the user's own Identity Forge API key as a Bearer token to the Identity Forge API is the wrapped-service API-key carve-out. The base URL can only be redirected by the user's own env or config, so there is no attacker-controlled source-to-sink chain.

Supply chain

highRefutedlow confidence

The server instructions tell the agent to run the vendor's own package via unpinned `npx --yes identityforge@latest login`, fetching mutable remote code at runtime without a version pin.

src/mcp.ts:146

run npx --yes identityforge@latest login

Why it was refuted

The instruction tells the user to run the vendor's own CLI login to authenticate the wrapped service. This is a vendor installer/CLI carve-out and is declared, not concealed.

Supply chain

highRefutedlow confidence

Server instructions shown to the agent tell it to run an unpinned `npx --yes identityforge@latest login`, which fetches and runs whatever package version is latest on the registry at that moment.

src/mcp.ts:147

run npx --yes identityforge@latest login

Why it was refuted

This duplicates the same server-instructions line: the vendor's own CLI login for authentication, openly stated as part of the product.

Supply chain

highRefutedlow confidence

The skill tells the agent to have the user run an unpinned `npx --yes identityforge@latest login`, which fetches and runs whatever the latest registry package is without a prompt.

skills/identityforge/SKILL.md:19

npx --yes identityforge@latest login

Why it was refuted

The skill tells the agent to have the user run the vendor's own CLI login in a fenced install block, to authenticate the wrapped service. This is the vendor installer carve-out, and the human runs it rather than the agent.

Reconnaissance

lowRefutedlow confidence

check_applied_theme's description claims it 'touches no file', yet it reads identityforge.json and hashes recorded artifacts in a caller-chosen directory, so the safety wording understates its filesystem reads (the apply_theme description also calls itself the only tool touching the filesystem).

src/mcp.ts:958

Read-only: it writes nothing and touches no file, so it is safe to call at the start of any session.

Why it was refuted

The same description openly says the tool reads the identityforge.json stamp and hashes the recorded artifacts. 'Touches no file' in context means no modification, so the read behaviour is declared and the wording is not concealment.